Workprint – September 2018

I spent the previous weekend visiting family dahn sarf and, after a particularly harrowing coach trip home, had to spend a few days “recovering” so this post is a bit later than expected… on the plus side, I picked up a copy of Compute’s First Book Of Atari Graphics from the lovely folks at Level Up in Canterbury…

…which I hope is not too advanced for me! It even came with a hand-written page – poking out of the book in the picture above – of display lists as decimal from a previous owner which seems to have been used as a bookmark since it’s a few pages into the chapter titled Introduction To Player/Missile Graphics, one of the few places where the display list isn’t particularly relevant.

Sorry, drifted off a little there… so I’ve been working on the project I’m still not really talking about, although it’s probably safe to say I’ve been a little lazy recently; the intro is done and there’s two complete parts still waiting to be linked, but I haven’t found the time for a prolonged coding session to get any of that done and it’s one of those jobs I don’t want to stop halfway through for fear of losing my place. I also have a list of potential ideas which is coming along nicely and a couple of existing prototypes which can be improved and re-purposed so stuff is still happening.

I did find a couple of hours to doodle some code whilst away though; an interesting thread at the Plus/4 World forums mentioned using the registers $FF1A and $FF1B to scroll a bitmapped screen around in a form similar to AGSP on the C64 except without the “dead air” at the top of the screen, so I spent some time experimenting to get my head around it. The code I wrote works but this method only affects the bitmap itself so colour data would need to be moved by brute force, a bit of an ask considering the Plus/4 uses 2K for bitmapped graphics regardless of mode. It’s something to experiment with later, although I’m seeing an odd, almost FLI-like glitch in the version I wrote which added splits for a character-based scrolling message and can’t think for the life of me why it’d be there!

Workprint – August 2018

As noted a few times recently, I’ve cycled over into “demo mode” and have been working on… well, something that I’ll be keeping quiet about for a little while yet until it properly gets past that stage where it could be changed or indeed completely reinvented on a whim. Generally speaking though, my intention is to have something ready for X’2018 in early November – assuming we have a representative to take it along – and have a cluster of prototype routines along with some other ideas I’ve been meaning to try and a folder of logos because everybody loves logos… right?

Things have been going slowly but surely so far – today alone I somehow managed to metaphorically paint myself into a corner on two different occasions with what should’ve been relatively simple code, either choosing a less than sensible place to store things or simply running out of memory altogether – and, because it’s been a painfully long time since I worked on anything that wasn’t a onefiler, last week saw me sitting down and trying to get my head around cruncher and loader integration with some of the more recent iterations of popular tools with very little joy… at least until I discovered lft’s Spindle that is.

Spindle is, in essence, a back engine for demos which deals with loading and decompressing of data to the point where the user doesn’t need to be involved; no fighting assemblers to build loader or decruncher code, no messing around with building disk images of data, just document the files being used and the order they’re needed via a script file which is then run through Spindle to automagically get a working disk image out the far end. There are caveats of course – a couple of places in memory have to be avoided, something else I bumped into today – but having to do things just a teensy bit differently is worth it for the results.

Main project aside, there’s also been a little time spent generally doodling both with graphics and ideas for effects and a couple of forays onto other platforms; something might come of the latter if they survive testing on real hardware – in both cases the code was for a platform I don’t actually own right now, so that’s something of an issue – but at the very least it was all good practice.

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.