Workprint – February 2018

There hasn’t been much time for coding since the start of the new year, apart from spending a while prodding around a little at Vallation, mostly because another member of Cosine is considering a port and I’d forgotten how some of the level data was organised!

Previously I have pondered about coding something under the C64CD label as a practical demonstration of what processes are actually involved when writing a game; as already noted, my first thought is always “let’s do a scrolling shoot ’em up” but the idea of a tile-based version of Co-Axis didn’t really feel right so the project was pushed to the back burner until a recent Facebook post from Karolj Nadj about writing his first Run Length Encoding routine set me thinking; I’ve already got one of those, so could the scrolling background for a game be compressed that way rather than using tiles?

Run length encoding works by tokenising clusters of the same byte, so if there are twelve $64s in a row in the data they’re reduced down to three bytes which are a copy of the byte itself, a flag of some kind to say it’s going to be repeated and the number of times it should repeat; something like the gaps between landscape details on a scrolling background for example can be compressed quite a bit. With that in mind, out came my four year BlitzMax RLE compression code and the messy, self-modifying 6502-flavoured unpacker for a few tests and, after throwing some test data together and adding a couple of loops to convert the incoming map data to columns rather than rows, it seems to be reducing to around a third of its previous length which is sufficient for what I have in mind.

These early trials also found a bug within the RLE compressor code; because the length is a byte and can’t be higher than $FE there’s a sanity check in the code which stops the currently encoding run when it hits that value and forces a new one to start… all very sensible if I hadn’t forgotten to properly finish that first run in the data before moving on. Instead it only wrote the byte and a trigger for the run but no length value, meaning the 6502 end would pick up the next byte and use that instead, completely mangling the data in the process. This went undetected because the only practical use my RLE code had been put to previously was compressing streams of AY register changes for my prototype Apple II Mockingboard music driver where the data there changes too often for the bug to appear.

4 thoughts on “Workprint – February 2018

  1. Another way of tokening the data like I have done with EMS V10 Editor will squeeze you a bit more RAM. Consider runs of up to 7-bits long. You can use token codes of $00-$7F as a value of 1-128 bytes followed by this many bytes of uncompressed data bytes. Then use token values $80-$FF with AND #$7F as a run length of bytes from #$01-#$80 followed by a repeating byte. This will get your tokening down to just 2 bytes, plus I doubt you’ll have big long runs of the same byte beyond 128 in length, plus it is easy to navigate tokens. Read a byte, BPL to uncompressed byte loop, or BMI to compressed byte loop.

  2. I can’t really do that, the intention would be to use almost an entire character set for in-game graphics so the map data can contain pretty much any eight bit value.

Leave a Reply

Your email address will not be published. Required fields are marked *