Demo Factory 2018 (C64)

Okay, so between writing the first draft of Saturday’s post rambling about the development of Demo Factory and actually pushing it out to the world I found myself pondering ways to rework it and… well, sort of accidentally wrote a complete, upgraded version! Demo Factory 2018 has been through a few iterations since that first build, but the final code was finished in the early hours of this morning. The music this time is from the game Ninja Rabbits and was composed by Sean Connolly, whilst the general layout of the screen was based on the original 1976 release with some tweaks to add new features. After that, everything else was pretty much built from scratch.

In some respects at least this version works in the same way as the original Demo Factory, relying on the C64’s hardware-based sprite to background priority register for the disks – that’s why one of the character multicolours is black in both versions, those parts of the graphics can never have a higher priority than the sprites so the moving floppies are actually passing in front of those parts of the background – but the sprite-based part of the scroller has to work differently, with the left hand character being a sprite that’s being masked in software so it can pass behind the black part of the pipe regardless of the letter’s current colour.

Although there’s one highlighted effect running in the box labelled “VFX” there are also two starfield-like routines, the animating “SFX” cone and a couple of other, smaller elements which are mostly being refreshed every frame – the moving arrows are shifted every second frame because they don’t look as pretty moving faster and things like flashing lights change only when needed – and that lot are all handled with either character redefinition or simply changing the screen or colour RAM. The only hardware sprites in use are the eight floppies which are either on or sitting by the lower conveyor, the last three characters of the scroller as it falls from the upper belt and one expanded sprite which displays the character that’s just about to appear for the scroll.

I did consider saving Demo Factory 2018 for the CSDb intro competition if it happens this year – the highest byte of memory used is $3FFF since the upper and lower borders are open and the ghostbyte needed to be zeroed so the code is small enough and it does technically feature a logo – but it feels more appropriate to put it out now alongside my fevered ramblings about the original. The source code has been cleaned up and can be squinted at courtesy of GitHub for those who might be so inclined.

Hyperzap 2018 (C64)

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.

DYCP 2018 (A8)

So Blok Copy on the Atari 8-bit wasn’t the only Cosine contribution to the New Years Disk 2018 because Cosine also churned out a little demo called DYCP 2018. And yes, I know that’s a terrible title but I was taking the Roy Walker approach to naming for this one and, after scratching my head for a few hours, nothing better presented itself!

The main reason for this one is that Andy Vaisey sent along a great cover of the loading music from Uridium 2 on the Amiga; he’d produced it whilst getting his head around the Atari 8-bit’s POKEY sound hardware but the tune was triple speed (so is called 150 times a second rather than just 50) and needed code around it which wouldn’t mind being interrupted from time to time if you’ll excuse the “pun”. I wasn’t thinking about that as I delved through my workfiles but realised that one of my five year old DYCP prototypes would work in that respect and spent a morning making the two work together.

Why is there a copy of the C64’s power up screen here…? That’s mostly because the DYCP routine has been written the “C64 way” using one character set and arranging everything in memory to make drawing the letters as fast and efficient as possible.