Feeds:
Posts
Comments

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

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.

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.

Follow

Get every new post delivered to your Inbox.