Temporal Sprite Sharing Through Frame Alternation

Technical Article · 1 September 2021 · Updated 26 February 2026

Platform Context

The Commodore 64’s enduring reputation among 8-bit systems stems from integrated capabilities: dedicated audio synthesis, the VIC-II graphics controller, hardware scrolling support, and programmable raster interrupts. Hardware sprites constitute a defining feature, though the native limit of 8 simultaneous sprites drives developers toward creative expansion techniques.

The VIC-II provides eight hardware sprites, each 24×21 pixels in high-resolution mode or 12×21 in multi-color mode. Each sprite has dedicated position registers, a graphics pointer, and control bits for color, expansion, and priority. The hardware handles rendering automatically—once configured, sprites appear at their designated positions without CPU intervention during display.

Eight sprites often prove insufficient for action games requiring numerous enemies, projectiles, and effects. Various techniques extend this limit, each with distinct trade-offs. Toggle-plexing represents one such technique, operating on temporal rather than spatial principles.

Conventional Multiplexing

Traditional sprite multiplexing employs raster interrupts to reconfigure already-drawn sprites at lower screen positions with updated graphics pointers. This vertical reuse technique enables effective sprite counts exceeding hardware limits—some implementations achieve ten or more simultaneous on-screen sprites while maintaining additional visual systems.

The technique exploits the VIC-II’s scanline-by-scanline rendering. Once a sprite’s 21 lines have been drawn, the hardware no longer needs that sprite’s configuration until the next frame. Raster interrupts can reconfigure the sprite—new position, new graphics pointer—before lower screen regions render. The reconfigured sprite appears as a separate object at its new position.

Conventional multiplexing requires vertical separation between multiplexed sprites. If two objects need the same horizontal band, they cannot share a sprite slot through conventional multiplexing—both would need to render simultaneously, which one sprite cannot achieve. This vertical constraint limits multiplexing flexibility.

Temporal Multiplexing (Toggle-Plexing)

Toggle-plexing alternates single sprite hardware between distinct visual objects across successive frames:

Frame Alternation

Frame A: Configure sprite position, palette, graphics mode, pointer, and scale registers for first object
Frame B: Reconfigure identical sprite hardware for entirely different second object
Continue alternation indefinitely

The alternation occurs at frame boundaries—typically during vertical blanking when no rendering occurs. Configuration for the next frame’s object loads completely before visible display begins. Each object appears solid during its display frame, then disappears entirely for the following frame while its partner renders.

At 50Hz (PAL) or 60Hz (NTSC), each object displays 25 or 30 times per second. This rate falls below flicker-fusion threshold for most viewers when objects remain stationary—visible flicker becomes apparent. The technique succeeds only when object characteristics mask the alternation.

Viability Requirements

Toggle-plexing succeeds under specific visual conditions:

Target objects must exhibit inherent visual instability (flickering flames, pulsing energy effects)
Continuously moving objects maintain apparent solidity despite frame-by-frame absence

Successful implementation ensures players perceive two distinct game objects without recognizing single-sprite hardware reuse.

Inherent instability provides natural flicker cover. Effects representing fire, electricity, energy shields, or unstable phenomena logically flicker—players expect and accept this visual characteristic. Implementing these effects through toggle-plexing produces expected visual behavior while conserving sprite resources.

Continuous motion exploits a different perceptual mechanism. Moving objects activate motion-detection neural pathways that integrate information across frames differently than static object perception. A projectile moving steadily appears continuous despite being absent every other frame—the brain interpolates positions between rendered frames, perceiving smooth motion rather than discrete appearances.

Stationary solid objects fail the viability test. A stationary enemy character rendered through toggle-plexing displays obvious 25Hz flicker that breaks visual immersion. Such objects require dedicated sprite slots or conventional multiplexing.

Implementation Example

Practical applications combine toggle-plexing with conventional multiplexing—the same hardware sprite might render engine exhaust effects during even frames and projectile weapons during odd frames. Inherent visual characteristics of each effect mask the alternation, while projectile motion maintains apparent continuity despite intermittent rendering.

Consider a shoot-em-up scenario: the player’s ship needs engine exhaust (visual effect), the player fires projectiles (moving objects), and enemies fire return projectiles (moving objects). Without toggle-plexing, each category requires dedicated sprite allocation. With toggle-plexing, engine exhaust and player projectiles share a sprite slot; enemy projectiles share another slot. Effective sprite requirements drop substantially.

Implementation requires tracking which objects share each sprite slot and managing the alternation flag. A simple approach uses the frame counter’s low bit: even frames render object A, odd frames render object B. During the frame setup routine, the engine checks the alternation flag and configures sprites accordingly.

; Simplified toggle-plexing logic
LDA frameCounter
AND #$01
BEQ setupObjectA
; Setup Object B configuration
JMP finishSetup
setupObjectA:
; Setup Object A configuration
finishSetup:

Collision Detection Considerations

Toggle-plexed objects present unique collision detection challenges. The VIC-II’s hardware collision detection operates on actually-rendered sprites—an object not rendered during a particular frame cannot trigger hardware collision. Software collision detection must account for both toggle states regardless of which object currently displays.

The practical solution maintains collision boundaries for all toggle-plexed objects simultaneously, checking collisions in software rather than relying on hardware. This adds CPU overhead but ensures consistent collision behavior. Alternatively, design can accept that toggle-plexed objects (typically effects and projectiles) have simplified collision requirements—projectile-enemy collisions matter more than projectile-projectile collisions.

Historical Context

Similar temporal sprite sharing appears in other productions. LuftrauserZ employed comparable methodology. Earlier titles including Nemesis (Gradius) may have utilized related approaches with varying execution quality.

The technique appears across multiple platforms with sprite limitations. Atari 2600 games extensively used flicker-based object doubling given that system’s extreme sprite constraints. NES games occasionally employed similar approaches. The C64’s more generous sprite allocation makes toggle-plexing less essential but still valuable for ambitious projects.

Quality of execution varies substantially across implementations. Poorly chosen toggle-plexing candidates produce distracting flicker that damages visual quality. Carefully selected candidates—effects with natural flicker, rapidly moving projectiles—produce results indistinguishable from dedicated sprite rendering.

Technique Assessment

Toggle-plexing enables single sprite hardware to represent multiple spatially-separated game objects through frame-alternating configuration. When object visual characteristics—inherent flicker, continuous motion—satisfy perceptual requirements, players observe distinct elements where hardware constraints would otherwise prevent implementation.

The technique offers meaningful sprite conservation when applied to appropriate object types. Effects representing unstable phenomena (fire, electricity, energy) naturally mask alternation. Projectiles and other continuously-moving objects exploit motion perception to maintain apparent solidity. Combining toggle-plexing with conventional multiplexing maximizes effective sprite utilization.

Inappropriate application—stationary solid objects, slow-moving elements, objects requiring hardware collision detection—produces visible flicker that damages visual quality. Successful implementation requires careful object classification, dedicating conventional sprites to objects requiring stable rendering while toggle-plexing objects whose characteristics accommodate alternation.

Related: Product Information