Release notes – Death Weapon (C64)

It’s the final day for contributions to the RGCD 16K cartridge competition and your correspondent has been working on a second release for it from the C64CD stable; Death Weapon is an arena-style shoot ‘em up where the player must destroy all of the other spacecraft on each stage to progress. What’s a little unusual is the control scheme, holding fire whilst pushing the joystick will launch a bullet in the direction of travel but moving the stick on its own will still manoeuvre the craft but cause it to fire in the opposite direction. Enemies materialise at regular intervals and for a few moments are immobile and glowing, shooting them in this state will earn the player a score bonus.

The original inspiration for Death Weapon was the game Death Dealer, a simple action game which was developed in the late 1980s by Jeff J Gosden (and exists in a second form as The Perfect Weapon) but with a few inspirations borrowed from the Hallucin-O-Bomblets sub game from Batalyx by Jeff Minter – the idea of reversed firing came from there and was combined with Death Dealer’s forward-facing guns – and Andrew Braybrook’s Intensity – primarily this was where your correspondent borrowed ideas for the backgrounds and the parallax effect on the starfield – which were released in 1985 and 1988 respectively.

A couple of tricks have been employed to seemingly produce more colours than are usually present on a C64 and to make the player’s bullets appear to be semi transparent; these don’t entirely work under emulation or indeed with online videos, but with an actual C64 connected to a CRT display as nature intended they do fool the eye surprisingly well. The source code for Death Weapon can be delved into at our Github account as usual – the work files for Char Pad or Sprite Pad for the graphics and GoatTracker for the music are included – and the game itself is available from the relevant tabs on this very website or via a dedicated page at our shiny new Itch.io presence.

Advertisements

Waiting for impact

It’s been over three months since the author, whilst writing about a C64 BASIC program he was given to demonstrate hardware collisions, said that “soon, [he hopes] to post a conversion of the listing in question into Commodore BASIC V7 for the C128” and yet here we are without any sign of said listing materialising. Considering the author’s rather bold claim in the same post that converting the program to “a BASIC for spriteless computers […]  presents no problems” it seems bizarre that transferring the same eleven line piece of code to a system that shares the C64’s sprite hardware[1] has taken so remarkably long. By comparison, your correspondent’s port of his own assembly language conversion from C64 to C128 barely took a couple of hours!

At this rate the author is well past taking  a week per program line which isn’t really practical for developing software of any kind but, perhaps, goes some of the way towards explaining why, after nearly seven years of supposedly blogging about programming, we’ve yet to see the author release a single complete project even on the platforms he insists are easier to program for than the C64.

So, since all is quiet on the author’s front for the moment bar the occasional comment, let us instead discuss why he’s previously been barking up the wrong metaphorical tree as regards collision detection, at least from a practical standpoint for games. There are a few reasons why the C64’s hardware detection tends to be eschewed in favour of software-based checks, but the most important one is a design choice; pixel accuracy in such affairs would be far too sensitive for the majority of practical situations.

Many well-loved titles on the C64 and indeed for other 8- and 16-bit platforms are deliberately generous on the collision front because it’s only fair to give an advantage when the lone player is invariably up against multiple assailants. It’s not that hardware collision isn’t used of course and there are good games – along with some not-so-good games, for example Starforce Fighter shown in the screenshot above makes a “feature” of its shortcomings on that front within the documentation – doing so but, in the cases where the game itself is considered to be playable, great care has been taken by the developers to work around that accuracy in some form.

That mitigation can be as simple as ensuring that contact has to register for multiple frames before it actually counts[2] or perhaps only using the hardware for some aspects of detection as with classic titles such as Delta – shown in the screenshot above – where the player to enemy sprite and scrolling landscape (which are all generated with hardware sprites as well) impacts are detected by the hardware but bullet hits are checked in software.

[1] Sadly for the author, although the C64 and C128 share that sprite hardware, the latter’s BASIC maintains control over the registers so merely typing the same BASIC program into a C128 won’t work. This kind of issue would very likely have occurred had  Commodore upgraded the C64’s BASIC ROM, breaking compatibility for existing programs writing to the registers via POKE commands, which is why such upgrades are often frowned upon.

[2] One common trick used in this situation is to employ a power meter of some kind which is decreased for each frame that a collision occurs; if this is initially set to 50 that gives the player a second of bumping into nasties before death, usually enough to pass through a couple completely in fact.

Release notes – Stercore XD (C64)

The RGCD 16K cartridge competition is running during 2019, so your correspondent decided to have some fun and use it as an excuse to complete and release Stercore XD, a reworked version of the ported Spectrum shooter of a similar name which eschews software-based sprites in favour of larger, more colourful hardware ones and replaces the chunky scrolling backgrounds with something a lot more detailed. The competition rules state that entries must fit onto a 16K cartridge ROM and Stercore XD manages that even if it only just slides under the bar, with less than a hundred bytes of free space.

That doesn’t mean there aren’t some improvements to the original Stercore however, code for handling enemy movement patterns has been grafted in from Super Hyperzap to make the gameplay more interesting and the background scrolling speed slowed down to five pixels per frame rather than the original’s eight in an attempt to add further longevity to the game. The scrolling background’s map is 9,360 bytes wide by 20 high which means that there’s somewhere in the region of 182K of data passing by during the course of the game which, due to the slower movement speed on this version, will take just under five minutes to traverse.

As with the original Spectrum game there are two levels of background graphics, a darker layer which is always behind the hardware sprites and the mostly lighter one which passes over them. The technique is the same one used for games like Gryphon or Action Force and relies on one of the two character multicolours always staying behind the sprites regardless of what the hardware priority register is set to; this and the background colour are used for one layer whilst the other multicolour and various character colours provide the other. It does require a little more care than usual when designing the graphics but the effect works reasonably well.

Since the conversation here of late has been about hardware-based sprite to sprite collisions on the C64 it’s interesting to note in passing dear reader that this particular game exclusively uses software-based checks; that was a deliberate design choice for a number of reasons – this is something that your correspondent already has a longer discussion post in the works to cover more thoroughly – but it also harks back to the original Stercore and its subsequent C64 port, both of which rely on software sprites and, by association, collisions.

Along with the visual reworking, your correspondent also took some time to extend the original title music and tweak some of the sounds a little and most of the work files for the game are available over at Github including the Char Pad project containing the scrolling background for those wishing to understand more about how this works. It’s worth noting however that the source code is a little harder to read than usual, partly because chunks of the actual program are generated on starting up in order to meet the 16K limitation of the competition.

The source code even includes a macro since the author has previously talked about them. In this particular case the macro is called “print”, appears at the beginning of the source and is responsible for pushing text to the screen memory; the assembled code is slightly less efficient this way since your correspondent would normally optimise things by having one loop outputting multiple lines of text, but it does serve as a practical demonstration of how macros work since the author’s description was rather lacking.