One of the problems with CannonBall feature development is that many of the remaining tasks are hard to achieve. Take the music selection screen for example; it's one of the parts of the game that isn't widescreen and remains letterboxed.
Now it would be easy to simply drop in a replacement graphic at this point and bypass the original code to display it. In fact many people have sent me such an image over the last couple of years in the hope I would do just that. But that's not really true to the ethos of what CannonBall is about. The real solution is to extend the original tilemap and use the tile layer to render the screen, rather than hack in a replacement.
Unfortunately, this approach needs a full tile editing tool, which is a rather complex way of achieving something that will look no different to the end user. Nevertheless, I'm writing such a tool so that tilemaps can be edited, new tiles created and the screen finally widened.
It was a lot of work for something that looks simple. One of the complications with the System 16 tilemap format is that bits have a shared usage, that I'd previously overlooked. After all, the complications of it don't really matter when simply rendering existing data. For example a typical word of the tilemap is configured as follows:
MSB LSB
---nnnnnnnnnnnnn Tile index (0-8191)
---ccccccc------ Palette (0-127)
p--------------- Priority flag
-??------------- Unused
As the index and palette share bits, this locks tiles to certain palettes dependent on their index. Therefore the previously identified unused tiles are not usable. Instead the new tiles end up being scattered through the tilemap from location 4096 onwards. I also had to create new palette entries to map to these tiles.
This explains why Sega games have tile duplication, where the same tiles appear multiple times in the graphic roms. It enables them to be used with multiple palettes. In practice I can't help but think it would have been simpler to double the tilemap memory, thus giving the palettes their own distinct bitrange and avoiding tile duplications. I guess this may have been a cost saving measure.
Now it would be easy to simply drop in a replacement graphic at this point and bypass the original code to display it. In fact many people have sent me such an image over the last couple of years in the hope I would do just that. But that's not really true to the ethos of what CannonBall is about. The real solution is to extend the original tilemap and use the tile layer to render the screen, rather than hack in a replacement.
Unfortunately, this approach needs a full tile editing tool, which is a rather complex way of achieving something that will look no different to the end user. Nevertheless, I'm writing such a tool so that tilemaps can be edited, new tiles created and the screen finally widened.
Currently I have the ability to import the music selection tilemap, edit tile data and edit tile maps. I'm in the process of creating the new tiles to extend the image to widescreen. As you can see above, the right hand side is relatively easy to extend and I'm just starting to tackle the more complex five columns on the left hand side.
OutRun contains plenty of unused tiles, which can be replaced for this purpose. For example, the larger Space Harrier font exists in the tileset, which is of course unused.
Now that tiles can be edited, I can also move on to create HUD graphics for the High / Low gear change, a MPH display and so forth. The next version of CannonBall will feature these improvements.
UPDATE: And here is the final result in CannonBall. The observant among you will notice that I've based the new tilemap on the 3DS version.
MSB LSB
---nnnnnnnnnnnnn Tile index (0-8191)
---ccccccc------ Palette (0-127)
p--------------- Priority flag
-??------------- Unused
As the index and palette share bits, this locks tiles to certain palettes dependent on their index. Therefore the previously identified unused tiles are not usable. Instead the new tiles end up being scattered through the tilemap from location 4096 onwards. I also had to create new palette entries to map to these tiles.
This explains why Sega games have tile duplication, where the same tiles appear multiple times in the graphic roms. It enables them to be used with multiple palettes. In practice I can't help but think it would have been simpler to double the tilemap memory, thus giving the palettes their own distinct bitrange and avoiding tile duplications. I guess this may have been a cost saving measure.
