I released this at EXACTLY the same time as CPCWiki went down so I never got to talk about the technical details. The code uses a lot of exact timing so once again I unintentionally made a test for emulators, as I find out when people post videos of it looking wrong…
I removed the Extra Sugar modes because all those scoreboards and achievements were designed for a disk-based system that would save your progress. So I thought, I will set it up to play like the arcade game and just have one score table to keep it simple for a cartridge.
Then shortly before the game was done the PicoGX was given the ability to read/write to the SD card so I added high score saving at the last minute. I think it would have been the first game to use this feature if the Bloodwych mod hadn’t beat me to it. So, maybe I could consider putting the Extra Sugar content back in but I would have to redraw all the new backgrounds I made for Extra Sugar, which only exist in 4 colours. And to be honest not that many people have downloaded Bomb Jack GX compared to Extra Sugar which is interesting.
Memory map is completely different and a lot of code had to be tweaked to remove self-modifying stuff so it could run from ROM. Screen doesn’t need to be double buffered any more thanks to hardware sprites and most code runs from ROM, so 64k is more than enough RAM. And the ROM is only 128k so again, plenty of room.
The background pictures obviously are in Mode 0 this time and actually use more colours than the arcade because I used anti-aliasing/blending wherever I could to try to make them look a bit less chungus in Mode 0. They were all touched up by hand. They also use colour splits where possible to get more than 16 colours. Or 12 colours, since the platforms always take up 4.
The interrupt system is way more complicated than Extra Sugar but the game structure was way easier to write thanks to the PRI, which might be the GX’s most underrated feature. Any timing-critical code was put on the interrupt chain which made everything so much simpler, and tidier.
Sprite code was all completely redone to use hardware sprites. The game needs a maximum of 12 sprites for game objects (1 player + 9 enemies + P ball + B coin). I was worried about how much time it would take to update the asic to animate them, since sprite memory isn’t indexed (which is so annoying). So to make them go faster, the sprite data is all compiled sprites and where possible stored as a delta, ie only the pixels which are different from the previous sprite are changed. The enemy animations all work this way, and they take turns updating, 4 at a time. So in fact sprite updating is done quite quickly, usually before the visible frame has started drawing. And the game logic was already fast, so the game runs at 50hz comfortably.
More time was burned on the sprite multiplexing which was again handled by the interrupt. After the game objects, I had 4 more sprites left over and I wanted to multiplex them into 24 bombs. This is a piece of cake when they’re stacked vertically, but the trouble is there can be as many as 7 bombs on a line. So, whenever there are more than 4 the game does a tricky horizontal multiplexing where the sprites are moved back and forth every scanline so they appear twice. This requires precise timing and is one point of failure for emulators.
The rainbow meter at the top of the screen is also made from two of the bomb sprites. These are quickly redrawn into bombs in the time between the top display ending and the playfield beginning. So the game often has more than 30 sprites on screen at a time and can have more than 16 sprites on a line. Can’t do that on a Master System or NES.
The extra lives at the bottom of the screen are not sprites but are done with colour splits like Extra Sugar does.
The title screen is a completely different solution to the same problem - I want the logo to be high res but you need at least 7 colours to draw it, and they can’t be split easily. This time I had hardware sprites on my side, but the lettering is too big to cover entirely with hardware sprites. So I ended up drawing the logo in mode 1 using two shades of blue, black and orange, and the lettering is covered with a strategic arrangement of hardware sprites combined with colour splits on the orange channel. It rewrites two of the hardware sprites while it’s doing this, so 18 sprites in total are used. Again this requires precise timing, so again this is something that doesn’t look 100% correct in all emulators.
Apart from that it all came together pretty quickly. The GX is fun and still has a lot of untapped potential.
