Part 10 – Bases and their destruction!

In this article we look at adding the player bases (defensive structures). Again we are not looking a line by line account, but rather an overview of what’s been done. As always a companion video is available on youtube:

Bases need to be destroyed – The problem with Adafruit_GFX.h
As you probably know these bases need to be destroyed in a bit-by-bit style either by the Invaders or the player shooting into them. But herein lies the problem. Take a look at the definition for the base (or any other graphic)

This uses the compiler directive PROGMEM, this was mentioned in an earlier article on graphics and it allows us to store our data in the Atmel processors (used by Arduino) program memory rather than the usual data memory. This is very important in games on the Arduino due to the very limited data memory available (2Kb). We have 32Kb of program memory and it would be far better to store these large data items in there if we can. And so far that is what we’ve done and no problems.  If these bases were not damageable, i.e. never changing we would use this method, but each one on the screen can have bits of it removed when hit and in different ways. With PROGMEM once something is stored in there it cannot be changed by your code, only by re-programming by the usual interface. So we cannot just alter the graphic during run-time.

Choices for destruction
So we could actually store different versions of a destroyed base in PROGMEM and display which ever was appropriate depending on the damage inflicted. However this is a valid method when you have only a few permutations of the graphic. For these bases there will be a wide variety of different damage, far too many to store a different graphic for each possible looking damaged base.

So we have no choice, we have to store the graphic in normal dynamic RAM (all 2K of it!). In this way we can alter whatever parts of the graphic are destroyed. We will still store our original base graphic in program memory (unchanging) and just make new copies of it for each base at the bottom for each new level. When I was developing this part I was unsure if I would have enough memory in RAM but after implementing I did, phew!

 Adafruit_GFX
There was another issue though, the Adafruit graphics library we use will only work with graphics stored in program memory by the PROGEM directive. So I had to add a new routine that could display graphics from dynamic memory. This has been forked on GitHub and is also available on this website. More on that later.

The base structure
Below is the new structure for a base

As is usual we use the GameObjectStruct structure to give the item positional information, and then in addition we have some memory reserved for the graphic (16 bytes in total). This is the size of the base graphic just above which is stored in program memory for our code to copy from into this dynamic memory that we can change.  The function below handles this task and is called when a new level is started.

We can see we have a #define NUM_BASES for the number of bases on screen. The code then spaces them out evenly on the screen (the “i” loop) and the “DataIdx” loop copies the graphics data in program memory into the Gfx array in dynamic memory.

Base Collisions
This is quite a complex piece of code as we have to destroy bits of a base at pixel level and those pixels are stored in various bytes in the base graphics. It is only complex because of this pixel level destruction on a graphic whose pixels are part of a byte. Apart from this it is relativly straight forward. The three routines that handle collisions are

BombAndBasesCollisionMissileAndBasesCollisions and AlienAndBaseCollisions

BombAndBasesCollisionMissileAndBasesCollisions
These are virtually identical apart from one destroys the base from top to bottom and the other from the bottom up. Which ever it is the routine randomly decides how deep to go (up or down) and how much side-wards damage is done on the way down (again randomly). In the real arcade this was not so random as it had three slightly different missiles which penetrated to different amounts (and also travelled at different speeds). But I have not implemented it this way in this version, but it plays virtually the same.

AlienAndBaseCollisions
This handles collisions between Invaders and the bases. As an Invader collides bits of a base are removed.

The altered AdaFruit_Gfx
It is very important that before you put the new code on your Arduino that you add the altered AdaFruit library. Otherwise you will probably forget and wonder why things don’t quite look right. The easiest way to do this is to replace the file in your library folder with the new one linked just below.

Adafruit-GFX-Library-master

To do this open up your Arduino folder, the one where your programs are stored (on windows it will probably be called Arduino and be in the MyDocuments folder).  Within this you will see a “libraries” folder and within this (provided you have been following these tutorials) will be the folder Adafruit-GFX-Library-master. Delete this and then extract the contents of the zip folder just above into the libraries folder.

If you haven’t been following this series and you have never installed the Adafruit-GFX-Library-master library then ensure you first do so by looking at the guide to hooking up the 128×64 oled screen used in this project, see here. Then come back to this page.

The Code
Now you are ready to copy and paste the code below into your Invaders project and upload.

The next article/episode will be the penultimate one where we will add sound to our game. See you next time!