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.
Well girls and boys, t’s rather late and I’ve spent most of my free time today getting it ready for release so don’t have many words left for a blog post, but MD201702 for the C64 has just been released. It’s another “look at all the pretty FLI colours” routine similar to the one in MD201509, but writing two independent colour values per byte rather than just one. Oh, and there’s some horizontal scroll register splitting on each scanline during the FLI routine which tilts the entire thing simply because that was fun to put in!
The unrolled code updating the FLI colours takes the majority of the processing power, so the copyright symbols swinging back and forth are handled using a similar trick to the swinging logos in MD201602 but using characters… that one might need a “how it works” with more detail at some point but there’s something of a queue forming again, so in the meantime I’ll just point at the Github repository where the sort-of-human-readable source code can be found.
I’ve been thinking a bit more about the Monthly Demo series as a whole and currently like the idea of “organising” it into seasons like television programmes tend to be arranged; that means I can take a break once in a while without worrying about it.
Well it’s been quite a while… but here’s a workprint post with almost no real information in it!
First off, after the “blip” at the end of 2016 I’m back to doing the Monthly Demo series and a couple of candidates are being prodded at for this month; I do want to expand the reach of that series a little as regards platforms, but will have to do a little “organising” since I don’t currently own the appropriate hardware for testing in some of those cases! I’ve been writing code using cross assemblers and emulators for over fifteen years now, and the most important lesson that’s taught me is to “metal test” everything before it goes out the door.
There’s a spot of learning that needs doing for some of the potential projects as well – my Z80 is still very weak and a few of the systems under consideration don’t have music editors available, so a probably half-arsed solution needs to be constructed which will allow someone with musical talent (so just to be clear, not me)to compose for for those cases. There’s a fairly substantial collection of half finished parts and routines for a range of platforms that could do with some attention so that they can escape into the wild. And yes, I know this is all rather painfully vague but at the moment I’m not sure which of these more out there ideas is even viable so I’m keeping my cards reasonably well hidden at least for now.
I am also, to hugely understate things for comedic effect, just a teensy bit behind with the “how it works” posts and will try to get onto that at some point soon; the two that I feel are most urgent are for the Cracker’s Demo 5 part and Koalatro since they’ve raised a few questions; the latter’s memory footprint seems to be surprising seasoned C64 coders, so I’ve been irritatingly smug about that for a while now despite having kept quiet about it actually taking 1K less than they think it does.