Last Login:
July 29, 2015


User Profile

Hits: 127,672
Joined August 08, 2010
Games (11)

Game Music Player
October 10, 2011
August 01, 2012
In a word
August 10, 2010
October 07, 2010
Flood the mines Demo
November 12, 2010
January 24, 2011
Velocite R
April 12, 2011
Shinsetsu Ninja
February 18, 2013
Walk of Darkness Demo
November 15, 2013
Project Phoenix
April 30, 2014
Frosty RPG WIP
December 23, 2014
Examples (1)
Favorite Users

Current Projects
Posted on July 18, 2015 at 15:14

It feels like forever since I've even had any tangible progress to report on any of my projects.

In fact, it's been a while since I've had time to work on a project. Retail is soul-crushing.

A few weeks ago I basically handed in my notice, and will no longer be working at the front-desk from September 1st.
I'll instead be repairing computer problems on contract, with an up-front fee per machine (Nominal, I'm not going to fleece my boss; she's helped me out a lot - I'll be earning more than I am currently on a good week, since it'll be per-job and not a fixed weekly rate).
I've got my learner license for motorcycles, so I'll have easy transport between home and the workshop (Only a 2.5km trip, but I'm not walking when I have wheels available).

This means one thing to me: Time. I'll finally have time to get back to doing what I want to do.

Which is get all my skills back up to scratch again.

Skills rust. I can still draw and sprite relatively well, but can't animate for shit.

Music? I don't even know where to start.

So yeah, I'm going to have time to get back into practice; maybe release a few mini-games, do a Ludum Dare if I remember to join.

Oh right, the blog title is "Current Projects". I still tinker at work when I can; I have a crappy Linux box (Crappy because of crappy hardware, not because it's Linux).
I actually got around to not being a lazy ass and figured out how to implement both 2D and 3D renderers using modern GL (2.1, 3.0 mostly).

I've spent a lot of time streamlining my development process too. On my home machine, I've made use of a semi-forgotten command line program in Windows, SUBST, to map my dev folder to a drive letter.
Makes for much easier access via command line, and do 50% of my work in the command line (MSYS. Once you BASH, you can never CMD again).

For moving code between work and home, I set up a git repo for my projects on my USB drive. Simple git push, and a pull on the other machine and I'm done.

My build system at the moment is either very simple or very complicated, depending on the project.
For small things, I just set up a pair of shell scripts (One for Linux, one for Windows).

If things start to get mildly complicated, I usually slap together a makefile. Then I inevitably get tired of doing that and switch to using CMake, which is wonderful when it works, and a piece of shit when it doesn't.

Anyway... projects. I've got one game project I'm working on at the moment, not counting the other cold-starts I have in my dev folder.
It's mostly art at this point.

I just want to make a solid platformer. No gimmicks; just core concepts from the Megaman series: Jump 'n shoot.
I've gotten over the "Indie Disease" where you start every project trying to figure out a unique mechanic or theme. It doesn't work, you just end up with a bunch of false starts and end up feeling like crap.

I've played games like Axiom Verge and Freedom Planet recently. They both are just really solid games. Axiom Verge is pretty much a 1:1 Metroid Clone; everything you know about Metroid applies here. And I loved it.
Ditto for Freedom Planet.

I'd rather make something that fulfills the expected platformer mechanics first, and as solidly as possible, before I create any new mechanics; that way, I can create a gameplay element that fits the game, rather than create a game to fit it.


You know what I feel like doing at the end of a long day of dealing with the pests commonly known as the Computer Illiterate Masses?

Nothing. Absolutely nothing.

Nothing requiring input anyway. That's one of the major reasons I haven't been doing anything creative recently.

So basically I end up trawling Youtube and watching a ton of Anime. I tend to play games on the weekend when I have a bit of time.

Anime I'm watching
> Shokugeki no Soma (Genius, if you don't mind the Ecchi)
> Overlord (Mixed opinion on this so far)
> Dragon Ball Super
> Ranma 1/2
> One Piece (I'll never catch up)

Anime I recently finished
> Fate/Stay Night: Ultimate Blade Works (Excellent fight-scenes, slow story)
> Sword Art Online 2 (Stronger overall than the first season).
> JoJo's Bizarre Adventure. (Contents as on label. Loved it though, and am now reading the Manga).

Those of you who remember my viewing preferences from a few years ago will notice a huge shift. That is, I'm watching stuff that isn't Mecha.

Games I'm playing
> The Witcher 3 - I get the feeling this is going to take me months to get through.
> Dark Souls - I love doing speedruns and challenge runs.
> DoomRL
> NetHack, Crawl, ZAngband.
> A bit of TF2 on occasions.
> ARK: Survival Evolved
> Megaman X3: Been working out 100% Speedrun routes for this during quiet periods at work.

Games I recently finished
> Kerbal Space Program (Demo)
> Axiom Verge (Recommend highly to Metroid fans)
> Freedom Planet (Recommend it highly to Sonic 2/3 fans)

Impulse-bought Fallout New Vegas Ultimate Edition at the shop yesterday. I swear, they placed it right where I would see it ;_;
I already had the main game, but for all the DLC, it was nice and cheap (Approximately $7).

Well, that's enough out of me. Go watch these guys make a sword:

Posted on June 25, 2015 at 05:20

*grumble grumble* Mind altering code *grumble*

Blogging anywhere else sucks. I don't want to use a buggy Javascript implementation of an RTF text editor every time I want to write a small blog.

So hi. I'm back, unless bullshit starts up again.

Stuff I'm doing/have done
End of the month, I'm doing an aptitude test for the South African branch of this:
Not necessarily going in for it, I want to see what costs there will be first; and whether they'll be teaching anything I need to learn.

I'm still working at the PC shop. I plan on leaving towards September in order to pursue programming a bit more fervently. I kinda need the cash :P

During the Steam Summer Sales, I managed to buy a total of 10 games using nothing but trading cards. 11 if you count the gift copy of One Way Heroics I sent to my brother.

Speaking of that, it's a cool game. Take Pokemon Mystery Dungeon, add a liberal dose of JRPG tropes and throw in some Roguelike features and that's pretty much this game. Also has some online functionality.
It was going for $0.29 during the sales.

I pretty much freaked out during the Fallout 4 announcement at E3 and have promptly started dumping cash in a jar to save up for it (They're releasing it two days before my birthday, assuming there aren't any delays).

Jeremy and I made a Curses/Terminal based chat client in Node from scratch in about 7 hours.

I've started to want a HoloLens more than an Oculus Rift, but still want both.

I've hit a wall with that Point of Sales app I was making, mostly because of thermal receipt printer drivers, Node and cash drawers.

I've started to make a new engine based purely on OpenGL 4.x. It's more fun than fixed pipeline, that's for sure. Have also got a BSP editor in progress, and the skeleton of a voxel based "pixel art" editor I'm experimenting with.
More on that when I have pics/video.

Well that's enough out of me. I've got money to take from people who broke their computers.

March Blog
Posted on March 23, 2015 at 16:38

I've got a distinct lack of blogs for this month, besides that UE4 announcement thingy.
So here's a hodgepodge of a blog; I'll try to section things off neatly and remember to use paragraphs for once.

Work has been... interesting. I still get basket cases bringing their PCs into the shop, along with other electronic devices.

I've been asked, over the last two weeks, whether I can repair:
> Fax Machines
> Toasters
> Televisions (CRT & LED with a busted screen)
> Amplifiers
> Microwaves
> DSTV Decoder (Set-top Satellite Box)

The looks on people's faces when I remind them that this is a computer repair shop straddle the line between bewildered and horrified.
They seriously don't see why I don't fix these objects. I mean, heck... I could try, but I'd more likely break it/turn it into an analogue computer than actually do what they want me to do.

Also had one of the usual dicks in the shop last week. I was pleased to learn that most of the other shopkeepers I know refer to him as "That Bloody Wanker".
He's a musician, plays Afrikaans gigs (Guitar + Singing, solo) and obviously thinks he's a Big Deal.

So, he walks into my shop with his laptop. He uses it to play his backing tracks and record music on, and for some reason his audio ports have stopped working, and he has a gig the next day. So it's a big emergency, and I help him out.
About 10 minutes and one driver repair later, they're working again. He's overjoyed, until I tell him the repair cost.

Our shop has a basic "service" fee, per hour. So the first hour costs a fixed amount, at our discretion. This applies to any 'basic' job such as the above, or helping people "Fix their Facebook", and so on.
It's about $15, R150 locally (And about 15 loaves of cheap white bread around here).

This is a middling bit of cash; it's not huge though. We pride ourselves on having lower basic rates than the other computer shops in the nearby area. The next lowest price for this sort of thing is R450, three times what we charge.

This guy proceeds to throw the biggest tantrum I've ever heard an adult throw. He goes on and on about how he's a "Starving musician", that I'm a "greedy son of a bitch trying to take his hard earned money" and the usual allotment of swears that the locals learned in school.
If this was my first month on the job, I'd probably have been scared off. Fortunately, I've figured out the best way to deal with them:
"Shut the hell up, pay up, and get out. I don't want to see you in my shop again."

A lot of the customers I have in the shop tend to have a bit of an attitude, like they're doing us a 'favor' in bringing their problems to us.
I often have to remind people that if they knew what they were doing, a lot of the problems they pay for me to fix wouldn't happen in the first place.

I get three primary customer groups (Four if you count the Toaster brigade).
> People needing a problem solved (Repair, Viruses, etc)
> People wanting advice
> People wanting to buy a retail product

The latter two are usually amiable, and never cause any trouble.

People who fall into the first category tend to either be very polite, or extremely vitriolic.
Often, when they see how 'simple' a problem was for me to solve, they get angry and seem to think it's somehow my fault that they didn't know how to solve the problem.

But yeah, my policy with these customers is that I don't want them or need them. Let them go; they'll probably come back later with mumbled apologies (Which has happened a few times when they go to the competition and pay through their nose for the same job).

On a more cheerful note, our landlord told us to move at the beginning of the month. And no, I'm not being sarcastic; she's letting us have another shop in the building that's 6 times the floor space, with a storage room at the back, and all for the same rent!
We're actually in the position where this feels like too much space, and we're puzzling out ways to effectively use it.

One of the improvements we're making is the placement of a coffee table and armchairs, along with a coffee machine and a stack of computer magazines (Those being provided by me; have nearly 300 assorted mags).

To make our shelves seem a little less empty, I'm putting a bunch of old empty part boxes on display; things like GPU boxes, motherboard boxes, etc. Looks nice, and also happens to be stuff we can order.
I'm going to make sure to put an "Order on request" sticker on the empties though, because otherwise I'm going to be explaining myself every day.

I haven't been doing as much programming recently as I'd like to be doing, but I'm slowly getting back into it. I have a multitude of mini-projects I'm working on at work.
These include:
> QRL - Quick Roguelike; something like Binding of Isaac, with rudimentary graphics. Looks like an Atari 2600 game at the moment.
> QRL3D - Working on a span-renderer akin to Doom and making a simple shooter/roguelike hybrid.
> CSH - C-like scripting language library, trying to make it as tight as possible.
> RAY - Simple raytracer I'm kinda piecing together using the materials below.

I've been getting into the recent habit of naming all my projects in upper-case, as you can see.

At home, I'm working on a Super Secret Project with Jeremy; if you know what it is, let it be known that major progress has been made on it.

I've also been working on a simple port of Exile to UE4, just to learn the ropes. I haven't got much further than importing my assets though. :P

Interesting programming materials
I've been reading from these two sites recently:

Fabien Sanglard's Site
Full of wonderfully constructed breakdowns of classic game engines. Wonderful to read, especially how the Doom & Quake engines work.

Want to learn CG? This site is an absolute gem. Written by anonymous programmers who may or may not work for Pixar and other big companies, it even includes a primer on the basic math you need to know to start writing raytracers. All in C++ too.

Also FlipCode, which I'm using to write the semi-software renderer for QRL3D above.
I say "semi" software, because I'm technically using a GL context to provide an easy way of writing pixels to the screen in a simulated limited-color environment.
Screenshots when I remember to bring them home from work.

Recently, I've been playing quite a lot of Guild Wars 2 (somebody bought it for me, and insisted I try it).
I've never really "gotten into" an MMO before, but this one is definitely interesting. Lots of platforming, adventure, dynamic events, and smooth combat. Musical score is decent too. :P

And for those times when I don't feel like playing anything online, I've been playing a ton of heavily modded Minecraft. I've got about 230 mods installed on my main pack, and I'm having fun building virtual server farms. I'm obviously channeling my rage at a work-related thing from a few weeks ago involving a server, a horrible network and other nameless horrors.

At work, when I'm bored and remember that Klondike/Solitaire isn't healthy, I've been playing through Megaman Zero again, as well as Super Mario Bros 3.

The year is just about a third gone. It's scary, because it feels like my birthday in November was just a few days ago. Time flies when you have a job.

I'm thinking of joining both 7DFPS and LD again this year, when they next come around. Assuming I remember, and assuming I have the time. Events tend to conspire to steal time from me just as I'm about to do something I enjoy...

Well, that's enough out of me. Go blog some more you lazy cactus-people.

Unreal Engine 4 Free to all users
Posted on March 03, 2015 at 02:43

Apparently, on Monday, Epic decided to spontaneously drop all subscription fees for everyone, making Unreal Engine 4 free for download and use for anybody.

The only fees still in place are those related to income (After a certain amount of income, you pay Epic 5% of the game's revenue).

Here's the official blog:

I'm gonna get to downloading this when I get home.

In other news, Khronos has just officially announced the successor to OpenGL, to be called Vulkan

64DCG 2015?
Posted on February 27, 2015 at 19:37

Yeah, I'm tired, jumped up on energy drinks and coffee...

Here's a thing:

I have no regrets.
Actually, my only regret is recording that in such a crappy resolution.

Engineering Logs - Singletons Revisited
Posted on February 26, 2015 at 04:28

Now that I have free time again for my own programming projects, I decided to start working on games again, and thus on my game engine.
My current goal is to transfer the gameplay from that puzzle/RPG game that I was working on in collaboration (Which is on halt due to the guy I'm working with being bogged down by the German education system).

So yeah, I'm quietly porting it to C++; we don't want to use GM for it, because it's damned messy.

Anyway, the last blog I wrote about Singletons showed me doing it in the naive way: Manually creating classes 'as' a Singleton type by giving it specific properties.
That works, but is a slog. Wouldn't it be far easier to just inherit some sort of global "Singleton" type and not have to do anything further?
Well, we can. And it's easy too.

There are two methods I'm going to address: One for those who like templates, and one for those who don't.

The Template method
Templates are a very powerful part of the C++ language... but in my personal opinion, they can also be messy, unwieldy abominations that make your code look like it fell part-way into a mincer.
It all depends on how you use them, of course.

Originally, I was just going to write the quick and dirty 'macro' technique, as below, but then on the spur of the moment I added this as an elegant alternative.


template<class ATYPE>
class Singleton {
        static ATYPE & getInstance() {
            static ATYPE singleton_instance;
            return singleton_instance;

And that is pretty much it. Define your classes as such:

class Tester : public Singleton<Tester> {
        Tester(){} // Prevent construction
        void doSomething() { 
            printf("Something is being done\n");

And use it like this:

int main(int argc, char** argv) {

Or, as I like to do it:

#define INST(singleton) (singleton::getInstance())

int main(int argc, char** argv) {

Works like a charm, easy to use, and easy enough to understand.

The Black Magic method (Macros)
First things first, Macros aren't by any means "bad". But there are "bad" ways to use them.
The C Pre-processor is a very powerful tool in the right hands; I use it to process my game scripts (Whether LUA or Squirrel), allowing me to use the ever-useful #include directive, as well as macros.

Macros, when used incorrectly, can cause all kinds of headaches for the developer; so use them at your own risk.

This, however, is an interesting little use for the things.


#define DECL_SINGLETON(stype) static stype & getInstance() { static stype singleton; return singleton; }
#define INST(singleton) ((singleton&) singleton::getInstance())

class Test2 {
        void doSomething() {
            printf("Something else is being done!\n");


int main(int argc, char** argv) { 

Arguments for and against either method
Both of these methods work; they are almost equal in performance, identical in use... it's just a case of how you want to create your singletons.
Personally, I'm a fan of simply inheriting from the Singleton type. It's clean, elegant and easy.

On the other hand, you may be working in an embedded environment where templates may not be supported (Unlikely as that may be. Embedded systems are pretty sophisticated these days). Or, you know, you're using wxWidgets and already have a million macros sprinkled throughout your source.

So basically, flip a coin.

I'll probably be posting a few updates on that game, specifically on the 'porting' process, within a week or two.
Though porting is a bit of a grand word to use; it's like creating a whole new game; I'm just reusing the art and game rules. :P

I did a thing again.
Posted on February 16, 2015 at 11:04

I woke up this morning feeling vaguely down about it being Monday and all (I spent my entire weekend setting up computers; hardly caught a break).
So in a fit of madness, I got up earlier than normal and decided to devote half an hour to doing something.

That something turned out to be a little cover of one of my favorite Megaman tracks.
Working in Famitracker felt a little alien. Haven't touched it since September or so. :P

Engineering Logs - VFS
Posted on January 13, 2015 at 06:57

It's a quiet day at work and I feel like doing something with my time.
So here's the second in a potentially long-lived series of blogs about what I'm doing with my engine.

Just a note, before I start:
These may or may not be the 'best' ways of doing things, but I really don't give a damn. I'll do things as I please, since I'm the one who has to work with the end product.
Everybody is welcome to work in whatever way they think is best. This is my way of working.


In Exile I used a static class called AssetManager that handled all the resources used by the game. This included textures, fonts, music, sound and levels.

The AssetManager class loaded an asset list on startup, which was a file that looked something like this:

# Asset File
TEXTURE ./res/tiles/tex_brick.png BRICK_001
TEXTURE ./res/crosshair.png CROSSHAIR

SOUND ./sfx/enm_hit.wav ENM_HIT

MAP ./maps/E1L1.grv E1L1

This uses a simple parser to read in first a type identifier, then a relative path, and finally an internal identifier that was used in-code to reference the assets.
These are stored in separate lists for each type of asset, and come with associated Getters (GetTexture, GetTexturePAK, GetTextureIndex, etc).

The system worked, but became really difficult to deal with every time I needed to add a new type to the manager.

I did a bit of thinking and decided to implement a simple VFS, or "Virtual File System".

What I wanted was a very simple abstraction that worked with a class called File, of which there were subtypes (TextureFile, SoundFile, and so on).
The VFS manager must maintain a list of all paths from its root, and allow for both a lazy-loading system and for a preload system, with hooks for loading screens if necessary.

With that, I started out with what I believed to be the closest 'skeleton' representation of the VFS class and its methods. VFS is a Singleton, but I'm ignoring the specifics below.


class GSVFS {
        void stageFile(std::string path);
        void preloadFiles(std::function<void ()> loaderCallback);
        GFile& getFile(std::string path); // Will load if not loaded, but its
                                         // best to preload if possible.
        std::string root_path = ".";
        const std::string exclusions = "exe;dll;pak";
        std::map<std::string, GFile> files;
        std::vector<std::string> preload_list;

        void enumuratePaths(); // Recursively scan folders for files.    

This is just a simple representation of what I have. The ability to stage
files for preloading is very useful when you're loading a lot of resources, even small ones.
My actual implementation has quite a few extra management methods (For clearing staged files, unloading loaded files, mostly).

It's quite a simple system, really. The only 'complicated' bit is the enumuratePaths() method. And that isn't really complicated at all. It uses the C library header dirent.h to operate on the directory.
Certain filetypes are excluded (Via the exclusions string).

In addition to handling files on the actual HDD, the VFS class can also manage PAK files. It treats PAK files in a slightly different manner, in that it adds one extra layer to the root path that matches the internal name of the PAK.
This has the interesting side-effect of allowing 'patches' to existing assets.

As an example, if the original release of Exile had utilized this system and I wanted to fix those holes in the maps without having to build and release the entire game again, I'd just release a "patch1.pak" that overwrites the faulty maps.

Additionally, the VFS class also handles general file IO. So writing new files or reading from text/binary files is managed at a relatively low level via this class.

The GFile class

Well, time to discuss the data the VFS actually deals with.
The GFile class is pretty much a wrapped ifstream with a virtual Get method that returns the file contents.

In the case of the plain GFile, it returns a reference to the opened ifstream.
Other variants I use so far are GTextFile (Returns a block of text), GTextureFile (Returns an sf::Texture) and GSoundFile (Returns a pointer to the beginning of a Sound for SFML).

The implementation for each is black-boxed so that the caller doesn't have to worry about how it gets the data, just that it'll get it (Or an exception if the file isn't the correct type).
The VFS class manages instantiating the correct types via a table of lambda functions mapped to extensions.
If an extension isn't covered, the default GFile handler is used.

Well, that's enough of that. I'm going to go find something to do. Work is slow today...

Engineering Logs - Singletons
Posted on January 12, 2015 at 14:40

I'm feeling the need, to write blogs people won't read.

EDIT: Link to Part 2

Over the last year or two, I've been spending a lot of my time working on my ideas as quietly as possible. I have a 'major' game I'm slowly piecing together, bit by little bit.

One of the things that always slows me down is the engine I use for my games. I'm always torn between using an engine like GM, or creating my own.
I always want to create my own for the added benefit of being able to implement things that are unwieldy in GM, or even in Unity.
But as I've been noticing over the course of the last few competitions, I've always started out in C++ and ended up using GM (Or Unity in the case of Project Phoenix).

My work flow tends to involve drawing some initial artwork, and beginning work on the framework I'll be using. What usually happens not long after drawing the artwork is that I start to get anxious with regards to testing mechanical concepts, and seeing my animations in-context.
So I invariably end up just choosing the GM route for a quick game; at least with my competition entries.

In this case, especially with my long-term project (Called Fallen Keep), I've been sticking with C++ for the long haul.
My main reason for this is that it's far easier to express certain pieces of game logic in C++ than it is to fudge it out in GML.

Anyway, I've been working on the latest iteration of "my engine" for quite a long time now. About 18 months ago was when I started working on this game, and the new framework with it.

The engine that powers Exile was my original choice, but I realized shortly that the engine was very much locked in to creating 3D games; 2D games were too unwieldy. Much of the code was modified to fit into what I needed for the game.
If you ever want to see mangled code, give a programmer with nothing better to do a month and a simple 2D game engine, then tell him to make a Hexen clone.

Fallen Keep is 2D, and relies on the Core OpenGL profile for various effects. Exile primarily used Fixed Function OpenGL, and later mixed GL3.2+ features to add the lighting model I used for Abyss.
As a result, the render code is pretty much screwy. Rewriting in this case was the sane choice.

Anyway, enough rambling. I've learned a lot over the past year with regards to quickly implementing a game engine from scratch. A lot of experimentation has gone into this, and I decided to start writing a few pieces on some of the patterns and ideas I've been using for it.

Take everything with a pinch of salt. No doubt some of you will have an alternative, or 'better', way of doing things; that's fine. Discuss it, I'm always interested. :P

Singleton Pattern

This is a mildly polarizing design pattern; some people swear that you should use the things "wherever possible", whereas others insist they be treated as something akin to goto.

My opinion is that they fit the bill perfectly for their intended purpose: To provide the programmer an instance of a class, and only ever that one instance of that class.

Originally, I used to create purely static classes for things like this. The AssetManager class from Exile is an example.
There are downsides along with advantages to static classes, but in the end it boils down to aesthetic for me. I hate using the :: accessor outside of the only context I believe it fits: Namespaces.

Anyway, on to the actual definition of a Singleton.
The Singleton Pattern is a specific manner of coding a class in such a way that you can only ever instantiate a single instance of that class at any given time.

This might sound stupid to some, and in many cases it is. You wouldn't make, say, a GameEntity class a Singleton.

But for some things it provides an elegant solution to the problem of access.
A lot of 'tutorials' I've seen on GameDev and other sites that involve creating game engines tend to either make liberal use of global variables, or pass certain objects as parameters.
Something like this:


// Using some basic SFML code.
#include <SFML/Graphics.hpp>
#include <SFML/Window.hpp>
#include <SFML/System.hpp>

void update(const sf::RenderWindow& window);
void draw(const sf::RenderWindow& window);

int main(int argc, char** argv) {
    sf::RenderWindow *renderWindow = new sf::RenderWindow(sf::VideoMode(640,480));

    sf::Event event;
    while(renderWindow->isOpen()) {
        while(renderWindow->pollEvent(event)) {
            if(event.type == sf::Event::Closed) { renderWindow->close(); }


void update(const sf::RenderWindow& window) {
    // Do stuff, update view, etc

void draw(const sf::RenderWindow& window) {
    // Render game objects

This is a 'flat' example, just here to show the concept I'm talking about. I've seen quite a few "C++" engines that depend heavily on coupling like this (The function definition requires another object to exist, instead of being able to exist on its own).
Decoupling is fairly important to building stable programs, in any given situation.
Some classes and functions are designed to work with each other, but in some cases you're passing references out like candy. Break or change the thing being passed, and you start getting potential cascades of breakages.

The point with the renderWindow variable above is that it's something that will need to be accessed by a large number of classes.
If I was using SFML's built in draw functions, every Drawable object would need a reference to the render window.
And things will get messy very quickly this way.

Static classes alleviate the problem somewhat, but in my opinion are somewhat messy to handle.

So I'll skip those and dive right into the same program segment above, reworked to use a Singleton class.


#include <SFML/Graphics.hpp>
#include <SFML/Window.hpp>
#include <SFML/System.hpp>

#define INSTANCE(singleton) singleton::getInstance() 

class GSWindow { 
        static GSWindow& getInstance() {
            static GSWindow window;
            return window;

        sf::RenderWindow& getRenderWindow() { return *this->renderWindow; }
            this->renderWindow = new sf::RenderWindow(640,480);

        ~GSWindow() {
            delete renderWindow;

        sf::RenderWindow* renderWindow;

void update();
void draw();

int main(int argc, char** argv) {
    sf::Event event;
    while(INSTANCE(GSWindow).getRenderWindow().isOpen()) {
        while(INSTANCE(GSWindow).getRenderWindow().pollEvent(event) {
            // ...   


void update() {

void draw() { 

Longer winded, perhaps, but neater... at least to my eye. :P
And yes, I'm using simple Macro expansion. I could also just call GSWindow::getInstance(), but I prefer the INSTANCE macro to be 'first'; makes it easy to read that I'm using one of the Singleton classes.

The 'creation' of a singleton can be automated somewhat with templates, but I prefer to hand craft them to a degree.

A way of creating something like "INSTANCE()" without using the pre-processor is to create a static method that operates on anything of the Singleton 'type', but I consider it too much work and extra processing to be bothered for the scarce few Singletons I use.

Anyway, back to the subject at hand.
This setup allows for a few things. First of all, clarity. Reading this code in my engine I see immediately that I am using one of the few Singletons I have.
Secondly, I can access everything with a guarantee that everything is initialized and ready to be used.
Thirdly, and class method or function can access and use the instance of GSWindow as long as it 'sees' the class declaration (Normally I'd split that GSWindow class into separate .h .cpp files).

So, a few notes. I only have three major Singletons in my engine, each of which are natural fits for the pattern.
These three Singleton classes are :
GSWindow - Wraps the sf::RenderWindow and associated window functions.
GSVFS - Virtual File System for game resources.
GSTasker - Task management system

The "GS" prefix stands for "Game" and "Singleton".
I had a GSInput class for a while, but decided that it was a poor idea if I ever felt like implementing multi-source input (for local multiplayer), or for input streaming (for demo playback, AI control, or even network play).

A little quirk you'll notice if you stare at the code hard enough is the way I implement getInstance(). I'm specifically taking advantage of the static keywork, initializing an instance of the class (Possibly on the Stack, depending on compiler and what the optimizer feels like doing, so don't get too carefree with them).
When the program ends, this instance falls out of scope and will automatically delete itself. Nifty, as it allows you to 'black box' the details of creating the instance.

Anyway, that's enough rambling for now. Next time I'll write about my VFS system, why I'm using it instead of my old AssetManager system, and maybe some other stuff.
Feel free to argue inefficiencies below; don't get too hard-assed about doing things 'right' though - there isn't any such thing as far as I care. If it allows me to make games, it's right for me.

F4D Progress Blog
Posted on December 19, 2014 at 16:19

I'll post micro-updates here.

I'm making a mini-RPG thingy, because that's what I feel like making.
So far, I've created a character template, and started on an icy dungeon/castle tileset. I'm trying to go for a somewhat SNES/GBA style of art this time round.

Here's what I have so far:

I also have some basic music I've started to hammer out. You can hear it here if you have an NSF player:

Not doing much more tonight; I have work in the morning. :P

Prev Page | Next Page

Recent Activity
Active Users (0)