#100DaysOfCode

Day 1:I’ve been working on a program to access longform texts with a shortcut over the past few days. E.g. Type ‘awesome’ to access ‘programming is awesome, I really love it’. Currently it’s a console app in c++, using an unordered map to save the shortcuts and longforms as key/value pairs. This is then written to a txt file so the entries are stored across sessions. It copies the longform to the clipboard (on Windows) when you successfully search for a shortcut, allowing you to immediately paste it into your document. There is an option to print all the pairs out and you can clear all the entries as well. I think in the future it will probably work better as a web app in JS, but I just wanted to see if it was easy to do for now.

GitHub and Android

I like the idea of open source software and of giving away your work for free so all around you can enjoy it and so it was a sad moment when I decided to take down my source code files from my downloads page. I just didn’t feel there was any way to take credit for the work (in whatever form that is) and couldn’t stand the idea of someone taking it and claiming it as their’s.

Thankfully Linus Torvalds is a very clever man with the best of intentions and so stands GitHub, a place for coders to upload their source code for all the world to see for nothing but a place where it can be seen to be yours. Hence I have now signed myself up an account and uploaded my source code to Brick Buster, Flood Fill, Simon and Bomber Run. Peruse them, download them, fork them, do as you wish with them. Have fun!

 

In other news, smartphones are quite popular these days I think we can all agree. There are well over half a billion Android devices activated and last quarter nearly 50m iPhones alone were sold. With Windows Phone also apparently showing strongly and Blackberry 10 joining the market in the near future the future is mobile (as the cliche goes). So with the writing on the wall, you’d have to be a mug to go into programming these days without out some exposure to programming on these devices. I, unfortunately, don’t have access to a Mac or Windows 8 so that knocks out the prospect of developing for iOS or WP8 and with Blackberry 10 not out yet it would seem that I’m left with Android. Easily the largest mobile OS on the planet, it is also the most fragmented with nearly half the users running Android Gingerbread, an OS over 2 years old.

So it was with trepidation that I set out to find a library to help me along my way but I shouldn’t have been so worried. I came across Andengine first on my travels and gave that a few days of toil before losing all faith in it’s ability to create games using anything but a singleton design and packed it in. I then moved on to libGDX and I couldn’t be happier. It’s a lot more hands off then Andengine and lets you create your own game loop, whilst still providing a huge amount of back end functionality (loading and playing a sound effect can be done in one line each, incomparable to C++!). Again I’ve found a good site with useful tutorials, this time provided by Steigert (with  free source code on Google Code too!), but most importantly the documentation and wiki provided by the libGDX team is unparalleled. There are Javadocs, a wiki, a simple game example that builds an entire working game and a whole raft of tests to look at (and borrow code from!). You just cannot go wrong with this library, incredible stuff. Be warned though, it is still in very active development and they’re releasing nightly versions fixing bugs, so development can be a bit of a moving target from the tutorials and code. Nothing that a good google search and stackoverflow can’t normally solve though.

libGDX also provides another benefit, you can test your game as a Java application instead of having to launch the emulator and wait for that to process and then lag. It makes testing so much quicker and allows you to make small changes and test them quickly. It also generates an HTML5 version of your software as well and is incredibly versatile and extensible. An A* library if ever I saw one. If you’re thinking of developing for Android, it’s definitely the way to go

The re-emergence of smart pointers

Somehow I managed to miss the fact that Microsoft had actually implemented smart pointers in VS2012 and was working back with raw pointers everywhere in my code. This mean writing a lot of delete statements and ensuring that resources were being freed properly.

Not any more! Now I’ve finally tagged on to the blindingly obvious (why would Herb Sutter be talking about smart pointers and modern C++ so much if MSVC didn’t support it, how comes everyone at StackOverflow said use smart pointers when most newbies probably learn with MSVC, why were there so many docs mentioning it at MSDN etc etc) I felt the need to modernise my code. Now I’ve used smart pointers before, back on GCC 4.7 with Code::Blocks, but I was convinced I wasn’t using them correctly so I set off for some basics on best practices. After a few searches on Google and StackOverflow, I came across a link to the MSDN docs on smart pointers. This page contains explanations on each version, example code for how to implement them and then has links to more detailed explanations on unique_ptr, shared_ptr and weak_ptr all of which also contain exemplar code.

Taking this on board I set out to update my code. First up was finding where I could implement unique_ptr. These are members of a class that are not called or accessed from outside of the class, they are unique to the object that they belong to. Using my Flood Fill game as my test project, the first member I figured was best as a unique_ptr was the board contained in the Level class. This is not accessed by any other classes and is not passed to any other classes (as a whole, Squares contained within it are passed around however). The colorChooser vector of Squares is also never accessed from outside the class so can be a vector<unique_ptr<Square>>. The only other pointer that I was able to make into a unique_ptr was the StateMachine in Engine.

