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.

Workprint – January 2018

I’ve missed my first Friday “deadline” for 2008 2018, that’s a cracking start to the year… having a cold is my excuse and I’m sticking to it, although that might just be the mucus!

The aftermath of the “festive season” means that I didn’t have much of note to write about at the moment anyway, I’m still hacking away in the background at the Hex Files remix when I can find time and have been mulling over a game for C64CD which will no doubt prove to be just another cheap excuse to write a scrolling shoot ’em up, but I’m tempted to throw some of the sillier ideas I’ve had for “features” into the mix for that one.

And before I forget, couple of folks have asked why Blok Copy or DYCP 2018 didn’t appear in last month’s workprint; that’s a simple one really, neither project had been decided upon when the post went live! I like to think of myself as spontaneous, although everyone else seems to feel it’s more “annoyingly erratic”.

DYCP 2018 (A8)

So Blok Copy on the Atari 8-bit wasn’t the only Cosine contribution to the New Years Disk 2018 because Cosine also churned out a little demo called DYCP 2018. And yes, I know that’s a terrible title but I was taking the Roy Walker approach to naming for this one and, after scratching my head for a few hours, nothing better presented itself!

The main reason for this one is that Andy Vaisey sent along a great cover of the loading music from Uridium 2 on the Amiga; he’d produced it whilst getting his head around the Atari 8-bit’s POKEY sound hardware but the tune was triple speed (so is called 150 times a second rather than just 50) and needed code around it which wouldn’t mind being interrupted from time to time if you’ll excuse the “pun”. I wasn’t thinking about that as I delved through my workfiles but realised that one of my five year old DYCP prototypes would work in that respect and spent a morning making the two work together.

Why is there a copy of the C64’s power up screen here…? That’s mostly because the DYCP routine has been written the “C64 way” using one character set and arranging everything in memory to make drawing the letters as fast and efficient as possible.