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.

How Koalatro works

There were some interesting responses to Koalatro over at the CSDb when it was released, with a few people expressing surprise that the code only takes 16K which has left me giggling like a schoolgirl because, apart from some zero page use which doesn’t count towards the total according to the competition rules, the entire thing runs from 15K, loading and executing between $0400 and $3fff. A Koala-format bitmap is 10,001 bytes (8,000 of bitmap, 2,000 of colour and a byte for the background colour register), aNdy’s music takes around 3K and another half a K is taken up by unrolled code to open the borders and split sprite colours. So that’s about 13.5K use and the rest of the code, some tables, sprite definitions and a little scroll text therefore have to fit in the remaining 1.5K… right?

Well not exactly and it’s probably best to look at the memory map in order to explain further; before the code starts, the layout looks like this:

$0400 - $07e7	First block of colour RAM for the bitmap
$07e8 - $09db	Second block of colour RAM for the bitmap (packed)
$09dc		Background colour register
$0a00 - $13ff	Code, data and scroll text
$1400 - $1fff	Music
$2000 - $3f3f	Bitmap data
$3f40 - $3fff	Colour tables and sprite positioning/set-up data

The first two “tricks” are how colour for the bitmap has been stored; the first block at $0400 is already where it needs to be (which is why only the crunched file from the Github repository can be dragged and dropped into an emulator) so there’s no memory lost elsewhere or code required to move it into place. The second block of colour is a bit more involved since it’s been packed down into 50% of the RAM; this relies on the fact that only the lower nybble is used (a value from $0 to $f) so two of those can be stored in one byte. The background colour byte from the Koalapainter format file is included for completeness and the code will actually deal with other background colours cleanly despite that not being required in the final release.

One thing that’s missing from the memory map above is where the sprite definitions for the scroller are being stored but there’s a small hole between the end of the packed colour data and where the code starts for a reason; one of the first things the code does is unpack the colour data to $d800 and, once that’s done, the space from $0800 to $09ff is then cleared and used for the sprites so there’s only eight definitions available but, since both scrollers use the same eight sprites, that’s not an issue.

And speaking of the scrollers, there’s that block of unrolled block of code I mentioned previously to split the sprite colours and yes, it’s literally doing that; rather than changing the background colour and having black sprites over the top it’s actually writing one of two values to every sprite colour register on each scanline whilst juggling $d016 to open the side borders. The same block of unrolled code is recycled for the two scrollers, starting one scanline further up the sprites for the upper area so the reversed version of the scrolling message gets the static colours. Finally there’s the eight hundred bytes of scroll text from $10de to $13fe which leaves one byte free before the music starts.

I think that’s everything of note covered, the source code is, I hope, reasonably well documented.

How our CD5 part works

So… erm yes, I said over at the Plus/4 World forums that I’d write a “how it works” for the Cosine contribution to Crackers’ Demo 5 and here it is girls and boys, only six months late! Generally speaking there are two actual effects in play, the forty by five byte luminance scroller running through the middle of the bitmapped logo and a sixteen by ten pixel DYCP which works in the regular 39 by 6 character workspace but splits it into two blocks which are four characters high at the top and bottom of the screen.

The DYCP isn’t doing anything majorly different to the other single character routines I’d released around the same time – the loops are all unrolled and there’s specially formatted character data for speed which was originally drawn with ProMotion (I’m actually using an older version) before being converted using my cheap and cheerless bitmap to raw data converter – except that it has two distinct versions of the clear and draw code; one starts from the left hand half of the first character and proceeds to draw across to the right whilst the other begins from the right hand half; the code then flips back and forth whenever the hardware scroll finishes a cycle. During what I’ll refer to as the “design phase” for want of a better term, I settled on wanting the four character high areas so the redraw has to happen during the logo and there was only enough time to render ten pixel high characters.

And since I mentioned the logo, it was originally drawn using C64-specific tool Project One (again, I’m using an older version… one of these days I’ll update all my tools) with the colours used representing luminances; that data was then converted for the Plus/4 with a small assembly language routine on the C64 (all it actually did was translate the C64 colour data and dump it into memory so I could save the results out with a virtual Action Replay cartridge) and all of the colour data was manually created as an included source file. Here’s the logo’s “before” picture when it was still on the C64:

Finally there’s the large luminance scroller; the TED keeps luminance and colour data separately for bitmap-based displays like the logo so one eight by eight pixel attribute cell has two bytes of information, one containing two nybbles of colour (values from $0 to $f for sixteen possible colours) and the other holding two nybbles of luminance data (this time values from $0 to $7 for eight possible brightnesses). The “trick” here is that the luminance has been limited to a maximum of $5 for every cell in the picture where the scroller can pass over it, so when that is added to the scroller’s buffer which is either $0 or $2 for each nybble there’s a noticeable hike in brightness. To keep things simple there’s a second copy of that luminance data used for reference.

And, apart from mentioning that the music was created by aNdy using Knaecketraecker, pretty much covers everything I think. The source code is available online for those brave enough to go prodding around it and I’ll have a go at answering questions if any arise.