Back to coding DefenderDS after a break of just over two months. Think I ran out of steam for a while, and I’m trying to get back into it now.
First thing I’ve done is sort out the explosion creation/destruction object initialisation. The explosions weren’t getting destroyed once they’d played, in order to reduce the amount of work done each time they were shown. The problem with this is that each explosion consumes around 12 sprites. If we have 8 landers, 4 pods, the player’s ship, 4 player bullets, a dozen enemy bullets and a dozen humans in a level, we’ve already used up 41 sprites. 25 of those have explosion objects, which gives us around 300 explosion sprites hanging around in memory for no reason. As the DS can only work with 127 sprites at once (I say “only”, but to put it into perspective I think the Amiga had 8 hardware sprites), it obviously wasn’t going to work.
Explosions are now destroyed and created when they are needed, which should prevent us from ever hitting the sprite limit.
I’ve tidied up the mountain code. Previously, I was passing a pointer to the mountain data into the game object’s constructor, which in turn passed it to the mountain drawing object and the scanner. This is clearly bonkers, as it is much easier just to #include the mountain data in the files containing those two classes.
Finally, I’m putting some thought into the way the scanner, mountain and game objects are created. They are currently created as standard objects, but I think a singleton pattern would probably be a better solution. How many scanners am I likely to create simultaneously? How many games do I want to run at the same time? The answer to both is just one, so it doesn’t make much sense to have to pass pointers around when using the singleton pattern would be much easier.
I can see why I’ve written it the way it is at the moment. I’ve spent far too much time developing web systems and so have become instinctively suspicious of using static members, methods or classes. In a web system, be it PHP or .NET, anything marked as static is shared across the entire application, not just the current session. Websites are multi-user, so if user A sets a static property, user B will see the same value. Should user B set it to something else and user A attempt to retrieve the property, they will be given the new value, not the value they set it to.
In DS development, though, this isn’t a concern. There will only ever be one instance of Defender running on the DS, and only one user will ever be playing it. Makes things easier.