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.
Before I start with the history – this is about Hyperzap in its myriad forms rather than just the new 2018 edition just released under the C64CD banner because why not – a quick disclaimer is probably required, my memory is shocking at the best of times and my recollection of dates may well be off by a considerable amount; usually I rely on friends who have a far better recollection of events, but in this particular case there’s nobody I can really ask. This is… frustrating to say the least and means I’ll be a little vague about specific dates, but I’ve tried to at least nail things down to the correct year and will update things should the facts turn out to be different.
I’ve mentioned Hyperzap in the past when talking about Co-Axis, it was the first “complete” assembly language game I ever wrote and started at some point in late 1986; the actual development process took several months because I was literally learning about the C64 as I went, working out features I wanted and then trying to understand the documentation to implement them. The code was written with the venerable Zeus 64 Assembler, the sprites drawn with an editor I was given but can’t remember the name of – the player ship is just a tweak I did of a default sprite included with it but the enemy was drawn from scratch by my friend Simon Probert – and the titles page is a Yak Society demo that was “repurposed” because I had no idea at the time how to rip the music myself.
There was also a Hyperzap 2 which improved on the original a little – some bugs were sorted out, it had a custom character set and there were multicolour sprites this time with the enemies being my own interpretation of the “licker ships” from Jeff Minter’s Iridis Alpha – but, during a coding session at a friend’s house on his C128, the source code was lost when the 1571 disk drive ate it – that was completely my fault and, although a valuable lesson about backing up regularly should have been learnt that day, it sadly wasn’t and came back to bite me on the posterior when working on Co-Axis,
And then there was another incomplete but at least partially preserved attempt to resurrect the original design, done for the sheer hell of it in the early 1990s around the time coding for what would eventually become Warflame was started; it was called Hyperzap ’91 and was essentially a from scratch re-write of the original even down to the hardware-based collisions – Warflame in its original form uses the hardware registers as well – which also added simple Pirates In Hyperspace style movement patterns since that game, along with Kernal’s Chaos, Galax-I-Birds and a few others, was originally an inspiration for Hyperzap.
Fast forward over thirty years from the original to an annoyingly warm bank holiday weekend and yours truly was pondering the mysteries of the universe, the meaning of life and C64 hardware-based sprite collisions. We’ll just have a quick primer for anyone who hasn’t dealt with the collision registers in the past; sprite to sprite and sprite to background collisions are handled by a video register each which both use the bits in their byte to represent the eight sprites. Bits are are set when a collision occurs and, whilst that’s fine for background collisions bar a few caveats, it doesn’t tell the entire story for sprite to sprite impacts. For example, if the lower four bits of the register are set there’s no way to tell from that if there are two separate collisions (and which pair sprites are involved) or if all four are clustered together somewhere.
So what Hyperzap 2018 does is split things in two. It checks the sprite to sprite collisions to see if the player is in trouble and, because the bullet is a software sprite, background collisions can be used to check when nasties have been shot. False positives don’t occur with the starfield because one of the multicolours doesn’t actually trigger sprite to background collisions and the registers are cleared at the top of the frame and checked just before the status bar so that doesn’t accidentally “shoot” enemies either. Being a software sprite also means the bullet can be coloured independently to the hardware sprites and the spaceship uses a second sprite as an overlay so it doesn’t share dark grey with the enemies.
I’ve also added a simpler version of the enemy movement patterns from Pirates In Hyperspace where only the vertical speeds are changed and two enemies will update every five and a bit seconds. It is almost painfully simple stuff for sure, there aren’t many bells or whistles past having a titles page and there’s a fairly obvious fault in the game design which survives almost completely intact from the 1987 original but, considering the bulk of the code took around four hours, I’m quite pleased with the results and it was nice to finally use that Marc Francois tune in something too. The source code is available through good old Github for anyone wanting a prod around and a download is over at the CSDb.