One of my “defining traits” is a quite frankly ridiculous lack of organisational skills, in fact it comes as something of a surprise to people who’ve known me for any length of time that I get blog posts up on what are, by my standards, a fairly regular basis. As a result of that there are a lot of projects hanging around my hard disks which have been put aside for one reason or another, sometimes either on the cusp of being completed or actually done and dusted (although in one case it’s a port and in need of an overhaul since the original version has subsequently been improved).
So with spring approaching I plan to apply the defibrillator a few and right now I have two in mind, both of which C64CD projects; I’m keeping one close to my chest until it starts to properly exist past a few sprite routines that need recoding anyway, but the other is a reworking of Stercore 64 which re-imagines it as a bespoke C64 game rather than a Spectrum port. That’s more difficult than it might sound because the game scrolls at a character per frame and the landscape has two layers with one passing over the sprites, so my “plan” is to rely on the way that one of the character multicolours always remains behind the sprites regardless of the priority register.
That’ll give me a black background with one other colour for the background layer and, if I can scroll the colour RAM, five or six foreground colours; the sprites can then pass between the two without needing any complicated sprite clipping code since the hardware will do the work for me. That said, actually drawing something half decent with those restrictions is difficult and, whilst games like Implosion and Shadow Skimmer carry it off well, I’m no John Cassells or Mat Sneap…
There’s another C64CD release drifting it’s way around the interwebs this evening. Stercore is a no-nonsense, scrolling shoot ’em up for the Sinclair ZX Spectrum with 48K or more RAM which was developed by yours truly a little while ago with the intention being to enter it into the venerable CSS Crap Game Competition because, well, it’s pretty darned crap! The code languished for a quite while after being mostly completed and was finally pushed out of the door and into the wild after a quick wash and brush up.
Everything should be moving at a constant 50 frames a second during play – my DivIDE is currently in need of either a major service or more likely replacing so I didn’t get a chance to try it on real hardware before release, but it doesn’t appear to be dropping frames under emulation – and the backgrounds whip past at a dizzying eight pixels a frame since it’s all built from attribute cells rather than graphics data. Because it would probably be impossible to play at this speed if there were background collisions there isn’t anything to smack into, but parts of the landscape scroll over both the player and their assailants so a close eye needs to be kept to make sure enemies aren’t not lurking behind something.
There’s even some beeper-powered “music” on the title page which was composed by a Python script called Autotracker and then forced kicking and screaming into Beepola. For the sake of maintaining the 1980s budget game aesthetic, the Wham! The Music Box style sound driver was selected when compiling the music rather than going for any of the more complicated routines available and there are also some appropriately beep-laden sound effects during play as well.
This is my first complete assembly language game for the Spectrum and yes, that’s very apparent even without delving through the source code at GitHub – it’s recommended that anybody brave enough to do that wears hazmat gear or at the very least a good quality wetsuit and breathing apparatus – and, although I can accurately make the claim that Stercore has been written in 100% machine code, it really isn’t “pure machine code” as some people used to claim on their cassette inlays. Oh no, this is the dirty, impure stuff that our parents would warn us about as children…
As promised in the previous post, here comes C64CD release time! First out of the gate is Super Hyperzap, a slightly remixed and improved version of my little gallery shooter Hyperzap 2018 which was actually completed around a day or so after the original escaped into the wild but then put aside to “release next week” and accidentally forgotten about during the subsequent shift to “demo mode”.
The main difference between Super Hyperzap and its predecessor is that many of the modifications that people asked for in comments online which had previously been omitted for “artistic reasons” have now been implemented, so there are a lot more sprite animations including an explosion sequence and as the game progresses the enemies begin to move horizontally as well.
That latter change fixes a design flaw in the original that it’d actually inherited from the original Hyperzap which meant it was possible to just sit still and hold the fire button and, whilst the gameplay is still simple enough, that updates does make things significantly more manic, especially on the later attack waves when nasties really start to shift around. It still won’t win any awards of course, but this version is a lot more fun to play!
As is always the case, source code and the relevant binaries can be downloaded from GitHub for folks wanting a delve around under the hood and there’s already a trained crack by Excess which was, rather impressively, released before I’d even finished writing this blog post about my own release.