Geo-Referenced Sprites for C64 Scrollers

Implementing world-anchored sprites with independent horizontal motion in bidirectional scrolling environments presents distinct technical challenges on the Commodore 64. This guide examines solution approaches for maintaining sprite world-position consistency.

The term “geo-referenced” borrows from geographic information systems, where coordinates maintain fixed relationships to physical locations regardless of viewing perspective. Applied to C64 sprites, the concept describes game objects that maintain fixed positions within the game world even as the view scrolls—enemies that occupy the same world location when players return to previously explored areas.

Most C64 games avoid this complexity through design choices that make world-anchoring unnecessary. When a project does commit to geo-referencing, a visual tool like a kanban board becomes invaluable for tracking the state of each subsystem — collision handling, sprite culling, datum calculations — across the implementation pipeline. This technical guide examines the implementation challenges that arise when game design genuinely requires persistent sprite positioning in bidirectional environments.

Technical Challenge

Bidirectional scrolling introduces complexity beyond unidirectional implementations. Sprites anchored to specific world coordinates must reappear correctly when players revisit previously explored regions—particularly challenging when those sprites also exhibit independent lateral movement patterns.

Consider the problem dimensions: a sprite has a world position (its fixed location in the game space), a screen position (where it appears on the visible display), and potentially an animation or movement offset (local motion independent of world position). As the screen scrolls, screen position changes even when world position remains fixed. When the sprite also moves relative to its anchor point (patrolling, oscillating, pursuing), the movement offset adds further complexity.

The challenge compounds when sprites move off-screen and must later return correctly. If a patrolling enemy moved 10 pixels from its anchor point before scrolling off-screen, it must reappear 10 pixels from its anchor point (plus any distance it would have traveled during the off-screen interval). Tracking this state for many sprites while efficiently culling off-screen sprites from active processing creates substantial implementation complexity.

Notable bidirectional titles including Dropzone and Uridium circumvented this challenge through alternative methods: character-based software sprites or non-anchored enemy movement patterns that reset rather than persist.

Dropzone uses character-based software sprites for most enemies, eliminating the hardware sprite positioning complexities. Uridium employs enemy patterns that don’t require persistence—enemies either pursue the player (screen-relative positioning) or spawn at level start (no return visits). These design choices avoid geo-referencing complexity while delivering compelling gameplay.

Approach Analysis

Four implementation strategies warrant consideration:

1. Lookup Activation — Maintain tables mapping sprite identifiers to world block positions, triggering activation when corresponding blocks enter viewable area.
2. Synchronized Sprite Mapping — Parallel sprite positioning map tracking scroller state (methodology employed in Mayhem in Monsterland).
3. Axis-Relative Movement — Sprites reference central axis coordinate with movement extending both directions.
4. Datum-Relative Movement — Single-sided lateral movement from fixed reference line (selected implementation).

Lookup Activation stores sprite definitions (position, type, behavior) indexed by world block positions. When a new block scrolls onto screen, the engine queries the lookup table for sprites associated with that block and activates them. This approach handles spawning efficiently but struggles with sprites whose movement carries them across block boundaries.

Synchronized Sprite Mapping maintains a parallel data structure tracking sprite states across the entire level, updating even off-screen sprites’ positions each frame. When sprites scroll back onto screen, their current positions (including movement progress) are immediately available. The overhead of updating all sprites every frame limits this approach to smaller sprite populations.

Axis-Relative Movement defines sprite movement patterns relative to a central axis with equal extension in both directions. A patrolling enemy might move 20 pixels left and right of its anchor. This symmetry simplifies calculations but constrains possible movement patterns.

Datum-Relative Movement (selected for implementation) anchors sprites to a reference line with movement extending in one direction only. This asymmetric approach enables broader movement patterns while simplifying the screen-position calculations needed for efficient culling.

Datum Implementation

The implemented solution recognizes three datum states:

1. Datum left of visible origin (x=0, MSB=0)
2. Datum within visible range, right of origin (x=0, MSB=0)
3. Datum at screen right boundary (x=0, MSB=1, below x=89)

The datum represents the sprite’s anchor point in screen coordinates—the fixed world position transformed into the current view’s coordinate space. As the screen scrolls, datum values shift accordingly. When the datum exits visible range (left or right), the sprite becomes inactive.

