LP's 12 Months of Games // Alien Invaders Part 2 [C++ & SFML]

Completed Independently

In part 1, I got a basic game loop going and you could shoot invaders as they descended upon you. In part 2 there's now shields, sounds and a flying saucer!

It's almost there but there's still some bugs and finishing touches such as:

• Background music. The famous "dun dun dun dun" has not been implemented as I haven't managed to recreate the sounds to a satisfactory standard and increasing the step as you destroy invaders is a task in itself as I'm not a sound engineer person.
• The arcade style surrounding and background as well as the CRT shader. A colleague showed me a different way to implement the disintegration effect using shaders so I'll be implementing that as well as messing around with some other shader effects.
• 2 Player mode
• Demo mode
• Taito Cop Easter Egg
• Different Invader shots. Right now they're all just using 1 shot and will fire every couple of seconds or so. That needs changing.
• The flying saucer is every 3 seconds which isn't correct. I haven't figured out from the assembly yet though what the actual timing mechanic is for it to appear.
• The Credit Inserted and Start Game animations haven't been created.
• The states don't really play with each other nicely
• Bugs

I'm shocked that the original developer managed to create this game in a year but not just the game; he also built the hardware that the game ran on. This is a level of engineering that I can only dream of reaching. 

Result:

It doesn't look like much but I'm quite proud of myself for sticking to a project and getting it to a somewhat finished state. That in itself is an achievement for me. I am feeling a bit burnt out on SFML though having done 5 back-to-back projects with it and I'm looking forward to a bit of Unreal and Blueprints for the next project.

This is far from over though. I have a new project now to recreate Space Invaders with as many APIs as I can. Making it that first time though is the kicker; now it's almost out of the way, I can focus on refining the code and then re-implementing it using other libraries.

Code:

https://github.com/l-paz91/AlienInvaders2/tree/main/AlienInvaders2

The code is quite honestly, awful in places lol. But I don't care. I think that's one of the hardest lessons I've learnt whilst doing this exercise; just do it and worry about how shit your code is when it's done. I do enjoy refactoring and optimising but they don't help you get a project finished.

LP's 12 Months of Games // Alien Invaders Part 1 [C++ & SFML]

Completed Independently

So the final game of "Beginning C++ Games Programming" by John Horton was a clone of "Space Invaders". I skimmed the first chapter of the project and he starts talking about Entity component systems, Factory class designs etc and I just completely zoned out and decided to make it myself. 

This took me a while as Back 4 Blood added an offline mode and there's nothing quite like hitting zombies with a baseball bat. Also the Witcher season 2 and Lost In Space season 3.

So anyway, I kept getting annoyed with myself whilst making this game; I was trying to make the code as beautiful as possible right off the bat; which is impossible unless your Bjarne or Scott Meyers or something. I asked many colleagues how they would go about implementing Space Invaders and amusingly, the more senior the engineer the more the answer became "just do it all in main, who cares?"

So, I've written some terribly hacky code that only gets worse as time goes on but I have a game! This is labelled part 1 because it's not finished however, there is a title screen, a game and a game over. It saves the high score between runs and loops after game over so it is a game...regardless of how finished.

I'm quite into the task now and the shields are ready to be implemented, as are the sounds. Then the flying saucer needs some attention as do the shot exploding animations but then I'll have a full Space Invaders clone!

I've given myself a few little extras that involve creating a CRT shader and making it look as though you're playing the game on an arcade machine.

Result:

I'm extremely happy with what I've done so far. I'm really trying my best to make it look and feel exactly like the original. I'm going so far as implementing the same bugs using this site which comments all the assembly:

https://www.computerarcheology.com/Arcade/SpaceInvaders/

There are some issues which you may have already noticed; my game over text isn't displaying and the high score isn't updating. That will be fixed next but the code is in place.

I just really wanted to get something uploaded for this month and I've already learnt so much from attempting to do this by myself. I'm glad I ignored the book as this game is deceptively hard but a great place to start when making a complete game from scratch for the first time.

I almost gave up a couple weeks ago as I find it difficult to find the motivation to finish things. I have about 70 started projects but I thought to myself, the whole point of this challenge is to get better at making games and I won't get better if I don't at least try! So I managed to scrape the code together enough to call it a "game".

