Cartridges and Bullet Time!

It's been a very busy week with a lot of good progress. The game is starting to take shape now and so the ideas are coming to me faster than I can implement. 

Cartridge Support

Before moving any further with the code I decided to take a step back, do some refactoring and get the code loading from a cartridge format. The gmod2 cartridge gives me 64 banks of 8k for a total of 512Kb as well as 2Kb of eeprom for use with save games, this fits the bill perfectly as currently a level stage size is around 16Kb for the map data (unique per stage) and 16Kb for the VIC bank data (unique per world) so if I have 2 stages per world and 5 worlds that's still only 240Kb which leaves plenty of room for level data sizes to grow if need be, shared code and additional asset space I may require for doing things like bosses, intro and completion screens.

With this in mind I set about reorganising my memory map to make more efficient use of the banks. Using a cart means having to copy some code from the first cartridge bank to RAM somewhere to enable banking and copying code into memory from the other cartridge banks. So to enable this I copy this code to $0400.  The remaining code and assets are organised from $0500 onwards.

Originally I had planned to try and use $8000-$a000 for the unrolled map code as this is where the gmod2 banks in to. This would have allowed me to fully unroll the code and bank in the correct code for whichever of the 8 directions is required rather than use a partly unrolled version. The result of this would have been using  LDA/STA pairs in absolute mode rather than having to use indexed Y mode for a saving of about 12 raster lines which is no insignificant amount and would have helped with NTSC support (still no clue if NTSC will be possible or not). However the problem with this is that to make it work I have to set the interrupt disable flag, otherwise the kernel at $e000 starts doing odd things when banked in with the cartridge. This in turn would mean that during the map shift operation no dynamic IRQ could fire which would break sprite multiplexing, the timeline effect and HUD split, an absolute no no, so this idea had to be dropped.

I still may use the banking to switch out sprites during timeline transition and at the very least will definitely be using it to swap out stuff for boss fights. Either way I'm happy that I have cart support as this is the media I was always most interested in aiming for. I'm trying to think of some good uses for the on cartridge eeprom save, currently I'm thinking of collectables and achievements to add replay value.


I want Doc to have a gun in the sequel and have already given his sprite the update to add the weapon in his hands. But until this week he was unable to actual shoot it. I made the decision quite early on to make Docs bullets use characters rather than sprites to allow the multiplexer to be used mostly for enemies (more enemies = more fun, right?). This however poses a few technical problems:

Firstly there is the issue of the double buffering. If we were to just draw and update the bullets on the active buffer and ignore the back buffer, we would end up copying the bullets to both buffers and end up with bullet chars stuck all over the place. The solution here is quite simple. Whenever the screen data is copied between buffers the bullet chars first need to be cleared and then when the copy is complete they can be redrawn back to the screen. Likewise the same needs to happen before and after switching the buffers.

Secondly as the bullets are chars they will replace the chars at the positions on screen. This means that at all times the bullets need to know what char was originally under its location and what color it was, so that when the clear and redraw explained above happens, it is done correctly. 

Finally this method of using chars also means that there can be a large cutout around the bullet, if its background color does not match that of the map position it sits at:

Notice in the screenshot above that when the bullets pass over the red part of the background they are surrounded by a black square. I managed to solve this by using a multi color bullet character, using MC1 and MC2 for the actual bullet and then using foreground color to fill in the empty space. The code will then set this foreground color according to the color of the original char under the bullet.

With the bullets in and functioning correctly the final piece is to make sure they are removed when they leave the screen either by themselves or as a result of the player scrolling them off. And also to make sure that the bullets are also removed when they hit something solid. In the second case we want the bullets to leave behind a kind of splash animation:

Finally this week I've been tidying up the scroll and collision code. This is going to be an ongoing task as its all central to the feel of the game, and after all its the feel of the game that's the most important bit to get right, even the best ideas can be let down by horrific control schemes or janky graphics. No video this week as there's just not enough new stuff to see, but hopefully by next week I can get the map object sprites system in place and be able to show that.

Leave a comment

Log in with to leave a comment.