I took a break from the Amiga development this week, mainly because I was ill and didn't feel like taking on the 3D collision detection and physics implementations. So why not tackle something on a completely unfamiliar platform instead?

Anyone for Rogue Declan on the Sega MegaDrive? Mega Declan!

I already had SGDK set up, via MARSDEV as I'm on macOS, with a sprinkling of CMake so I can use CLion IDE, and launching my ROM into BlastEm compiled from source. Which was all a bit of work. Next was just dropping in a lot of the Amiga source code and commenting out huge chunks to get it to compile and start, in whatever form, in the emulator.

MegaDrive rendering is very different from the Amiga (no, it's true!) and there was a mismatch between how the game was structured and how sprites neede to be fed into SGDK. I had to set them up as a dummy sprite that could be initialised with the proper image later, but this caused some confusion (and crashes) because - turns out - SGDK doesn't like rendering an entirely blank sprite. I suspect it gets optimised away to nothing or something like that and invalid data comes to exist. Anyway, starting the dummy sprites in a hidden state fixed that.

More confusing crashes followed that I eventually traced down in the SGDK source code, sort of. It sets a default stack size of 512 bytes which was about four times too small for the game and took a recompile to change. Hurrah for open source though.

With the crashes sorted out and a selected few entities merrily firing sprites into SGDK's sprite engine, this happened.

First SpritesFirst Sprites

Getting it looking better and moving sensibly wasn't too bad.

More entities and correct coloursMore entities and correct colours

However, the MegaDrive has a distinctly non-mega 64Kb of RAM available, and the procedural dungeons on Rogue Declan use up to around 95Kb on the Amiga. Something needed to go on a diet.

Fortunately, I'd previously done some experimental work to reduce the procgen memory footprint (not used in the end), but even after merging all that in to the MegaDrive code it wasn't enough to allow the largest dungeons to generate reliably. After sleeping on it, I had an idea to allow two kinda-duplicated tile arrays to share memory, saving about 5Kb. Filthy hack, but it worked. There's about 7Kb RAM free now when a large dungeon is running and hopefully that is enough.

A bit more bashing and floors were in. There's actually an awful lot of the game working to get it this far, which is encouraging.

Now with Floor TechnologyNow with Floor Technology

Walls, however, are another story.

The Amiga version builds up wall images from smaller images in layers directly in the screen memory, depending on the surrounding tiles. With the MegaDrive hardware this is much more difficult as it doesn't have directly addressable screen memory. I think there are 1024 possible combinations for any given 16x16 tile, but the console works with 8x8 tiles and perhaps that will make the numbers more manageable with (again, I think) 16 combinations for each of the four 8x8 tiles in one 16x16 wall space. This is the next thing I'll look at.

MegaDrive development is an itch I've wanted to scratch for a while. I have a basic knowledge of the hardware now, even with SGDK obscuring much of the nitty gritty. The hardware is good at what it does but quickly becomes awkward if you want to colour outside the lines as Rogue Declan does. I can see squeezing everything though two 64Kb memory windows becoming kind of a pain too.

Mega Declan will take ages.

Related Links