It also made me realise that I hate UI programming with a burning passion.

Code:

https://github.com/l-paz91/AlienInvaders2/tree/main/AlienInvaders2

C++ & SFML // Creating The Disintegrating Shields in Space invaders

Whilst making a clone of Space Invaders, I got to the point where I had to make the shields. They are interesting as only parts of them get destroyed when hit by bullets:

The damage done to the shields is based on the type of bullet and where they hit. It reminds me of the old Worms and Lemmings games that have disintegrating terrain due to explosions.

The player's shot and 2 of the invader shots deal the same type of damage. However the "plunger" looking invader shot is the most powerful and deals more damage. Therefore, having the shields as sprites make no sense as you can't manipulate the pixels in a sprite, so I started looking into ways to draw and modify pixels in SFML as well as do per-pixel collisions.

I eventually came across this post:

https://en.sfml-dev.org/forums/index.php?topic=23869.0

This seems super long winded for what I want as it copies the image from the gpu into an array of pixels, then you modify those pixels and then send that array back to the texture. But it's also the closest to how the original game implements the shields (in a way).

I then found this after googling "sfml array of pixels":

https://www.sfml-dev.org/tutorials/2.1/graphics-vertex-array.php

I was able to write a program that can draw individual pixels to the screen:

https://github.com/l-paz91/SFML/blob/main/Drawing%20Individual%20Pixels/main.cpp

This is more along the lines of what I wanted, as I could now simply create a vector of vertices in the shape of the shield. SFML already provides this type called VertexArray which can be passed directly to a RenderWindow's draw call.

Here's a simple program I wrote that uses a VertexArray to create a rectangle with a gradient fill:

https://github.com/l-paz91/SFML/tree/main/Drawing%20Multiple%20Pixels%20To%20The%20Screen

In my version, the shields are 66x48 pixels, with each vertex needing 4 uint8's of data (RGBA), so that means I need to supply 12,672 uint8's and I don't really want to type that out. So I had to start looking for a way to read in that data from something. SFML does not provide a way to convert textures or images to VertexArrays. I can get the pixel colour data by using the first method and copying the texture to an image but that doesn't provide pixel positions (which a vertex wants). So I wrote a method to combine the two. 

It creates a temporary texture, copies the texture to an image then loops through every pixel, pushing back a new Vertex after all 4 pieces of the pixel have been collected. The positions are calculated using an offset from the top left hand corner. So after 66 vertices have been pushed back, the y co-ord is shifted down 1 pixel. However there is still a glaring problem with this method; I have 4 arrays containing 3168 elements.

So I went back to the drawing board and found this post:

https://en.sfml-dev.org/forums/index.php?topic=7427.0

Using the code from Laurent (the developer of SFML) I managed to write a program that creates a "mask" from a png and uses that to turn pixels transparent:

https://github.com/l-paz91/SFML/tree/main/Using%20A%20PNG%20Image%20As%20A%20Mask

Armed with this knowledge I then set about creating a cannon that fires lasers at the doge image to destroy it:

The next issue to solve was the per-pixel collisions as the laser was still colliding with the bounding box of the sprite. I hackily solved this by writing a very simple collision check:

https://github.com/l-paz91/SFML/tree/main/Sprite%20Disintegration

First, it only does a per-pixel check if the laser has collided with the bounding box of doge. Then, it checks to see if 3 spots on the laser have hit solid pixels. If they're all transparent then the laser can pass through.

This isn't perfect, but it's good enough.

C++ & SFML // Simple Event Queue System with Timings

