"Toggle-plexing" Sprites for Games on the Commodore 64

Introduction

Ask any C64 fan what made (or still makes!) the Commodore 64 the superlative 8-bit computer and you're pretty much guaranteed one or more of a handful of standard answers to the question:

1. The SID chip with its 3 voices, 4 waveforms and 8 octaves.
2. The VIC-II chip with its 16 colours (twice what the Sinclair ZX Spectrum had) and 8 hardware sprites.
3. Hardware-facilitated smooth scrolling.
4. Raster interrupt services allowing for split-screens and many other exotic effects.

Sure, some other 8-bit machines could also match or outdo one or more of those features, but as far as I and many others are concerned, none tied them all together like the C64 did.

Personally, however, if you held a gun to my head and told me to reduce the Breadbox's appeal down to one very specific core "genius ingredient", I would have to say it is the hardware sprites.

Such a pity, then, that the C64 only provides 8 of them natively.

Of course, that limitation has been stretched massively via the well known expedient we call multiplexing.

Enter the Dragon, I Mean, Multiplexor

Before proceeding, it would be remiss of me not to point out the nebulous and historically contentious nature of the term multiplexing / multiplexor which, during the C64's legacy era, tended to be riven by the kind of conflicting definitions that only coding snobs could be bothered to split hairs over.

That situation has largely mellowed in the ensuing years, to the extent now that pedantic semantics have been supplanted by a more general consensus:

Multiplexing means any measure that uses an interrupt to re-draw an already drawn sprite, typically with a new pointer (i.e. definition), further down the screen, thereby producing one or more additional sprites (for an ultra hardcore technical treatise on maxing out the number of sprites yielded this way, see Linus Akesson's detailed article).

In any event, for the purposes of this article, multiplexing and multiplexor assume the broader meaning most people, myself included, use today.

And of course, as you might very well expect, I use a multiplexor technique in my next-generation game in development, Parallaxian, as per its provisional sprite schema depicted below:

Black text denotes "sprite zone 1", red denotes "sprite zone 2" and, well, give yourself a gold star and go straight to the top of the proverbial if you know what blue denotes!

What this illustrates, along with many other examples before it (such as Armalyte and Turrican) is the sheer power of raster interrupts when it comes to expanding the number of hardware sprites visible on-screen simultaneously.

In fact, that capture of a still frame (defined further below, just for the uninitiated) from Parallaxian shows that the VIC-II has drawn TEN hardware sprites without once using sprites 4, 5, 6 or 7, while at the same time managing the demands of a parallaxing smooth scroll handler and "software sprites" in the form of little men that run about the foreground and "chrome dome" laser pillboxes... yet another reminder why the Commodore 64 was and remains in a league of its own compared with its era-peers.

But what I really want to highlight the most from that image is this:

Multiplexing is a vertically biased technique.

In other words, you can only multiplex in the y-direction, not the x-direction.

That's because each frame consists of the VIC-II starting at the top of the screen (actually way above the visible screen) and far to the left and then running a render beam (aka the "raster") across the screen, jumping back to the far left and down one pixel depth in an instant before repeating the process 312 times (on the PAL machines we use in Europe; on the USA's NTSC it's a mere 262 times) until the entire screen is rendered.

This means each single screen refresh frame is a complete top-to-bottom sequence, repeated 50 times per second on PAL machines - for a more detailed primer on the raster (and to nip this wandering-off-topic tangent in the bud), see this Dustlayer article.

Now maybe you're wondering, why can't we trigger a re-draw of a sprite at some point as the raster beam zips along a horizontal scan line, you know, to create a horizontal raster split?

After all, there are many demos out there with vertical raster bar effects that would suggest an x-direction sprite multiplexor might be possible.

There is, however, another way; I call it...

The Way of the Toggleplexor

Obscure references to old Bruce Lee film titles aside, it is possible - if certain conditions are adhered to - to reuse an already drawn sprite elsewhere on the screen without recourse to brain-teasing multiplexing techniques.

It's still far from simple to execute (from a novice coder's perspective), but it's maybe slightly easier than multiplexing and is not bound by vertical biases or scanline-splitting constraints.

I call it, rather arbitrarily and without the least iota of community consensus, Toggle-plexing (or Toggleplexing, without the hyphen).

Assuming you are familiar with the fundamental nomenclature used with sprites, the technical principle is thus:

1. On every even numbered VIC-II frame, we set the toggle-plexed sprite's x- and y-positions, colours, mode (hi-res or MCM), pointer, MSB ($D010) and its x- and y-expansion bits to suit the desired rendering of the sprite at that location.
2. On every odd numbered VIC-II frame, we do the same but for a totally different sprite definition and / or location.
3. Repeat ad nauseam.

To illustrate the principle schematically, the diagram below shows how Parallaxian's afterburner effect is served by the same sprite (sprite 2) as the plane's laser; but it only works in the game because the afterburner flame has to flicker anyway and the laser has to move across the screen, thereby revealing 2 critical rules or conditions of the toggle-plexing method:

1. Any object rendered by the toggle-plexed sprite cannot be fixed in position and solid; it must flicker, like a flame, if it is not mobile.
2. Any object rendered by the toggle-plexed sprite, however, can be ostensibly solid if it is moving, such as a falling bomb (although its solidity is an optical illusion, as in actuality, it is invisible on every other frame.

You can see it in action now with the plasma bomb falling from the plane in the slow motion clip from my latest Parallaxian WIP clip below; again, it's the afterburner toggled with the plasma bomb:

Special Note: What toggleplexing is NOT is "flickering sprites"; I can't emphasise this point enough, because if it's obvious that the coder is alternating sprites with each frame, then the effect ceases to an optical illusion and is not, by definition toggleplexing... remember, the whole idea is that the player of the game never notices that it's just a single sprite being used to simulate two.

As with so many offbeat VIC-II techniques, toggle-plexing requires execution from within a raster interrupt to ensure consistent timing of the effect; in Parallaxian's case, that's the main game engine's interrupt that also runs the parallaxed scroller routines, the colour splits, the mode splits and the multiplexor.

So Parallaxian combines toggle-plexing with a multiplexor to maximise the number of useful, game-critical sprites visible at any time.

Not Quite a Novel Technique...

Alas, Parallaxian is not the first game to do this.

Unbeknownst to me when the concept bubbled up in my mind, at least one game coder had already got there before me.

While preparing this article, Paul Koller revealed to me that he used this (or a similar) technique in his brilliantly chaotic blast-athon, LuftrauserZ, for the very same things I'm using them for in Parallaxian,i..e, afterburner and laser.

That got me wondering, what other games might use the technique?

I'm not one for reverse-engineering and forensically deconstructing other coders' work, so I can only indulge in conjecture here, but I suspect some of the diamond-shaped projectiles used in Nemesis (aka Gradius) were sort of toggle-plexed, albeit badly.

____


PS - If you value my work and want to support me, a small donation via PayPal would be nice (and thanks if you do!)