"Toggle-plexing" Sprites on the Commodore 64
Ask any "Breadhead" 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:
- The SID chip with its 3 voices, 4 waveforms and 8 octaves.
- The VIC-II chip with its 16 colours (twice what the Sinclair ZX Spectrum had) and 8 hardware sprites.
- Hardware-facilitated smooth scrolling.
- 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.
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 a raster 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, Colony, 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 Colony 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.
The answer is we can't do this in any game-worthy practical way; sprite rendering is one of the VIC-II's less trivial chores and the hardware resources to keep such a split stable for more than a few scanlines just doesn't exist - for a detailed treatment of this subject, see Pasi Ojala's superlative article, "Missing Cycles".
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:
- 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.
- On every odd numbered VIC-II frame, we do the same but for a totally different sprite definition and / or location.
- Repeat ad nauseam.
To illustrate the principle schematically, the diagram below shows how Colony'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:
- 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.
- 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 Colony prototype below; again, it's the afterburner toggled with the plasma bomb:
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 Colony's case, that's the main
game engine's Non-Maskable Interrupt (NMI) that also runs the parallaxed scroller routines,
the colour splits, the mode splits and the multiplexor.
So Colony 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, Colony 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 Colony,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.
But beyond that, nothing remotely obvious springs to my mind so feel free to hit me with your own suggestions in the comments section below!
THE TIP OF THE ICEBERG
I believe toggle-plexing may yet be used for something really unprecedented on the C64 and have an idea in mind that I hope to demonstrate - should it prove technically feasible - by the
spring of 2019 (time and other demands permitting).
In the meantime, I intend to use the technique elesewhere in Colony as the game develops, at least in scenarios where maximising the number of sprites in the visible play area warrants it.
And, of course, toggle-plexing stands as yet another reminder of the way the Commodore 64 never ceases to provide scope for coders to find unconventional ways to expand its default capabilities, cementing its status as the greatest of all the 8-bit computers.
If you liked this article and want to know when the next one is posted, kindly consider joining my 100% spam-free, nag-free Newsletter.
Anything you receive from me will be cool and interesting - especially if you're a C64 gamer or coder!
In the meantime, feel free to use the handy buttons on this page to share it on social media, if that's your thing!
Good write up. Toggling sprites works very nicely with the laser and afterburner! Dragon Breed is another game that toggles sprites to give the impression of more sprites, as it has the difficult job of making the player's dragon appear to be equivalent to 7 sprites! You can see it in motion here.
Thanks for that and for the link - that's an interesting one but it's a bit outside my own rules for toggleplexing because it's obvious that the dragon's body is made up of alternating sprites.
The way I am doing it on Colony means it's impossible to tell that it's just one sprite, unless you slow it right down or freeze the frame.
So when I talk about "toggle-plexing", that's the end result I require, i.e., the illusion that it's two sprites not one alternating between two different conditions.
BTW, someone else on Lemon's forum mentioned that the game Thrust also uses a kind of toggle-plex effect, so I must look into that!
Leave a Comment
Comments are moderated to prevent spam and emails are only required to filter basic spambots; such emails are neither harvested by me nor displayed on this website.