Shared_ptrs will therefore be prevalent in my code. All of my GameTextures are created as shared_ptr<GameTexture> and passed around by value, letting the reference counting do the job of managing their deletion (when the program ends and the MediaCache destroys their relevant xCache). In the Board class, the board itself is a vector<shared_ptr<Square>> because different classes try to access the individual squares (i.e. to change their colour in the floodfill algorithm). Within the StateMachine class, the currentState is a shared_ptr<State> because the Engine class accesses it to call the various functions to run the game.

Creation of unique_ptr is still handled through the use of new and the unique_ptr constructor, i.e.

board(std::unique_ptr<Board>(new Board(20, 20)))

I would love to move to Herb Sutter’s make_unique function, but at the moment it isn’t supported by VC110, so we have to make do with this.

Creation of shared_ptr is however handled through the use of make_shared<T>, i.e.

auto gt = std::make_shared<GameTexture>(tex);

Reasoning for this is given here on Herb Sutter’s blog – essentially it’s making the code more efficient by keeping the memory for the shared_ptr and the shared_ptrs reference counting in the same memory block and creating them in one go instead of two. With auto saving us the effort of writing std::shared_ptr<GameTexture> on the LHS of the assignment operator, this is one big, beautiful c++11 line taking in a variety of the new features.

The only items left that are raw pointers are SDL specific – SDL_Renderer, SDL_Window, TTF_Font* – for which it makes no sense to wrap them in smart pointers, because they have their own, SDL specific, destroy function that needs to be called at the end of their lifetime.

State Design Pattern

Ever since I started building games, back at the start of 2012, I’ve been using a fairly cumbersome Finite State Machine to switch states. This involved the use of a StateManager class to keep track of the current state I’m in, combined with a switch statement of varying size (depending on the number of states in the game) to switch between the different states. This was a fairly good design in my eyes, but I always knew there was a better way to do it through usage of the State Pattern. This would ideally mean that to change states all I’d need was to call a changeState function that took a pointer to the new state and deleted the old state.

After plenty of searching through Google, gamedev, stackoverflow, GameDevNet et al, I finally stumbled across a tutorial that explained the idea and provided enough concrete examples for me to build my own system off the back of it. Given the new found freedom of a programming a new engine in SDL 2.0, I took this idea and ran with it.

So now my State class now has these 5 pure virtual functions:

virtual void enter(Engine* engine) = 0;
 virtual void handleEvents(SDL_Event& e, Engine* engine) = 0;
 virtual void update(const double dTime, Engine* engine) = 0;
 virtual void render() = 0;
 virtual void exit(Engine* engine) = 0;

These obviously all have to be overridden in any derived classes, such as Title, Level and GameOver. The Engine*’s are used for calling the changeState function that is inside the Engine class (actually the StateMachine class, but it is called from the Engine class). Enter and exit are called at the start and end of the class’ lifetime to perform any special functions that are needed.

Keeping track of the currentState that the game is in is no longer controlled by the Engine class itself, but is now operated by a StateMachine class, which is much like the StateManager class I used to operate (in some ways). The StateMachine class is very simple:

void setCurrentState(State* s) ;

State* currentState() const;

void changeState(State* newState);

One to set the currentState, one to return it and one to change it. ChangeState isn’t even a difficult function:

if(typeid(*mCurrentState) == typeid(*newState))
 {
delete newState;
return;
 }

mCurrentState->exit(mOwner);

delete mCurrentState;

mCurrentState = newState;

mCurrentState->enter(mOwner);

The first if statement stops us from changing from the state we’re in to the state we’re already in, using a wonderful feature I’d never encountered before in C++, RTTI (run time type information). This can work out what type a variable is whilst the program is running. For our pointers to State, we have to dereference them to find out what they’re actually pointing to. This little bit of code is put in because in the Engine class when we press the Esc key it changes state to the Title state, but if we’re already there there is no point in creating a new instance of it. We then exit the currentState, delete it, assign the newState to it and finally enter the state.

The Engine class then contains a StateMachine* within it, which is initialized in the body of the constructor (as we’re passing the “this” pointer into the constructor we can’t assign it in the initializer list) and the currentState is set. To change state from, say, the Title to the Level we can call one line of code, which is in the mouseClicked() function for Title:

engine->changeState(new Level(mediaCache));

