If you’ve been looking in the comments of the previous post you will probably have seen some screenshots of Dynamite Duke with correct colours.
The source of most of the problems in Dynamite Duke was the strange way in which the background layer was being decoded and handled. The biggest problem is that 1 bit of data for each pixel was being completely overlooked.
Dynamite Duke’s background decode was 5bpp, not 6bpp.
If that was all there was to it then it would have been a very simple fix, however, the problems were deeper than that. Neither of the upper 2 bits of the data are used in the traditional sense, to simply extend the available colour palette.
Ignoring the 6th bit for now, the one that was being used as transparency, I started looking at the bit that wasn’t being decoded, the 5th bit. There was clearly data there, it wasn’t just unused rom as you’ll sometimes find. Infact the data present conincided with the tiles that were being rendered with the wrong colours in the game, logically everything would suggest that the decode was simply missing a bit, and hooking that up should fix the colours as it would then be able to address the correct colours. It didn’t.
Usually if you increase the bpp of a set of graphics it allows the colours directly after the current palette to be addressed in addition to the ones already being used. For Dynamite Duke something different was going on.
Regular System
4bpp decode | Pal#1 Colours 0-15, Pal #2 Colours 16-31, Pal #3 Colours 32-47
5bpp decode | Pal#1 Colours 0-31, Pal #2 Colours 32-63, Pal #3 Colours 64-95
for Dynamite Duke however
5bpp decode | Pal#1 Colours 0-15 & 256-271, Pal #2 Colours 16-31 & 272-287 etc.
Basically the extra bit is being used by the hardware more as a palette bank bit, grabbing the extra colours from a completely different part of the palette.
I needed to clean up the driver a bit, remove some palette hacks that were already in there, and rework a few things, but by implementing that logic I at least got the right colours on all the scenes, except one, the map scene. For the map scene it turns out there was another error in the driver. As the previous decode didn’t allow for accessing of colours above 255 one of the layer disable bits had been incorrectly hooked up as a palette bank, probably because the map screen happened to have that layer disabled and also by chance needed the higher palette codes. An easy mistake to make. Removing that hack, and correclty hooking up the layer disables had the advantage of also getting rid of some garbage sprites left on the screen during ‘continue’ etc.
That just left the 6th bit, marked as transparency. Finding out the use for that was pretty straightforward, it quickly became clear that it was actually a priority bit (which is basically how it was being used anyway ‘transparency’ was rather misleading)
With everything fixed up Dynamite Duke looks better than ever, and one of the longest standing bugs that I can remember has finally been fixed.
