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.

Starforce Fighter (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.

Delta (C64)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.

This entry was posted in Meta Discussion, Programming and tagged , , , , , , , . Bookmark the permalink.