No calls to any external classes are needed, there is no need for a big switch statement to take place, the Engine which seamlessly switch from the Title to the Level and all will be good with the world. Any other states that are introduced won’t mean having to rewrite the StateManage enum and extending the switch statement in the FSM, we can just create a different State* instead, i.e.

engine->changeState(new HighScore(mediaCache));

//or maybe...

engine->changeState(new GameOver(mediaCache));

Downloads update

There’s finally been an update over on the downloads page, one that’s been needed for a while. I removed all traces of my source code, so they’re not for download any more. The links won’t even work any more because they’re no longer in my dropbox account. I’ve instead just got release versions of the games zipped up with the dll’s and the fonts/images/levels etc required for each game.

There are also two new games and an updated version of another:

Flood Fill – You have to turn the entire board into the same colour, see how few moves you can complete it in!

Simon – Everyone’s favourite memory game. There are only 4 buttons, but for how long can you remember the correct sequence?

Bomber Run has been massively updated. The game now starts with 15 houses and increases to 25 through the first 5 levels, the plane lands and crashes with (some basic) animation, the sounds have been updated to play properly, there is a pause and mute option, the plane has been modified to resemble a Tiger Moth and the biggest change of all – animated clouds have been added!

Head to the downloads page where you can play the above as well as Pong, Brick Buster, Aliens and Blackjack.

Introducing FontCache, TextCache and MediaCache

In what I’ll now call GameEngine v1.0, I loaded all my images, text and fonts from one place. This worked well but something wasn’t quite right with calling imgCache.getFont(50) – why would I go to a cache of images to load a font? So given the freedom of SDL 2.0 and noting that “modern c++” (and programming in general) revolves around large classes being built from small, single purpose classes I broke ImageCache up into 3 smaller classes. ImageCache itself remains but it’s now only for loading images (duh!), FontCache is for loading fonts and TextCache is for loading text. To bring all of these 3 new classes together I created the MediaCache. (If I can build SDL_Mixer 2.0 at some point in the future, my AudioCache will sit inside the MediaCache as well). This means that the vast majority of MediaCache functions are just calling functions from one of the contained classes. i.e.

GameTexture* MediaCache::getImage(std::string file)
{
return imgCache.getImage(file);
}

The getImage() function in MediaCache calls the ImageCache function of the same name.

You’ll notice the function returns a GameTexture*. A GameTexture is a small wrapper around an SDL_Texture that also knows of it’s width and height, using SDL_QueryTexture in it’s constructor

GameTexture::GameTexture(SDL_Texture* texture) : tex(texture)

{

SDL_QueryTexture(tex, NULL, NULL, &mWidth, &mHeight);

}

The main reason for setting this up was so I could centre an SDL_Texture on the screen easily. It’s proved a bit of a boon as now when the object’s destructor is called, SDL_DestroyTexture() now deletes the texture from memory, making memory management a little easier.

Rendering is now all done through one function, renderTexture, which takes an x and y position and a GameTexture* and renders the GT at (x,y).

The rest of the MediaCache is as it was in the old ImageCache with functions to centre horizontally and vertically, clearScreen and updateScreen functions to take care of updating the screen, drawRectangle to render any SDL_Rects and scrWidth and scrHeight to access the private variables.

SDL 2.0

I’ve used SDL for a while now, coming up on a year, and almost every recent question that I read regarding 1.2 (the latest “stable” release of the library) on forums suggests that users move over to SDL 2.0. Seeing that there is only source code available for the library at the moment and not a pre built binary, I’ve held off from upgrading. But recently having come to a bit of an end with my development path, I took the jump to setup SDL 2.0.

The big news? It’s easy. Like really, ridiculously easy. Download and install mercurial (there’s a link at the top of the SDL HG page), then from the command line run “hg clone http://hg.libsdl.org/SDL&#8221;. This will download the various files used for the making of SDL into whichever folder you run the command from.  The best bit is that the code is in Visual Studio   solutions (going back a few versions and including 2012). This means that to build the library you just build the solution like you would any other. Once this is done, you can go and find the dll and lib files, get the src code from your folder and organise them on your hard drive to give your SDL 2.0. Easy.

Of course, SDL isn’t really finished until you have the various other libraries that come along with it (ttf, image, mixer, net) and these are easy to download as well: from the command line, run “hg clone http://hg.libsdl.org/SDL_ttf&#8221; or “hg clone http://hg.libsdl.org/SDL_image&#8221; etc, then build as before. In no time at all you can be on the flash new API.

