Workprint – March 2018

So let’s get some workprint business out of the way first; since there are now two people showing an interest in converting Vallation to other platforms I might just have to properly shuffle it to the front burner and get on with building the new levels so they actually have a full game to convert. This process will doubtless involve lots of expletives – all aimed at myself for taking shortcuts or bodging – and possibly some rewriting or at least refactoring of the code because it seems to take far more processing time than I remember.

The RLE-based background compression I was mumbling about in the last update is also implemented and works surprisingly well, in fact there’s a simple but functionally complete game wrapped around it now. It has over 56K of background data in there which has been compressed into a mere 23.1K and takes around six minutes to scroll through at one pixel a frame. My intention is to get the entire game done rather than doing a “development diary” so I know it’s finished when writing the C64CD blog posts.

I’ve done a few more tests as regards grabbing video footage, again using VICE and OBS to this time accidentally record a full ten level playthrough of Warhawk. The results look quite solid, but there’s a bit more fiddling with settings I want to do and I have Vegas Pro courtesy of the Humble Bundle to install and get my head around… so who knows, perhaps I’ll become a rich and famous YouTuber? Well okay, probably just a YouTuber but I’m only doing it for the groupies anyway.

In other news, whilst I was away in Kent I met up with fellow Cosine inmates Darren Nevell , Frank Gasking and Sean Connolly for the twice-yearly internal meeting; that makes things sound all official and stuff, but we basically take up a corner of Starbucks and natter for the best part of a day. After nursing a coffee each for a couple of hours we then piled into Level Up and spent a happy hour or so trying to persuade ourselves not to buy everything in sight! Amongst other things I ended up with a PSU for one of my spare Atari 800XLs, a collection of books which are destined for the racking going into my office once it’s decorated including one about BASIC for the Dragon 32, an unboxed freebie of A64 – a C64 emulator for the Amiga which has a dongle for connecting peripherals – and… well, this thing:

Despite looking like an adolescent Enigma machine it’s actually a joystick interface for the Spectrum where each direction and the fire buttons can be connected to keys so pushing left on the stick is, as far as the computer is concerned, someone holding down the O key. I absolutely adore the bizarre but functional nature of this thing; it’s such a perverse work-around for the problem but at the same time will literally work on anything that doesn’t require actual typing to play. Come to think of it, you could also “type” rude words with the joystick…

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.

How RG Rampage works

RG Rampage is a platform-based collect ’em up which was put together over a couple of weeks for issue 100 of Retro Gamer magazine, where it appeared as a type-in listing. And, at least according to the changelog kept in the game’s original source file, the final build was on the 11th of January 2012 which was a day over six years ago and that doesn’t make me feel old and decrepit in the slightest! So let’s take a look at what’s going on “under the hood” – a more human-readable version of the source code and some work files have been pushed up to GitHub – in order keep the game under 3.9K uncompressed.

Most of the savings come from the graphics which are optimised in a couple of ways to keep the overall size down; the character set is just cloned from the C64’s ROM whilst skipping the third byte of each character to make it look different, whilst the platform tiles – sixteen characters in total with one more for the titles scroller – are copied into that same 2K block of character RAM. Similarly, any object which can point in either direction like the player or some of the drones is actually stored just the once in the sprite data where it’s looking to the right, with the flipped version being generated on starting up.

Another place where things are reasonably compact is the level data; each platform uses five bytes for X and Y start position, character pair, colour and width and an entire screen only needs about a hundred bytes in total when adding the player start position, enemy patrol data – basically just another five bytes per nasty saying which object to use and giving two sets of X and Y positions to track back and forth between – and a stream of coordinates for the pick-up items. The level layouts were rather arduously worked out on printed sheets because getting a bespoke editor done would’ve taken too long.

I couldn’t include music because it would’ve added too much to the program’s length, so my (t)rusty “Roundasound” engine was dragged out of storage and given a bit of a dusting down; this is pretty much the same routine which was used for Quota by Chris Young and, with some modifications from Sean Connolly, in Flair Software’s Turn ‘N’ Burn so if anyone fancies a laugh they can have a prod through the source code for that. The routine is almost painfully primitive looking back and there’s a far better version now which is the base of my Atari 8-bit sound routine too, but it was compact and did the job.

The final “trick” was creating a BASIC listing for publication which, to keep the chance of errors sneaking in to a minimum, was handled by a truly hacky piece of BlitzMax code that yanked the assembled binary file in, generated a simple checksum by adding all the bytes together and then wrote out a text file containing the game as DATA statements and a small BASIC program with a FOR/NEXT loop which the code out to memory. That text file could then be tested by copy/pasting the contents into a freshly-loaded emulator and, when everything was deemed complete, sent off for publishing.

When Darran asked me to produce a type-in for issue 100 it seemed like a fun thing to try programming but I honestly didn’t expect anybody to actually type it in! There were a few brave souls who surprised me though and, judging by the feedback, they seemed to enjoy the experience of playing it as well. Going back to RG Rampage this afternoon for the first time in a couple of years to grab screenshots, I can’t help feeling with the advantage of hindsight that the balancing was a little off – almost certainly due to the dash for the finishing line – but it still feels fun to play.