It’s again time to defend earth against alien invasion with the SDL2 version of the Space Invaders! As previously, I decided to re-implemented my HTML5 version of the game into a SDL2 (C++) application to see how some new important features (like pixel wise collision detection) could be implemented with different technique and environment. The basis of the game is quite similar to the HTML5 version described in HTML5-Space-Invaders.

At the beginning…

Again, it was easy to split the application into reasonable classes as it was already done in the HTML5 version. I did a bit further split with some game elements like alien shots. HTML5 version handled shot specific details directly within the in-game state, which made some unnecessary code bloat to in-game update function. Now I decided to encapsulate those details into shot specific classes so they can be more easily examined.

Game structure

The game structure was a quite similar than the HTML5 version, but some minor differences that where required by the SDL2 framework. One of the most important change was the way how pixel precise collision detection and pixel re-coloring works.

To edit SDL2 textures, I needed to build a locking structure that locks the texture so it can be edited. After the texture is edited, it must be freed so it can be used by other systems. I somehow managed to get this working by building a quite simple structure that actually seems to work. However, I’m quite sure that my implementation could be better formed so it would split the operation into much more logical steps. Now, the whole shield to laser/missile detection and pixel edit functionality is all included in a single place. This is a quite ugly way to perform it, but I’ll try to accept that…. Perhaps…


This implementation actually took me a much more time that I was expecting. It was quite interesting to note how much easier it is to perform pixel wise collision detection and editing in the HTML5 than in the SDL2 (C++) environment. Luckily, many games do not require this kind of collision detection as we have a quite nice set of all kinds of bounding volumes (e.g. AABBs) that we can use to perform optimized detection without iterating over the whole set of pixels.

Thanks for reading!

Game source code in GitHub:Β


8 thoughts on “SDL2-Space-Invaders

  1. Hi,

    Many thanks for this nice Space Invader example. Especially the pixelwise collision detection, which no open source clone I looked up today in the Net had implemented, is interesting for me. I just compiled the SDL game myself and it workes fine first… but after some time of playing and (rapidly) shooting invaders suddenly no shooting is possible any more. Also I am wondering, why you allow the player to move more far left and right than the invader, which was quite opposite implemented in the original game (in your game the defender can just move very much left or right and no invader shot can reach him). When the game ends the program freezes, would be nice if it would return to the intro menu.


    1. Hi Frank,

      Thanks for the feedback!

      You’re right about the ending of the game. It would be better to end the game by returning to the intro menu like those old arcade games typically do. This was also something that I had in my mind but somehow I managed to forget to implement it. I’ll put this to my todo-list.

      You’re also right about the avatar position / invader movement restrictions. My version does now actually provide a kind of “safe” zone where alien missiles cannot hit the player. It seems that I wasn’t studying the original game well enough πŸ™‚ I also think that my both versions (i.e. SDL2 and HTML5) have this behavior. I’ll put this into my todo-list as well.

      That bug with the shooting sounds strange. I’ll try to check what could be causing that behavior and get back to this.


    2. I think I managed to find the source and fix the shooting bug. The bug was related how the game was using the “rest” mode. This “rest” mode is used to add a small delay to game logic and is being activated when the player gets exploded. During this “rest” time, the missiles, player laser and the flying saucer still keep on moving across the scene. However, most parts of the actual gameplay logic is being frozen. This frozen section also included all collision detection code, which made missiles, player lasers and the flying saucer to continue their journey without being exploded by any out-of-bounds detectors. I fixed that by moving the corresponding collision detection code so it is being executed even when the game is in “rest” mode.

      I also restricted the movement of the avatar to correspond to the area that is used by the aliens. There should not be any safe zones anymore πŸ™‚

      I also managed to add a support to return from the in-game state back to the welcome state after the game is finished.


  2. Hi Joni,

    Many thanks for your explanations and the very rapid bug fixes. I just downloaded your updated SDL source code, compiled it and enjoyed playing the game.

    Actually your game is more challenging than the original game (which I just played for comparison using Mame). I did not manage to get beyond level 1, but ok, it is quite late now and the beer and… perhaps tomorrow I will be more lucky πŸ˜‰

    The reason that your game is more challenging is that the invaders come down much faster than in level 1 of the original game. One reason for that is that they do not move far enough to the left and to the right border of the screen. In the original game they move so much left that I cannot shoot the invader any more when it is in the most left (or most right) position. Nevertheless the player has also in the original game a “save” position – but only when the game starts, and only because the invaders are in the process moving to the right when the game starts while the player is in its most left position (but which is not the most left position of the invaders).

    What I somehow miss is that the number of points I earn when I shoot down the red spaceship are not displayed. In the original game they are displayed in red color directly at the place where the red spaceship did vanish.

    I found a bug when the invaders move very much down. In the original game, when the invaders are so much down that they touch the shields they eradicate the shields where they touch them (little bit like lawn mowers ;-)). In your game the invaders do not collide with the shields. Instead they vanish behind the shield sprites. Not sure if that can easily be fixed.


    1. That’s true. Aliens should actually “eat” those shields when they hit’em. This was one of those things that I left out for a purpose. This was mainly to keep the implementation more simpler (or I was just lazy). For the same reason, I also excluded the sprites describing the number of points received from the flying saucers.

      Again, many thanks for the feedback! If I remember correctly, those things need a bit more work that I’m currently able to reserve for this project. Perhaps I could try and return to implement those features when I have more time… If that ever happens…


  3. P. S.: Regarding the shooting down of the red spaceship. I think in the original game the number of points the player earns is related to the number of shoots he has fired between the start of the game and the last shooting down of the red spaceship (or the start of the game)… but I am not a good enough player to use this feature πŸ˜‰


    1. You’re right. In fact, I used that site as the blueprint to implement some parts of the game. For example, the order of where the alien missiles are being shot is implemented kind of same way than what’s described in that site. I also added a similar kind of shot counter, that tracks (or at least should track) the avatar’s shot count and uses it to resolve the amount of points received from the red flying saucer. The point table (with 15 entries) and it’s usage can be located within the flying_saucer.cpp file. The points are queried from a simple lookup table with the amount of player shots modulo 15. It should act in quite similar way that what is described in the computer archeology site, but of course there might some slight differences.

      btw. I actually did recommend that site in my first post about the HTML5 version of the game ( It sure does contain other cool game and application reverse engineering and explanations as well.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s