In a previous post (C++ & SFML // Simple Timer), I showed how you can create a simple timing system in SFML to display messages on the screen.

In this one I created a very simple "Messaging Dispatcher" that receives messages and displays them. I followed along with the Ring Buffer design by Robert Nystrom in "Game Programming Patterns" to create this little demonstration.

https://gameprogrammingpatterns.com/event-queue.html

Here, when E is released, it fires a message to the dispatcher. Each message has a random time to display between 1 and 4 seconds.

The code can be found here:

https://github.com/l-paz91/SFML/tree/main/Simple%20Message%20Dispatcher

There are a few caveats with this simple system:

• The queue is a fixed size so it will reject messages when full,
• The queue doesn't create an empty slot until the top message has finished displaying; if this was set to display for 5 minutes and all the other messages in the queue only want to display for 1 second, the queue will be held up waiting for the top message to finish.
• The dispatcher shouldn't really be handling the time.
• Everything is passed by value.

All these things are fixable with some brain power but getting the first implementation out of the way is key to figuring the fixes out. For the next step, it would make sense to create a class that handles the updating and displaying of the messages that it receives from the dispatcher. This way the dispatcher only has to worry about getting the messages to the right place each update.

As the class is static, you could have anything send messages to the dispatcher. it could also be modified to display sprites or play sounds (although I would define a set of events as enums instead of sending the sprite/sound itself).

The code may look a little odd in the dispatcher but the above link to the chapter in Robert's book explains what it's doing far better than I will be able to.

C++ & SFML // Simple Timer

So I'm currently working my way through making a clone of Space Invaders using SFML and I got to the point where I needed to do something after X amount of seconds. Usually I use FLTK and that would've been simple using it's callback system however SFML is event based and as such doesn't really supply a "timer system" out of the bag like fltk.

Therefore I googled and eventually found pieces of what I was looking for and managed to put this simple demonstration together for those who just want to figure out how to get seconds displayed on the screen. This is what the "tutorial" will give you:

The program does 2 things:

1) Display the number of seconds since the program started

2) Every second it chooses a random message (from 4) to display.

Very exciting. Let's begin.

Here is the full code:

https://github.com/l-paz91/SFML/tree/main/Simple%20Timer

Have a look, it's all in main for simplicity. 

There is a clock that is restarted at the beginning of the main loop and assigned to DeltaTime.

SFML have handily provided a way to get the DeltaTime as seconds. All you have to do then is += that to a variable defined outside the loop and you have your seconds since the program started.

For the text, I just made a variable that holds the max time we want to show the text for (maxDelay) and another variable to hold the elapsedTime. Getting the elapsed time is the same as getting the seconds above only when updating which message to display, there is a check to see if the elapsed time has gone above the max delay. If so, it changes the message and resets the elapsed time back to zero.

The concepts here can be used for many other things like displaying a sprite for a given amount of time as well creating more complicated things, like an event queue system that dispatches events based on the elapsed time (much more useful for larger projects than above).

Check out this post: C++ & SFML // Simple Event Queue System with Timings

for an example on how this can be put together.

LP's 12 Months of Games // Thomas Was Late [C++ & SFML]

Completed Via Tutorial

The 4th game taught in "Beginning C++ Games Programming" by John Horton and there are some more things I found strange:

• The engine class had 4 functions but only the constructor and 1 other function were defined in the cpp; the others were given their own cpp file....I have honestly never seen this. I can understand wanting to keep the code "manageable" but just collapse the function? There are class definitions in Unreal Engine thousands of lines long. If you're having trouble use Alt+G to directly go to the function or just Shift+F and search.
• The private const member variables in classes. If they're private, they can only be used within the class anyway so move them out of the class and into a private namespace in the cpp. Those variables are padding out the size of the class; all those bytes add up; especially if you are creating many instances of the class (as games often do). The const variables in the namespace will still be static but at least they're only being created once instead however many times you have created instances of the class they were in.
• There are also other implications on your classes to do with move/copy constuctors caused by const members.
• I've also seen some "Variable const x", especially in function argument parameters. Yes the compiler will accept it but it's good practice when declaring a const variable to have the const before the type. You may see const after a function declaration but that is promising that function doesn't modify any member variables inside the function. The const before the function return type specifies that return value cannot be modified.
• The given code doesn't actually work or compile. 
• Pointer pointers were introduced....in a book aimed at those who have never programmed before....I have no words. I know you can't create a 2d array without using values defined at compile time but that's because it's an array; just use a vector. This is not Beginning C Games Programming.
• The LevelManager should be holding an instance of the level vector array, this eliminates the need to new anything up. In the original code the pointer is returned to a different class. If it has to be a pointer at least ensure that whatever is holding the pointer frees it properly in the destructor (or better yet, use smart pointers).
• He includes headers in cpp's that have already been included in the matching header file.

