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

Introduction

SPECIAL UPDATE (Nov 2023): When I first wrote this article back in January 2019, the concept was met from elements within the god-complex coding clique in the C64 scene with scorn and derision. Another scener on Reddit privately told me that there is a largely unspoken "closed canon" in terms of what the C64 can do and so anything ostensibly new will, in fact, be hotly contested and put down by them.

As self-appointed custodians and arbiters of 6502 right-think who, to be fair to them, for the most part^* genuinely seem to understand more about the hardware of the C64 than the CBM engineers themselves did, will instantly squash and mock anything that hints at technical novelty, as I found with the toggleplex concept.

Of course, I never sold the concept as a new exploitation of a hardware quirk (which for me is the essence of any novel VIC trick), but simply as an optical illusion every bit as much as interlacing on the C64 is. But I was too enthusiastic - yeah, seriously, some people complained about that - and I think they thought I had to be firmly put in my place.

Anyway, simply be aware that this method, despite its demonstrable utility in games, dare not be named as such without drawing down the wrath and sarcasm of the anally retentive know-it-all uber nerds!

[* ~ I have noticed what appears plainly to me to be a lot of bluffing going on in some of the CSDB forum discussions, where certain personas pretend to know more about what they are discussing than they really do. I was guilty of things like that myself in the past, or of making careless technical comments on forums, but I am not justifying what I did or what these blowhards are doing.]

Enter the Dragon, I Mean, Multiplexor

Returning to the gist of the article, if you asked 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.

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...

Naturally, Parallaxian is not the first game to do this, with 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.