Stercore XD (C64) released

The start of a new month sees a new C64 game from yours truly… well, “new” in the sense it’s a reworking of something I released last year under the C64CD label. Stercore XD is a horizontally scrolling shoot ’em up and I’m sure my regular fan has just passed out in shock at such an out of character move on my part. Sarcasm aside, I might as well wibble on a bit about technical details since the game isn’t exactly a complex beast with an engaging back story.

The screen scrolls at five pixels a frame – a little slower than the original Stercore on the Spectrum or the direct C64 port which are moving at eight pixels – and uses a wider map which leaves gaps for tidy background colour changes. That map is 2,340 tiles wide, making the background around 240 screens in total and it all barrels past in a little shy of five minutes during play. Since Stercore XD has been squarely aimed at the RGCD competition it needed to run from a 16K cartridge, so the bulk of the game is compressed with Exomizer but the unrolled chunk of background scroll code required to move two and a half times what the Spectrum is dealing with was generated on start up.

Stercore had player and enemy objects passing between two layers and this has been faithfully replicated with hardware sprites in Stercore XD, relying on the hardware sprite priority register and using a similar approach to games like Implosion, Dan Dare or Shadow Skimmer. One background layer is always the background colour the character mulitcolour which that doesn’t get priority over the sprites, the other layer uses the remaining multicolour and character colour, with the latter mostly being used to add dark and light detail. This technique is accurate to half pixels and requires no processor overheads for masking but does require a lot of extra juggling when drawing the graphics.

After that it’s got a slightly extended and tweaked version of the original theme tune which was just an extra half pattern from the original Autotracker-generated tune used to “create” the original Stercore music and, more importantly to the gameplay, there’s a simple attack wave driver which was repurposed from Super Hyperzap. As is usually the case there’s source code – and in this case, work files for those wanting to understand the sprite priority thing – over at GitHub for folks wanting to prod around, although that source isn’t my tidiest piece of work even after it was “sanitised”!

Releasing Level One (C64)

We’ve reached the end game for 2018’s Intro Creation Competition so there’s been an inrush of new releases over the last couple of days including one last contribution from yours truly with the ever patient Andy Vaisey on music. It went through a few names but Level One was the final choice simply because it looks somewhat like a game.

The scrolling area takes up the entire regular screen – 39 visible characters across by 25 down – and is being moved using a double buffered scroll routine similar to the ones employed by games which in turn leans on some Run-Length Encoded background data. It also uses the C64’s Extended Colour Mode so, although there are only 64 characters available in the font, it can have four possible background colours for each character so I don’t have to scroll the colour RAM.

Something a little trickier is happening in the black bands above and below the scrolling; these are ten pixels high and sat in the borders, but containing a seven character wide Cosine logo and nineteen characters of either static text or scrolling message. To get twenty six characters into that space the code has to abuse the ghostbyte, splitting it at five points on each scanline to produce the extra two characters (they’re at the far left and right of the screen on both lines) and mask off the raster bars for the areas between the sprites.

I suspect a few people will be asking themselves if a game with similar graphics would be possible and the answer is a sort-of-yes, although drawing decent backgrounds when restricted to just 64 characters is bloody tricky!

Watching Snata (C64)

Released in 2002, Snata was an entry into the Christmas Demo Competition and not in the slightest bit cynical or sarcastic. Well, okay it was because the “inspiration” was a SuperCPU-specific demo called Coca Cola Santa Claus – the original seems to be lost to the mists of time – which used the 65816 to brute force a full screen width FLI image out of the VIC-II… and then displayed one of the worst-looking wired pictures I’ve ever seen! So on a particularly dreary winter evening I was making a nuisance of myself on IRC and ended up in a little “competition” with Groepaz where we amused ourselves by taking said image and trying but failing to produce something similarly terrible by throwing it through whatever converters we had to hand.

A year or so before this evening of entertainment happened I’d noticed in passing that the tunes from Zeppelin’s Amiga game Santa’s Xmas Caper were all written in the same general, annoyingly jolly style so, pretty much on a whim that I was probably at a loss to explain even then, I spent an evening unceremoniously mangling them into a single piece with Goattracker. So now I had a piece of music and a fairly reasonable wired picture, so all that was needed for a Christmas competition entry was a little code to glue it together and that was actually donated by a previous release.

But once that had been congealed I had a moment of what we’ll have to call “inspiration”; since the picture had been based on a demo which required a hardware expansion to run it seemed sort of appropriate to add a similar but in this case optional overhead to mine and I already had just the thing lying around, a routine which leant on a RAM expansion to produce an effect similar to the FLI-based one in Charlatan – appropriate considering Coca Cola Santa Claus – but in the borders rather than on screen.

The routine uses the REU’s DMA to transfer colour data back and forth between the base 64K and expansion RAM, moving everything around at an impressively fast one byte per cycle. There are two shifts of the colour data during the screen to update it but the important part happens during the upper and lower borders where transfers are triggered with the destination set to $D020 and the DMA told not to update that address with each write; the result is that the border colour register is updated once per cycle with around 48 being visible but 63 writes actually taking place since there’s that many cycles per scanline.

Of course, the competition was just for fun and meant to be just standard C64 code so the colour bars were only there as a hidden bonus, but hey ho ho ho…