I will admit, I did find this funny though:

Finished Result:

The tutorial spanned from chapters 14 - 18 and I stopped halfway through 17 because the game is severely broken:

I don't have time to get this working nor do I really care. There was something going on with the drawing and ordering of the sprites vs the background. Left and right were only for the green shape, A and D were for the red. It knew this when input was received yet for some reason it decided to apply the updates to some other sprite.

There's only space invaders left now which should be more fun; this one was a bit dry.

Code:

No code drop for this one. The authors repository for the book is here though:

https://github.com/PacktPublishing/Beginning-Cpp-Game-Programming-Second-Edition

LP's 12 Months of Games // Zombie Arena [C++ & SFML]

Completed Via Tutorial

Another tutorial finished from "Beginning C++ Games Programming" by John Horton. 

Please do not use this book to learn C++. Some things boggled the mind when following this tutorial like:

• variable + 0 (???)
• Creating a header, only for it to contain functions that are neither marked as extern or static or within a namespace. One function returns a raw pointer which is deleted somewhere else...
• #pragma once #ifndef #define combo (pick one. I like ifndef define because it's slightly more portable).
• Constant float to int/int to float with no casting or safety in place. For example, he'll choose to make an int variable but only use it with a float???
• Singleton classes. Don't get me wrong, I like singletons but this is not the best way to do it. The constructor should be private with copy and assignment deleted. There should instead be a static public function that declares and returns a reference to a static instance of the class to ensure it is destroyed properly.
• Member functions that don't modify are not marked as const nor is anything returned by const reference if it can be.
• Initialises class members in the constructor body instead of via initialiser list; this causes the member variable to be default initialised and then assigned again.
• Const member variables are initialised in the class body definition??? static const integral types yes, but otherwise for linking sake, it's best to initialise const members in the constructor.

One thing that really bugged me was all the event handling for input was done in main. I am a firm believer that objects should handle input events themselves. That said, the author promised at the end of this game that there will be better code handling in the next two projects so I'll hold further judgement until I finish the book.

Finished Result:

I was having fun with this one by the end. I quite like "Demakes" and I think this style would make a good Left 4 Dead demake. The hitboxes on the zombies are a bit janky and I'd like some background music but other than that I'm actually pretty happy with this one. 

It taught some solid SFML concepts that I can take away to personal projects. I'm itching now to start Tetris or my own version of pong to apply what I've learnt but I'm going to finish the book first as he mentioned using more advanced sound features, particle effects an split-screen in the upcoming chapters.

Code:

https://github.com/l-paz91/ZombieArena

There's a code drop for this one as I feel I changed it enough. Assets haven't been included for copyright reasons but here is the authors repository:
https://github.com/PacktPublishing/Beginning-Cpp-Game-Programming-Second-Edition

LP's 12 Months of Games // Basic Pong [C++ & SFML]

Completed Via Tutorial 

This is the second project taught in "Beginning C++ Games Programming" by John Horton. The two chapters mainly focused on teaching classes and multiple files so the actual pong game was lacking.

Finished Result:

The "bat" is far to quick and moves off the sides. The ball scrapes along the bat or becomes stuck resulting in ridiculous scores and there's no states like a menu or game over. The basics are there though but I'll be improving this over the next week to add better collision, sounds and "english" (where the ball bounces off the bat with a certain velocity) as well as multiplayer.

I did finally learn how to use Github with Visual Studio though in this exercise. It's quite painless once you get used to it. I still prefer Perforce but for project sharing/collaboration, Github is the clear winner. That won't stop me from using Perforce though.

Code:

I modified the code in the book however it's mainly from the tutorial so I won't be posting. The next Pong game I will though.

LP's 12 Months of Games // Timber!! [C++ & SFML]

Completed via Tutorial

I started a book called "Beginning C++ Games Programming" by John Horton. It's aimed at those who've never used C++ before and teaches you how to make 5 games using SFML. I thought this would be the perfect introduction to SFML as I could ignore the bits about C++ and focus on the library. I was right.

I've just completed the first game; Timber!! I've used sfml once, many years ago to try and make pong. At the time I had been learning cpp for about 6 months and found it utterly confusing. This time, thanks to experience with FLTK and DirectX it was more "ah so this is how I get a sprite, this is how I draw it, this is how you poll events" etc.