So now you’re running SDL 2.0, unforunately your code won’t port straight across. Bit of a bummer, but not the end of the world. It’s not a whole lot of effort rewriting it and things will be easier on the new version (in my opinion). To this end I found a great tutorial over at Twinklebeardev which is up to date and explains things from the bottom up.

What are the advantages of SDL 2.0? Hardware accelerated textures (SDL_Texture), a window and rendering context which allow for multiple screens (SDL_Window, SDL_Renderer) and better OpenGL support (although I’m leaning towards GLFW for that at the moment). Have at it and see how you get on. I’ve enjoyed the new version and not found any bugs at all.

So to celebrate, I rewrote my game engine! I broke ImageCache up into 3 smaller classes, got rid of SDL_Surfaces and replaced them with SDL_Textures and introduced the state design pattern (finally!). All to come in a future post…

Using the STL pt. 2

So having covered a better way to remove and erase items from a container, there are a couple of other ways that I’ve leveraged the stl to improve my game.

One is through using std::copy to write out to a file, instead of using an iterator and a for loop. So for instance the old way I used to write out to a file was

Std::ofstream outf("high scores.txt");

for(std::vector::iterator it = hiscores.begin(); it != hiscores.begin() + 8; ++it)
{
    Outf << (*it) << std::endl;
}

Which wrote out the first 8 elements of the hiscores vector to the high scores file (at the end of a game, after the users score had been added into the vector and sorted). This worked fine but I came to realise that there was a better way after a bit of exploration on StackOverflow. So the code now reads like this

Std::ofstream outf("high scores.txt");

Std::copy(hiscores.begin(), hiscores.begin()+8, std::ostream_iterator(outf, “\n”));

Which to my eyes looks a lot nicer and can be optimised by std::copy.

Within the original for loop I also used to check to see if the user had a new high score with a basic if statement. With that for loop now gone I obviously need to put that check back in elsewhere and to do that I’ve used std::for_each, as below

Std::for_each(hiscores.begin(), hiscores.begin()+8, [this](int i){ checkNewHighScore(i); });

//outside, as a separate function
Void GameOver::checkNewHighScore(int i)
{
    If(player.getTotalScore() == I)
    {
        NewHighScore = true;
    }
}

With newhighscore being a bool contained within GameOver. For_each is using a lambda function to capture the int in hiscores that the iterator in for_each is currently pointing at and then passes that int into checkNewHighScore. All contained in one easy to read line of code.

The final example of using the stl in my GameOver class relates to using std::sort (I’m not sure how I only managed to reference one function in this post, especially as I’m referencing the use of the various stl algorithms in the reverse order to which they’re called!). Obviously once a user has achieved a score that is added into the high scores table and then we reorder the scores around it. I could have done this myself, but why bother when the stl has done it already and implemented it. I used to call this with a lambda function, but recently found a call that would do the ordering correctly for me, std::greater

Std::sort(hiscores.begin(), hiscores.end(), std::greater());

And that’s it, my high scores are ordered from biggest to smallest, at which point I can start finding out if the user has a new high score and writing them back out to the high scores file.

Using the STL properly

So in my quest to learn C++ and perfect the code that my games are running, I’ve come across a lot of people who say that most C++ programmers are just writing C with classes and one of the best ways to take advantage of the language is to use the STL. The main reasoning is that the STL was written by the best minds in programming and has been made as efficient as possible, so using them will almost always be quicker than writing your own loops.

Take for instance removing objects from a vector. In my code there was a lot of this kind of code:

for(std::vector<Object*>::iterator i = objects.begin(); i != objects.end();)
{
    //process the objects

    if((*i)->isDead())
    {
        delete *i;
        i = objects.erase(i);
    }
    else
    {
        ++i;
    }
}

Which I used to think was really efficient, looked quite organised and was easy to follow. Unfortunately, it’s not that efficient at all. Whenever erase is called, every member of the vector that is after the element erased has to be moved up one space to fill in the gap. In my ParticleEngine class I’m managing 400 particles, of which 40 are going to be dead at any one time. That means that 40 times in one pass through that for loop a couple of hundred objects are having to be reassigned positions in memory, which is obviously going to be a massive slowdown and hog on performance. This was showing itself up in rudimentary testing when I’d see a jump in CPU usage on task manager whenever a ParticleEngine was called into being.

