I posted a big update tonight - I've been working on the game off and on over the year. I only recently noticed that it has been nearly a year.
Quite a lot of little tweaks that were fun to do. I'm still playing with the weapons systems, but I think I came up with a power-up scheme (not implemented yet) that I like, which will be a little more Raiden-like, rather than just swapping weapons as today.
I had fun with some animation enhancement. The mines now have flashing lights at their tips -- to do this I used the one unused enemy sprite. Every game frame it cycles to the next enemy in the table. If that enemy is a mine, it overlays it, if not, it is offscreen. The effect is that each mine gets blinking lights.
Bosses by far saw the most enhancement. The boss explosions do a little macross-inpired animation now instead of being static, which makes it more interesting to look at. Beyond that, the tricky part is that they move smoothly horizontally, rather than per character.
Smoothly here means with 2 pixel resolution. They accelerate per level - meaning the last two bosses are moving per character anyway for the most part. The way it's done is pretty simple -- there are 4 character pattern tables loaded into the VDP. When the boss graphics are decompressed, they are shifted two pixels into each pattern table. When we are moving the boss, then, we just change the pattern table appropriately for a free shift of up to 6 pixels. When it actually changes character position, then we redraw.
I was worried about the damage patterns when the boss is shot. This updated data is shifted in real time and all tables are updated. Luckily, it appears to keep up.
The real problem was the loading phase. It takes a notable amount of time to pre-shift all the boss graphics, and I don't have space to keep them all loaded. A 'BOSS APPROACHING' phase was added to cover this up. During this time, the player's ship is centered, and enemies are made to leave the screen. In the background, the boss graphics are being pre-shifted. When it's done, then the boss can arrive.
I was also able to remove a lot of old, messy code, and fix up a lot of silly functions. I removed all the hard-coded delays I found, and replaced them with VDP timing loops. Also, many of the original functions were from the TI's c99 graphics library, which attempted to emulate Extended BASIC. As a result, pretty much everything was 1-based instead of 0-based. I did away with that. I also wrote my own code for most of the hardware access for better control of the system, since a lot of it is just as good inline.
I was also able to use the above tweaks to take control of the framerate. Due to somewhat unpredictable code paths (and those hard-coded delay loops), the code's performance varied a lot. It's now fairly solid. I ran the game at 20fps so that I could divide the workload among 3 different tasks, every 60th of a second.
The vblank handling uses my technique (dissed elsewhere) of masking VDP interrupts until you are ready to process them. This eliminates the need for a variable to check whether a VDP interrupt happened when you were not ready for it (not to mention all the code needed to set and later check it). This is the way TI programmers have handled it for 30 years now -- with the exception that the 9900 has a CPU instruction for it, and so on the Coleco we have to use a two byte sequence to the VDP register. This is slightly racey so does require some consideration about timing... but so does accessing the VDP anytime outside of the interrupt on the Coleco with interrupts left enabled, so I don't feel too bad.
Hope you enjoy! It's shaping up to closer to what it should have been twenty years ago!