I'd say this project would take a while for a complete C++ beginner but it was perfect to showcase on how to get to grips with sfml. I'm looking forward to the other 4 games and learning other sfml features.

As for the tutorial itself; I don't like the amount of hardcoded numbers and the fullscreen game (I prefer windowed when debugging). All the textures rely on the screen being a certain size as well but I can remedy that in my own projects. Also, the author is extremely bias to arrays and OOP with the code being very java-ry. I wouldn't recommend the book for first time C++ programmers as I feel it would teach some bad habits; make sure you use Principles & Practice for cpp.

Finished Result:

The assets were all provided by the book and I made a few adjustments to the code but other than that it's pretty much what the book gives.

I will say I'm extremely surprised by just how easy SFML actually is to use. I'm already formulating how to get a tetris game working or match 3 from just doing this simple game. So I guess it was a good tutorial overall.

Code:

A code drop will not be provided for this one as it's mainly from the book.

C++ & FLTK // Adding Simple "Sprite" Support

This isn't really a tutorial, more of a "hey, I wanted to add 'sprites' to my FLTK build, how would I do that?"

For those of you new to my blog, I've been working my way through Bjarne Stroustrup's Practice & Principles using C++ in which there are several chapters focused on graphics programming. For this he supplies a couple of helper files that wrap some fltk features in a "higher level bow" so to speak. Over the months I've been editing these quite a bit to create my own shapes and add other functionality.

After these graphics chapters ended, I started to wonder if I could make a 2d engine using fltk and what does every good 2d engine need? Sprite support.

After an hour of tinkering, I had achieved this:

Very exciting. I'd like to note, this did not capture well and it kind of looks like there's a slight stall after a few frames but when running the program it's fine.

So I first went about this by creating a new simple window that supports "ticking". It has a quit button and a tick function that's registered with fltk's callback system to run every 0.1 seconds.

Then I made a new class called Sprite which inherits from the Shape class. I soon learnt that Shape is great for basic stuff, but when you want to start doing event based game stuff, the way shapes are drawn and updated is kind of clunky so I need to re-do shapes. But for now I worked round it.

So a Sprite takes in a point to draw from the top left-hand corner, a file name, frame width, frame height and the number of rows in the spritesheet; kind of reaching for the moment as it can't deal with sprites with multiple rows just yet.

The Sprite itself is just an Fl_Image that holds the png "spritesheet". This was mine:

It's the coin blocks from Super Mario World. When attaching this image to the window, obviously the entire image was displayed. Sprites should be able to only display a certain portion or 'frame' of their spritesheet, so I made a function called drawFrame() that takes in a frame number. This frame number is stored and used in draw_lines() to display a particular part of the image. This is the annoying part of using a Shape; I must override draw_lines() and use that to draw. 

To only display a certain part of the image, you can just use built-in functionality of Fl_Image. The draw() function allows you to specify a part of the image to draw by passing in the top left corner locations and an offset. This essentially "crops" the image to the size given. The width and height is then multiplied by the frame number each frame to advance it to the next image:

Here, my spritesheet is 200x400 pixels with each block being 40x40. Therefore, to play an animation, fltk is told to start at frame 0 and increase by 1 each frame until it hits 3, then go back to 0. This stops it from showing the brown block, which is frame number 4.

So to show the second image block, it would do 40 * 1, which is 40. This gives an x offset of 40. Then the x and y coordinates of the new cropped image are obtained by getting the top left of the full sprite sheet (I set it to 50, 50) then adding on the offset; making the new draw point 90, 50. The draw() function is handy though as it can display the cropped image in the same position as the last through the first two parameters. The Y offset is ignored right now as we don't have multiple rows.

It's also important that post increment is used here. I usually detest using post++, however here it is necessary as the current frame needs to be drawn before it's incremented. If it was ++frame, then the next frame would be drawn as it's incremented before use.

And that's pretty much it for creating the most basic of basic sprite systems for FLTK. I have plans to rewrite the shape class so I have full control over how they're drawn.

You can find the full code for this project here along with a project file:

https://github.com/l-paz91/FLTK-Projects/tree/main/SimpleSpriteClass