Needless to say I’ve now found a better way and the worst part is that the answer was under my nose the whole time. Scott Meyers’ book Effective STL documents the best way to erase elements from a container and needless to say, it isn’t the way above. He recommends using std::remove followed by the container’s erase member function. std::remove takes the elements to be removed and moves them to the end of the vector, returning an iterator to the end of the range that are not to be removed (or the beginning of the range of elements that are to be removed). Erase then uses this as it’s starting point and erases all elements from this point to the end of the original container. So how do we know which elements to remove/erase is the next question, leading on to another neat trick from Meyers’ book. Any pointers that aren’t needed any more can be deleted and set to NULL, that way all we have to look for is NULL pointers and mark all of these for erasing. Hence the following code can now replace the above:

void processObject(Object* o)
{
    //process o

    if(o->isDead())
    {
        delete o;
        o = NULL;
    }
}

//go through objects, processing each one
std::for_each(objects.begin(), objects.end(), processObject);

//remove any NULL Object*, then erase them from objects
objects.erase( std::remove(objects.begin(), objects.end(), static_cast<Object*>(NULL)), objects.end() );

This code requires one loop through the container for for_each, another for remove and then a loop through however many objects are to be erased. So for my ParticleEngine example, I’ve gone from reorganising a vector of 400 items up to 40 times a loop to once in std::remove. Much quicker and nicer.

Visual Studio and moving away from C++11

As someone who’s interested in acquiring a job in programming in the near future, I recently came to the conclusion that I should probably create a few demo projects that can be sent in with job applications. As the industry is unlikely to be at the cutting edge of compilers, thanks to established code bases, and probably even less likely to be using the GCC compiler, I made a move over to Microsoft Visual Studio. To ensure the code worked, this meant a move away from all my C++11 code – the removal of smart pointers, the auto keyword, range based for loops, member initialization in header files and others.

To start this off I chose to work once again on my Brick Buster project, thinking that my knowledge of the code and it’s (relative) brevity would enable the process. The first thing to be removed was member initialization in header files, which meant a return to long constructor initialization lists. The move away from C++11 also meant losing delegating constructors, so I had to rewrite my Ball class. This actually helped clean the code up as I went from three to 2 constructors.

The next step was to remove all traces of smart pointers, a task that I thought would be arduous at best and fatal to stability at worst. In reality it was remarkably simple – I removed each smart pointer one at a time, compiling after each batch of changes to ensure that the code still worked. The only really tricky change came in the Game class where the currentState pointer had to be changed from a unique_ptr to a GameState*, which had a knock on effect for my FSM. In the end I decided to pass a reference to the currentState into the FSM, which would delete it and return a new GameState* which could be assigned to currentState:

currentState = FSM::changeState(currentState, player, imgCache, stateMan);

Of course the major fallout from the loss of smart pointers is memory management. Making sure that the correct delete call is placed everywhere it is required is not an easy task and led to my destructors increasing in size from nothing to multiple lines. To counteract the repetition of for loops containing delete and erase instructions for vectors, I wrote a template deleting function which will work with any container that has an iterator:

template <typename T>
void deletePtrCntr(T& cntr) const
{
    for(typename T::iterator it = cntr.begin(); it != cntr.end();)
    {
        delete *it;
        it = cntr.erase(it);
    }
}

Next step was the auto keyword. Now I love the auto keyword, it makes writing iterators infinitely quicker (4 chars vs 25+) and easier and allows the user of std::pair in a much nicer way. However, with the loss of C++11 they were written out and replaced by their verbose C++03 counterparts. As part of this removal, range based for loops disappeared from the code as well, rewritten back to the same standard as every other for loop.

One thing that almost got forgotten in the change over was enum classes. I have two of these in Brick Buster: one for the states and one for the power ups. The reason I use them is to give them their own type (instead of returning an int from a function, I can return a State or a GamePowerUp) and to keep the namespace pollution down (instead of calling my enum members STATE_TITLE, I can call them through State::Title or GamePowerUp::BigBall), both brilliant additions in my opinion. However if these were to be removed it would mean renaming the members to make it more obvious, or so I thought until I had the brainwave to put them inside their own namespaces so that they can still be called through State::Title or GamePowerUp::Multiball. Of course any function that previously returned a State or GamePowerUp had to be changed to return an int, but this was a minor change that caused almost no nuisance.

Of course as with all code rewrites, improvements are made to the codebase and it now looks a lot more organised. I’ve changed (back) to references from pointers in my base GameState class on the basis that none of the classes should ever be NULL as they are constructed before any GameState is ever created. This makes things slightly easier, removing the need for pointer dereferencing and -> everywhere.

To make the code portable, I put the SDL files inside the project and pointed the linker at the relevant folders so that anyone can compile the game on their computer if they have VS. This has given me the incentive and knowledge to go an rewrite my other games for VS and hopefully they won’t take to long to complete either.

The Brick Buster for MS VS10 is on the downloads page