This week in gamedev #5

I’ve been posting on Twitter, because after the Brick Rick: Graveyard Shift release I went back to engage; but that will stop and return to very low intensity –I don’t even have a Twitter client on my phone–, because I haven’t changed my mind.

So that means one thing: it is Thursday and that here comes another gamedev update!

ubox MSX lib release

This is a maintenance release that basically fixes a potential problem when changing song with the play function being active in the interrupt handler.

I have used that same code in several games, and you only need to be a bit careful and wait for vsync before changing the song, to ensure that the code will finish before being interrupted. Given that this is a library for others to use, I have decided that it makes more sense to avoid interrupts explicitly.

I had the change in the repo for a while, and I still have a couple of things in my TODO, but the fix deserves a release just in case there is someone out there working on a game.

Targeting the ZX Spectrum 48K

When I was working on “Graveyard Shift” I half added support for 48K games, only that… it wasn’t really working.

The library I wrote for Brick Rick on the speccy is for the 128K models only because it uses double buffer by hardware (and therefore, memory banks), so a lot of code targets 0xc000 as video memory instead of 0x4000.

I have reviewed that code and made a few things configurable:

• By disabling the 128K support, all the tables are using the 48K memory addresses; and the bank changing code won’t work –48K models anyway–.
• The interrupt setup code is now fully configurable, so for example the 257 bytes table for the Z80’s IM 2 can be located at a high address (on the 128K models can’t be over 0xc000 because of the banks).

At the moment the same library can be configured at compilation time to target 128K or 48K, which is perfect.

I have a work in progress memory map that should work great for 48K games:

This leaves probably too much memory for the library and the stack, but for now I think is fine. I may move non speed-sensitive library code to that 0xf900 address, so I have more space for the game itself.

In my TODO there is also some sort of support to build a 128K version of the game, that should be the same game but adding AY sound. I’m not a fan of that, because I prefer to offer the same experience in all models, but people expect AY sound in 128K models, even if the game is targeting 48K. For now this is low priority, but it shouldn’t be too difficult.

I have a few possible ideas for the game, although it doesn’t need to be necessarily a ZX Spectrum 48K game. In reality I could jump directly into making the game, without having to write any new library code, if I was using my Amstrad CPC or MSX libraries, but I still want to make a speccy game on 48K, so there’s also that!