The three-state model handles the VIC-II’s 9-bit horizontal sprite positioning. Screen X positions 0-255 use the low byte directly with MSB clear; positions 256-343 (approximately, covering the right border region) require MSB set with the low byte wrapping. Correct state tracking ensures sprites render at correct positions regardless of which screen region they occupy.

Pre-computed sinusoidal values generate smooth oscillating motion with natural acceleration curves. Per-frame updates read range table offsets and apply them to current datum coordinates.

The sinusoidal tables encode velocity values rather than absolute positions. Each table entry indicates the position change for the current frame. Summing entries across frames produces the actual position offset. This approach enables smooth acceleration and deceleration at movement extremes while maintaining constant velocity through the movement center.

Condition Evaluation

Eight-state condition logic governs sprite behavior:

• Deactivate when condition 0 datum exceeds rightward roaming boundary
• Track addition carry flags indicating MSB transition requirements
• Permit position updates only when carry conditions allow in state 0
• Manage state 1-to-2 transitions through carry flag monitoring
• Deactivate sprites when condition 2 datum exceeds far-right limits

The eight states enumerate the possible combinations of datum position, MSB status, and movement phase. Rather than evaluating these conditions through nested branches (which would consume excessive cycles), the implementation uses a state machine where each state has specific permitted transitions.

Carry flag tracking serves dual purposes. The 6502’s carry flag indicates when 8-bit addition produces results exceeding 255—precisely the condition that triggers MSB transitions for 9-bit sprite positioning. By preserving and testing carry flags from position calculations, the engine determines MSB requirements without separate comparison operations.

The deactivation conditions implement efficient culling. Sprites whose datums exit the visible region (left edge or right edge) become inactive, freeing resources for sprites remaining on-screen. The roaming boundary extends slightly beyond visible screen edges to prevent sprites from popping in/out at screen boundaries.

Non-Anchored Patterns

World-anchoring suits some enemy types while others benefit from reactive patterns. Point-defense enemies spawn at specific triggers then pursue dynamically. Patrol-type enemies roam predetermined areas until player interaction modifies their behavior.

The game design should specify which enemies genuinely require geo-referencing. Enemies that spawn, perform one attack pass, and disappear need no world-anchoring. Enemies that guard specific locations and must persist across player visits require full geo-referencing. Mixed behaviors need partial implementations.

Point-defense enemies exemplify reactive patterns. A turret that tracks player position performs all calculations in screen coordinates—the turret’s world position matters only for activation. Patrol-type enemies benefit from geo-referencing’s persistence, maintaining patrol phase even when players scroll away and return.

Optimization Guidance

• Execute directional routines synchronously with scroll updates
• Prioritize zero-page storage for position variables
• Apply self-modifying code for runtime step-value adjustment during rapid scrolling
• Schedule position calculation within interrupt contexts where timing permits
• Commit sprite register updates during vertical blanking or lower border periods
• Undocumented opcodes provide additional cycle savings in critical paths
• Self-modification throughout reduces conditional branching overhead

Synchronous scroll updates ensure sprite world-to-screen transformations occur exactly when scroll position changes. Asynchronous updates can produce single-frame positioning errors where sprites appear to “jump.”

Zero-page storage accelerates the frequent position variable access that geo-referencing requires. The 3-cycle advantage per access accumulates significantly across multiple sprites each frame.

Self-modifying code adapts to varying scroll speeds. Rather than loading step values from memory each frame, self-modification writes new step values directly into instruction operands when speed changes.

Design Considerations

Before implementing geo-referenced sprites, evaluate whether the design genuinely requires persistent positioning. Many successful games avoid this complexity through alternative approaches:

One-way scrolling: Players only progress forward. All enemy positioning becomes relative to scroll progress with no need for persistence.

Screen-based levels: Each screen is independent; returning to a previous screen resets enemy positions.

Respawning enemies: Enemies regenerate when areas scroll back onto screen rather than persisting in previous states.

Geo-referencing proves most valuable when persistent world state contributes meaningfully to gameplay—exploration games, puzzle games with positional elements, or tactical combat games.

Resources

Implementation examples and motion calculation spreadsheets available upon request.

See also: The Wild Wood engine teardown · vertical parallax landscapes · Seawolves engine techniques · Seawolves