Ant64 Proposed Games

Overview

The Ant64 is not primarily a games machine — it is a creative computer for musicians, coders, and makers. But it is a computer with hardware that maps remarkably well to several categories of game rendering, and a 1GHz RISC-V big core running bare-metal C++ alongside a dedicated rendering co-processor is a genuinely capable games platform.

The games documented here are selected on a single criterion: the Ant64's hardware provides a specific, architectural solution to their rendering problem — not just "runs faster than period hardware" but "has a dedicated unit for exactly this algorithm." Each game in this document has at least one such match.

All games are open source. Engine source licences are noted per game. Asset licences vary — where commercial assets are required, free replacements are documented.

Games run as bare-metal big core C++ applications, the same execution model as the music workstation app. The big core handles all game logic; FireStorm handles all rendering. The CPU never touches pixels.

Doom is documented first and in most depth as the archetypal case — its hardware fit with the Ant64 is the clearest of any game in this collection, and its visual effects system establishes patterns used by the other games.

Launching from AntOS:

game doom          # Doom WAD player
game cave_story    # Cave Story (NXEngine-evo) — free, no ROM needed
game zelda3        # Zelda: A Link to the Past — requires zelda3.sfc
game super_metroid # Super Metroid — requires sm.smc
game smw           # Super Mario World — requires smw.sfc
game quake         # Quake engine
game wolf3d        # Wolfenstein 3D
game openttd       # OpenTTD
game julius        # Caesar III engine
game openrct2      # RollerCoaster Tycoon 2
game armagetron    # Armagetron Advanced (Tron light cycles)
game taisei        # Taisei Project (bullet hell)
game veloren       # Veloren (voxel RPG)
game openxcom      # OpenXcom (X-COM)
game oolite        # Oolite (Elite-style space trading/combat)
game pioneer       # Pioneer (Frontier-style Newtonian space sim)
game veil          # Veil (original Ant64 space game, CC0)
# ── N64 decompilations (ROM required) ────────────────────────────────────────
game oot            # Zelda: Ocarina of Time (N64 decomp — ROM required)
game mm             # Zelda: Majora's Mask (N64 decomp — ROM required)
game sm64           # Super Mario 64 (N64 decomp, CC0 code — ROM required)
game goldeneye      # GoldenEye 007 (N64 decomp, MIT — ROM required)
game perfectdark    # Perfect Dark (N64 decomp, MIT — ROM required)
game mk64           # Mario Kart 64 (N64 decomp — ROM required)
game banjo          # Banjo-Kazooie (N64 decomp — ROM required)
game starfox64      # Star Fox 64 (N64 recomp — ROM required)
game papermario     # Paper Mario (N64 decomp — ROM required)
game cannonball    # Cannonball enhanced OutRun engine — requires Sega ROMs
game supertuxkart  # SuperTuxKart (kart racing, fully free)
game sunrise       # Sunrise Drive (original OutRun-spirit racer, CC0)
game powermanga    # Powermanga (vertical shmup, GPL v3, free assets)
game vicraider     # Vic Raider (original horizontal shooter, CC0)
game thelongdark   # The Long Dark (original Gothic platform action, CC0)
# ── Deluxe Pixel originals ──────────────────────────────────────────────────
game dungeons      # Dungeons (Deluxe Pixel, 1-2 player dungeon crawl)
game retrostar     # RetroStar (Deluxe Pixel, 3D arcade space combat)
game zombies       # Zombies! (Deluxe Pixel, Lemmings-style)
game zombierocks   # Zombie Rocks! (Deluxe Pixel, Boulder Dash-style)
game footymanager  # Footy Manager (Deluxe Pixel, football mgmt + arcade)
game pingpongdx    # Ping Pong DX (Deluxe Pixel, arcade — Colony showcase)
game match3        # Match 3 Martians! (Deluxe Pixel, puzzle)
game rainbow2048   # Rainbow 2048 (Deluxe Pixel, puzzle)
game sudoku        # Sudoku Challenge (Deluxe Pixel, puzzle)

Hardware Capability Index

Which FireStorm hardware each game primarily benefits from:

Doom

Engine: id Tech 1 (original GPL source + community ports) Licence: GPL v2 — engine and game code Assets: Commercial (id Software) — WAD files required; FreeDoom ships as default Free alternative: FreeDoom 1 and 2 — BSD licence, complete replacement IWADs, ships with the Ant64

Overview

Doom is not just a game the Ant64 can run — it is a game the Ant64 was, in a meaningful architectural sense, built to run well. The two algorithms at the heart of the Doom engine are BSP tree traversal for sector visibility ordering and DDA ray casting for wall column rendering. FireStorm has dedicated hardware units for both. The match between the engine's requirements and the hardware's capabilities is exact enough to be striking.

The Ant64 Doom implementation is a bare-metal big core C++ application — the same execution model as the music workstation app — that runs the Doom game logic natively on the C906 at 1GHz while offloading all rendering to FireStorm's hardware accelerators and blitter. The result is a Doom that plays correctly, looks better than any period hardware could produce, sounds dramatically better than OPL2 or Sound Blaster 8-bit, and uses the Ant64's specific capabilities in ways that no other platform offers.

Legal Basis

The engine: The Doom engine source code (id Tech 1) was released by id Software in 1997 under the GPL. It is free to use, study, modify, and distribute under GPL terms. The Ant64 implementation is a new port — written from scratch in bare-metal C++ for the C906, referencing the original GPL source as a specification document — rather than a direct recompilation of the GPL code. Either approach is legally clean.

The WAD files: The IWAD files — doom.wad, doom2.wad, heretic.wad, etc. — are still commercial products owned by id Software / Bethesda / ZeniMax. Players must own a legitimate copy. The Ant64 Doom player reads WAD files from the SD card; it does not ship WAD data.

FreeDoom: The FreeDoom project provides completely free replacement IWAD files — freedoom1.wad and freedoom2.wad — under a BSD licence. These are fully compatible with the Doom engine and ship with the Ant64 as the default playable content, meaning the machine is immediately playable out of the box without requiring a commercial WAD purchase.

PWADs and community WADs: Thousands of community-created WAD files are freely available. The Ant64's 256GB internal SD accommodates an enormous WAD library.

Architecture

C906 Big Core (1GHz, bare metal C++)
    │
    ├─ WAD parser — reads level data, textures, sprites, sounds from SD
    ├─ Game loop — player physics, enemy AI, game state, input handling
    ├─ BSP dispatch — walks the BSP tree, dispatches to FireStorm hardware
    ├─ Sprite dispatch — sends enemy/item positions to FireStorm sprite layer
    ├─ Audio event dispatch — triggers SFX voices via QSPI on game events
    └─ QSPI → FireStorm (all rendering commands, no pixel work on CPU)

FireStorm (hardware rendering pipeline)
    │
    ├─ BSP traversal engine — walks BSP tree autonomously from viewpoint
    │   outputs visible sector list to FIFO, EE reads ordering
    ├─ DDA ray cast units — 480 columns cast in parallel (Standard resolution)
    │   returns hit distance, face, texture column offset per column
    ├─ Reciprocal unit — converts distances to column heights in 2-4 cycles
    ├─ Blitter — draws textured column spans to bitmap layer
    │   wall textures from Graphics SRAM (texture atlas)
    │   floor/ceiling from Mode 7 affine tilemap blit
    ├─ Hardware sprite layer — enemies, items, weapons — above blitter layer
    │   zero additional render cost per sprite
    ├─ CRT simulation pipeline — period-accurate display character
    └─ Audio DSP — all sound effects and music, 128+ voices

Pulse (RP2350)
    │
    └─ Jog dials as weapon select / map navigation / menu control
       RGB LED feedback — health bar colour, ammo level, powerup status

The C906 never touches a pixel. Every rendered element — walls, floors, ceilings, sky, enemies, items, HUD, menu — is handled by FireStorm. The CPU's full 1GHz is available for game logic, AI, physics, and WAD management.

How the Hardware Maps to the Engine

BSP traversal — Doom's engine walks a precomputed BSP tree every frame to determine which sectors are visible and in what front-to-back order. On the original 486 this was a software loop consuming a significant fraction of the frame budget. The FireStorm BSP traversal engine walks the tree autonomously from the current viewpoint, outputting visible subsectors to a FIFO. The C906 simply reads the FIFO to get the ordered sector list. The BSP walk costs near-zero CPU time.

DDA wall casting — Doom casts one ray per screen column, stepping through the BSP sector grid until hitting a wall. On the original 486 the column loop was the single most expensive operation in the renderer. The FireStorm DDA units cast all 480 columns simultaneously at Standard resolution. The entire column cast completes in well under a frame period. What consumed most of a 486's frame budget is a rounding error on the Ant64.

Reciprocal unit — converting ray hit distance to projected column height requires a divide per column. The FireStorm reciprocal unit computes this in 2–4 cycles using Newton-Raphson refinement, vs 16–32 cycles on the EE. 480 columns × 2–4 cycles = under 2,000 cycles for the entire height calculation pass.

Textured column spans — the blitter draws each wall column as a vertical textured span, sampling from the texture atlas in Graphics SRAM. Texture coordinates are the texture column offset returned directly by the DDA units — no additional calculation. The blitter's perspective-correct sampling handles texture distortion correctly at no extra CPU cost.

Floor and ceiling — rendered via Mode 7 affine tilemap blit with a per-scanline matrix list computed by the EE from the floor/ceiling geometry. The Copper drives per-scanline register updates for the matrix parameters, making floor and ceiling rendering a blitter job dispatched once per frame.

Sprites — enemies, items, decorations, and the weapon are hardware sprites on the layer above the blitter. Doom's sprites are pre-composited billboards — the WAD loader uploads the sprite frames to Graphics SRAM at level load time. The C906 computes screen position and scale per sprite per frame and writes to the FireStorm sprite attribute table. The hardware sprite engine handles sorting, occlusion, and rendering with no blitter involvement. Hundreds of sprites per scanline — far beyond anything Doom requires.

Sky — rendered as a scrolling HAM24 texture layer behind the world geometry layer. The original Doom sky is a flat 256-colour bitmap; the Ant64 version uses a HAM24 sky with full photographic colour depth, scrolling with the player's horizontal rotation via the Copper's per-scanline H_scroll register.

The HUD — rendered as a separate Hires (960×540) layer above the game layer, giving sharp pixel-perfect status bar graphics at double the game resolution. The status bar's colour (health green → yellow → red) is driven in real time by the Copper, which writes palette entries on the relevant scanlines based on the player's current health value. No CPU framebuffer writes needed to update health colour.

Display Enhancements

Native resolution options:

The authentic 320×200 mode uses the 4:3 pixel aspect ratio compensation built into the native resolution system — the non-square pixels of the original DOS display are reproduced correctly, so the geometry looks exactly as it did on a period monitor rather than stretched.

CRT simulation profiles applicable to Doom:

• JAMMA Arcade — the closest to how Doom looked in the few arcade appearances of the era; bright, punchy, slight green phosphor bias
• Generic SCART TV — how most European players experienced it on a TV; warm, slightly soft, strong scanlines, nostalgically accurate
• Sony PVM — the "correct" look that game developers saw; sharp, accurate, the pixel art reads as intended
• Aperture Grille — the Trinitron look; sharper and more saturated than shadow mask, the look of a high-end desktop monitor setup

Each profile is a register write via DeMon at launch, selectable from the Doom options menu. The display output can simultaneously run CRT simulation on HDMI and clean flat output on DisplayPort (Ant64C) — allowing side-by-side comparison or a capture card on the clean output while playing on the CRT-simulated display.

Lighting and colour:

Doom's original lighting is a simple 32-level sector brightness table — each sector has a light level 0–255 that maps to a colour map entry. The Ant64 version uses this data but renders it via the Copper-driven per-scanline bloom intensity register rather than the palette colourmap approach. Brighter sectors have active bloom on the texture layer; darker sectors have reduced bloom and slightly increased shadow density. The result is more atmospheric than the original flat sector brightness, with bright areas appearing to glow slightly and dark corridors feeling genuinely dark rather than palette-remapped.

This is one Copper register write per sector boundary crossing — trivially cheap and indistinguishable from magic.

Audio

Doom's audio divides into two parts with different enhancement paths:

Sound effects — Doom uses 8-bit PCM samples at 11kHz or 22kHz for all SFX: the shotgun, the imp fireball, the door grinding, the player death. These load from the WAD into Graphics SRAM at level start. The Ant64's SFX engine plays them via the sample playback voices. Enhancement options:

• Authentic: WAD samples played back directly — period-accurate, exactly as shipped
• Enhanced: each canonical SFX triggers a parallel procedural synthesis voice using the SFX archetype system. The shotgun sample plays alongside a synthesised transient that adds low-frequency body the 8-bit sample lacks. The imp fireball gains a synthesised mid-frequency crackle underneath. The door sound gains a sub-bass thud. Each enhancement is authored as a small SFX patch — a few bytes — mapped to the WAD lump name
• Positional: all SFX pan with the source's screen X position using the pan matrix. Enemies on the left of the screen sound from the left. Running past a barrel sounds like running past a barrel in physical space

Music — Doom's soundtrack is stored as MUS format (a compact MIDI variant) in the WAD. The Ant64 converts MUS to standard MIDI at load time and plays it through the full FireStorm synthesis pipeline. The question is which synthesis voice to assign to each MIDI channel.

Options selectable from the Doom menu:

• OPL2 authentic: VA engine configured to emulate the Yamaha OPL2/OPL3 FM synthesis chip of the original Sound Blaster. The specific FM operator algorithms and waveforms that Bobby Prince used. This is how the music was designed to sound.
• OPL enhanced: OPL2 timbre but with the full BBD chorus and FDN reverb added. The compositions were written for OPL2 but they were always trying to sound like more — this gives them the space and warmth they were reaching for.
• Full synthesis: each MIDI channel remapped to a VA or FM patch appropriate to its musical role. Lead melodies to expressive VA voices. Bass to the full ladder filter with sub-octave. Percussion to the SFX engine with physical modelling. The soundtrack becomes a full modern synthesis arrangement of Bobby Prince's compositions.
• MIDI out: the MUS-derived MIDI stream sent to a connected hardware synthesiser via Pulse's DIN MIDI output (Ant64C) or USB MIDI. Play Doom through a real hardware synth of your choice.

The OPL2 authentic mode specifically is a hardware showcase in its own right — the VA engine emulating a chip synthesiser with period accuracy, as a deliberate constraint.

3D positional audio:

The FireStorm audio DSP supports per-voice stereo pan matrix updates at sample rate. The C906 computes the angular position of every active SFX source each frame and writes pan values to the corresponding voices via QSPI. Running from an imp on the right while a pinky charges from the left sounds appropriately terrifying from both sides simultaneously. This was computationally expensive in 1993. On the Ant64 it is a QSPI register write per active sound per frame.

Multiplayer via Colony Connection

The Colony Connection on Ant64 and Ant64C provides a hardware point-to-point interconnect between machines. Two Ant64s connected via Colony can run Doom cooperative or deathmatch without any network stack overhead — the game state synchronisation runs over the Colony link directly, with DeMon managing the physical connection.

The Colony link's bandwidth (up to 7.83 Gbps per lane) is orders of magnitude more than Doom's multiplayer protocol requires. Latency is determined by the physical cable, not protocol overhead. Two machines one metre apart will have sub-millisecond round-trip game state latency.

For machines not physically adjacent, WiFi and Ethernet (Ant64C) carry the Doom multiplayer protocol over UDP in the standard way, using AntOS's TCP/IP stack on the little core.

The TPU and Enemy AI

The SG2000's 0.5 TOPS INT8 tensor processing unit is available to the big core for inference tasks. Doom's enemy pathfinding and behaviour are simple finite state machines — no AI enhancement is needed for authentic play. But the TPU enables optional enhancements:

• Improved pathfinding: a small trained model (fits comfortably within TPU capacity) that gives enemies more believable routing through complex level geometry, finding flanking paths rather than walking directly into walls
• Difficulty scaling: a model that observes player behaviour and adjusts enemy aggression and accuracy in real time — more sophisticated than Doom's fixed skill levels
• Enemy recognition for demo playback: when playing back Doom demo files (the .lmp format), the TPU can classify enemy activity from the game state for automatic highlight detection — finding the most intense combat sequences in a recorded demo

All TPU enhancements are opt-in from the options menu and default off for authentic play.

Jog Dial Controls

Pulse's eight jog dials with integrated push buttons offer a control model that keyboard and mouse do not:

Dial push buttons: fire (3), use/open (4), run (1+2 hold), map toggle (8).

The RGB LEDs provide live game state feedback:

• Health: dial 1+2 brightness and colour shift from green (100%) through yellow to red (critical), matching the status bar colour
• Ammo: dial 3 brightness proportional to current weapon's ammo count — dims as ammo depletes, flashes on pickup
• Powerups: dial 7 pulses white when invulnerability is active; flashes blue for radiation suit; glows red for berserk

Particle and Visual Effects

One of the most visually significant differences between Doom on the Ant64 and Doom on any period hardware is the particle and effect system. The original engine has essentially no particle effects — every visual event is a sprite animation: the bullet puff, the blood splat, the rocket explosion, the teleport flash. Each is a flat bitmap at a fixed screen position. There is no physics, no persistence, no interaction with the environment.

The Ant64's blitter particle system — blit.particlelist with BLT_ADDITIVE|BLT_BLOOM — is a natural replacement for every one of these. The sprites remain as fallback for the authentic mode; in enhanced mode each game event dispatches a particle list job to the blitter alongside or instead of the sprite. The C906 triggers the effect; FireStorm renders it; the CPU moves on immediately.

All effects are opt-in per category from the options menu, defaulting to authentic sprite-only behaviour. Individual categories can be mixed — particle blood with sprite explosions, or the reverse — because each enhancement is independent.

Hitscan Impacts — Bullet Puffs and Blood

Original behaviour: A single puff sprite (grey smoke for wall hits, red blood for enemy hits) appears at the impact point for a few frames then disappears. No physics. No persistence. Single frame, flat colour.

Enhanced behaviour:

Wall hits: A small burst of debris particles ejected from the impact point, velocity vectors fanning outward from the surface normal. Concrete dust: grey-white particles with low bloom intensity, high falloff — they catch the surface lighting and fade quickly. For metal surfaces (determined by the texture being hit, crossreferenced against a small lookup table of texture names to material types), the particles are brighter with a brief spark trail — a few frames of high-intensity orange-white before fading to grey. The puff sprite is suppressed; the particle burst replaces it entirely.

The surface normal is computed from the DDA unit's returned hit face (N/S/E/W wall) — the same data used for texture column selection. No additional geometry query needed.

Enemy hits: Blood. Not a sprite — a physics simulation. 8–16 particles per hit, ejected from the impact point in a cone weighted toward the incoming projectile direction. Each particle has:

• Initial velocity from the impact direction, randomised ±30° in a cone
• Gravity applied each frame — the particles arc downward
• Bounce coefficient — particles that reach floor height stop rather than continuing through the floor geometry (floor height is available from the BSP sector data)
• Colour: deep red, high bloom intensity at spawn, fading over 12–20 frames
• Trail: a spark trail of 3–4 diminishing particles behind each main particle for the first few frames

The result is blood that splatters with physical plausibility — impacts from the right leave blood arcing left and downward, floor hits splatter upward in a low fan, ceiling hits cascade downward. The particles are additive-blended with bloom, so clustered impacts (chaingun fire) build up intensity at the impact zone before fading.

Persistent splats: Blood particles that reach floor level leave a small persistent mark — rendered not as a sprite decal but as a tiny dim bloom point at the floor surface that fades over 30–60 seconds. In prolonged combat the floor accumulates a record of where damage occurred. This costs one blitter particle per splat, additive-blended at near-zero intensity after landing.

Explosions — Rockets, Barrels, BFG

Original behaviour: A multi-frame sprite animation plays at the explosion origin. Flat, same apparent size regardless of distance, no light emission, no debris.

Enhanced behaviour:

Rocket explosion: Three simultaneous particle list jobs dispatched on detonation:

1. Core flash — 20–30 high-intensity white-orange bloom particles in a tight sphere burst, high falloff, fade over 4–6 frames. This is the initial detonation flash — bright, brief, central.

2. Debris cloud — 40–60 slower particles, darker orange-red, lower intensity, physics-driven with gravity. These are the burning fragments — they arc outward and downward, some reaching floor level and leaving brief persistent sparks. The velocity distribution is spherical with upward bias — explosions throw more material upward than downward.

3. Smoke column — 15–20 very slow upward-drifting particles in dark grey, very low intensity, large bloom radius, extremely low falloff. These persist for 3–5 seconds, drifting upward slowly, giving the explosion a lingering smoke presence. In an enclosed room multiple explosions build visible smoke layers.

The Copper writes a brief increase to the ambient bloom intensity register at the moment of detonation — the whole screen flashes slightly, simulating the real-world light emission of a nearby explosion. The flash lasts two frames and fades over the next four. This single Copper register write costs nothing and is the most impactful single-frame visual event in the entire effect system.

Barrel explosion: As rocket but with more debris particles (barrels throw heavy fragments) and a more persistent smoke column. The bloom flash is slightly redder.

BFG explosion: The BFG9000's plasma burst is already green in the original. The enhanced version uses the vector CRT simulation bloom preset — the same additive particle system used for vector arcade games — for the BFG's impact. The green plasma ball leaves a bloom trail as it travels (a few particles per frame from the projectile's previous position), and the detonation is a wide low-falloff bloom burst in bright green. The BFG energy lines (the secondary tracers that fire after impact) are rendered as blit.line_bloom primitives — actual lit lines rather than sprite graphics.

Projectile Trails

Original behaviour: Rockets and plasma balls are sprites. No trail. Position updates per frame.

Enhanced behaviour:

Rocket trail: Each frame, 3–5 smoke particles are emitted from the rocket's current position with near-zero initial velocity — they instantly begin falling and drifting. They are dark grey, very low intensity, large radius, slow fade. The rocket leaves a physics-accurate smoke trail that lingers in the air behind it, dispersing gradually. In enclosed spaces the trail fills the room with smoke texture over the course of a sustained firefight.

Plasma ball: Each plasma ball emits 2–3 bright cyan particles per frame with slight random scatter from the projectile's path. Low falloff — the trail is a soft glowing smear. The plasma ball itself is redrawn each frame as a bloom particle rather than a sprite, giving it a physically lit glow that the sprite cannot.

Cacodemon fireball: Dark red bloom trail, 2–3 particles per frame, slower than plasma. The fireball sprite is retained but surrounded by a bloom halo rendered as a large-radius low-intensity bloom particle at the same position each frame.

Weapon Effects

Shotgun: The original has a brief muzzle flash sprite. The enhanced version adds a blit.particle at the muzzle position — maximum intensity, zero falloff, single frame — plus a cone of 6–8 tiny spark particles ejecting forward and upward with short trails. The Copper writes a brief ambient bloom intensity spike on the frame of fire (same mechanism as the explosion flash, but briefer and less intense). The muzzle flash illuminates the immediate environment for one frame.

Chaingun: Same as shotgun but firing continuously. The spark particles accumulate if the rate of fire exceeds their fade rate — continuous fire builds a glowing spark cloud at the muzzle. The ambient bloom pulse fires on every shot, creating a visible strobing brightness effect in dark corridors that matches the sound rhythm.

Rocket launcher: Rocket ignition at the muzzle emits a large initial smoke puff — 10 particles — that immediately begins the smoke column behaviour described above. The launch frame has a brief bright back-blast particle burst directed backward from the muzzle (physically, launching a rocket pushes exhaust backward).

BFG9000: The charging animation (the original has a glowing sphere in the weapon sprite) is augmented with a large bloom particle at the barrel position that grows in intensity over the 1-second charge time. When fired, the flash is the brightest single-frame event in the game — a full-screen ambient bloom spike for two frames that briefly washes out nearby surfaces before fading.

Pistol / chainsaw / fist: Minimal enhancement — brief single-particle muzzle flash for the pistol, no effect for melee. These weapons are deliberately understated in the original and the enhancements respect that.

Environmental Atmospheric Effects

Torches and light sources:

Doom's torches are animated sprites with no light emission — they flicker but do not illuminate anything. The enhanced version:

• Each torch sprite in a level is identified by its sprite lump name (TRED, COLU, etc.) from a lookup table at level load
• A persistent bloom particle is placed at each torch's world position, rendered each frame at a position computed from the BSP sector and player viewpoint
• The particle has warm orange colour, large radius (~48px at close range), low falloff — it casts a glow onto nearby walls and floor
• The intensity oscillates at ~8Hz with slight random phase variation — the torch flickers
• At close range the Copper writes a per-scanline warm colour tint on the scanlines corresponding to the torch's screen position, warming the rendering in the torch's immediate area

The effect makes torchlit Doom levels feel genuinely atmospheric rather than uniformly lit. The E1M1 zigzag room with its many torches becomes a warm, flickering, shadowed space.

Nukage and slime pools:

Nukage floor textures (NUKAGE1/2/3, SLIME01-09) are identified at level load. Each nukage sector has a low-intensity green bloom layer applied — the floor appears to emit faint radioactive light. When the player is standing in nukage, a subtle green colour tint is added to the lower third of the screen via a Copper register write on the corresponding scanlines.

Nukage damage events (the player losing health in a nukage pool) spawn a small upward particle burst — 4–6 bubbles of bright green rising from the player's position, additive-blended, fading quickly. The player can see the pool reacting to their presence.

Teleporters:

The original teleporter uses a fog sprite. The enhanced version:

• On entry: a spiral of 20–30 particles rising from the pad, bright white, high intensity, rapid fade — the "departure" effect
• On exit: a burst of 20–30 particles radiating outward from the arrival point, same colour, slightly lower intensity — the "arrival" effect
• The Copper writes a full-screen white flash (single frame, full bloom intensity) on the frame of teleportation, fading over 4 frames — a disorienting brightness event that matches the jarring spatial discontinuity

Crusher and door debris:

Doors and crushers generate small dust particle bursts when they start moving — a few grey particles falling from the top of a closing door, rising briefly from the floor when a crusher activates. These are subtle ambient particles that make the architecture feel physical.

Water and slime surface:

Doom has no dynamic liquid surfaces — water and slime textures scroll via texture animation. The enhanced version adds sparse bubble particles rising from any liquid-tagged floor sector — 1–2 bubbles per second per visible liquid sector, tiny, low intensity, rising slowly. Individually imperceptible; collectively they make the liquid surfaces feel alive.

Sector Lighting Enhancement

The original Doom lighting system assigns each sector a flat brightness value 0–255 that is applied as a colour palette lookup — darker sectors have a darker colourmap applied to every texture in them. The result is uniform flat-shaded sectors with hard lighting boundaries at sector lines.

The Ant64 version retains the sector brightness as the base value but adds two enhancements:

Bloom-driven lighting: Sector brightness maps to the Copper's per-scanline bloom intensity register at sector boundary crossing. Bright sectors (light level 240–255) have bloom active — textures appear to glow slightly, as if lit by real light sources. Dark sectors (light level below 64) have bloom suppressed and a slight additional shadow density. The transition between adjacent sectors with different light levels is a Copper register change at the sector boundary crossing — one write, zero cost.

Flickering sectors: Doom has several light special types: flicker (type 1), blinking (type 3), oscillating (type 8 and 12). In the original these are achieved by modifying the sector's light level value on a timer. On the Ant64 the same timer drives a Copper bloom intensity modulation rather than a colourmap swap — the flickering effect is physically more convincing because it modulates apparent light emission rather than palette remapping.

Effect Quality Levels

All effects are categorised and individually controllable from the options menu. Three preset levels exist as starting points:

Individual categories override the preset. A player who wants authentic blood but enhanced explosions sets the preset to Authentic and enables Explosions separately.

The maximum preset with all effects active adds approximately 2–4ms to the frame render time at Standard resolution — well within the 16.7ms frame budget at 60fps. The particle lists are blitter jobs dispatched alongside the main render; most run in parallel with other blitter work and cost real time only when the particle count is high. A room full of barrels exploding simultaneously is the worst case — and even that is comfortable at Standard resolution.

WAD Compatibility

The implementation targets compatibility with the major WAD formats in use:

The 256GB internal SD accommodates the entire community WAD catalogue many times over. A curated WAD library installer runs via AntOS, fetching freely distributable WADs from the community repositories over WiFi.

A Note on FreeDoom

FreeDoom ships as the default playable content on every Ant64. It is a complete, free replacement IWAD — two full games, 60+ maps, compatible with the enormous Doom community WAD library. It is BSD licensed. There are no legal complications, no purchase requirement, no grey areas.

Players who own commercial WADs (Doom, Doom 2, Heretic, Hexen) copy them to the SD card and the launcher detects them automatically. But FreeDoom means the machine is playable from the moment it arrives, which is the right experience for a machine that is meant to be used immediately.

Storage

The Doom implementation lives on the SD card rather than the FPGA flash partition — it is a full application, not a boot-time showcase.

AntOS application:
  doom_ant64 binary (big core C++):               ~2 MB
  FireStorm EE modules (renderer):                ~150 KB
  SFX enhancement patch library:                   ~40 KB
  OPL2 emulation VA patches:                       ~20 KB
  Full synthesis MIDI patch bank:                  ~80 KB
  FreeDoom1.wad + FreeDoom2.wad:                  ~600 MB
  ──────────────────────────────────────────────────────
  Total (excluding commercial WADs):              ~603 MB

Commercial WADs are user-supplied. A full Doom/Doom2/Heretic/Hexen collection adds approximately 50MB. The 256GB SD has effectively unlimited capacity for WAD files.

Launching

# From AntOS shell:
doom

# With specific WAD:
doom --iwad doom2.wad

# With PWAD:
doom --iwad doom2.wad --pwad mymod.wad

# FreeDoom (default):
doom --iwad freedoom2.wad

# With display profile:
doom --crt pvm

# OPL2 authentic audio:
doom --audio opl2

# Full synthesis audio:
doom --audio synthesis

Wolfenstein 3D

Engine: id Tech 0 (Wolf4SDL / ECWolf) Licence: GPL v2 — engine and game code Assets: Commercial (id Software) — free replacement assets not available Asset path: Original data files required from user; GOG/Steam versions supported

The Hardware Match

Wolfenstein 3D is a pure DDA ray caster. Every column on screen is cast by stepping a ray through a 64×64 tile grid until hitting a solid wall. On the original 286/386 this was the entire renderer — no BSP, no floor/ceiling, just the wall column loop.

The FireStorm DDA units cast all 480 columns simultaneously at Standard resolution. The renderer that ran the original game on a 286 at 15fps runs at 60fps on hardware purpose-built for it, with all 480 rays in parallel.

Wolfenstein 3D is, in a real sense, the game the DDA hardware was designed around — or at least the ancestor of those games. Running it on the Ant64 is a direct lineage demonstration.

Architecture

C906 big core (1GHz, bare metal)
  ├─ Game logic — AI, doors, pickups, player state
  ├─ Map management — 64×64 tile grid in L1 cache
  └─ QSPI → FireStorm

FireStorm
  ├─ DDA unit pool — 480 parallel rays
  ├─ Reciprocal unit — distance to column height
  ├─ Blitter — textured column spans
  ├─ Hardware sprites — guards, objects, pickups
  └─ Audio DSP — SFX and music

The 64×64 map fits entirely in BSRAM alongside the texture set. DDA stepping accesses the map with 1-cycle latency per step — no page misses, no cache pressure.

Display Enhancements

Resolution options:

• Authentic 320×200 with correct 4:3 pixel aspect ratio compensation
• Standard 480×270 for clean integer scaling
• Double 640×360 for higher detail

CRT simulation — the Wolfenstein look is strongly associated with VGA monitors of the early 1990s. The PC Monitor CRT profile (slot mask, boundary darkening) is the most authentic. The JAMMA Arcade profile produces a striking alternative aesthetic.

Sector lighting — the original Wolfenstein has no lighting variation between rooms. An optional enhancement applies the sector brightness data from the map (door colour codes and room type) as Copper-driven bloom intensity variation — guard rooms are slightly brighter, secret areas slightly darker. Subtle and opt-in.

Visual Effects

Bullet impacts — the original has no impact effects at all; bullets simply remove enemy health silently. Enhanced mode adds a small debris particle burst at the wall hit position using the DDA hit face for the surface normal, identical to the Doom implementation. Small sparks for metal surfaces (the grey wall textures), plaster dust for stone.

Death effects — enemy death is a sprite animation in the original. Enhanced mode adds a blood particle burst — 6–10 particles, physics-driven, gravity applied, directional from the killing shot.

Secret door discovery — when a secret door is triggered, a brief bloom flash particle burst fires from the door position. One frame of ambient brightness spike via the Copper. The satisfying secret-found moment becomes physically real.

Weapon muzzle flash — a single-frame bloom particle at the gun position plus a brief ambient Copper brightness spike. The dark corridors strobe with chaingun fire.

Audio

The original Wolfenstein used an OPL2 AdLib soundtrack by Bobby Prince (the same composer as Doom). The same audio enhancement options apply:

• OPL2 authentic — VA engine emulating AdLib FM synthesis
• OPL2 enhanced — OPL2 timbre with BBD chorus and FDN reverb
• Full synthesis — each channel remapped to appropriate VA/FM patch
• MIDI out — MUS-derived MIDI to hardware synthesiser via Pulse

The digitised sound effects (the guard shouts, the gunshots) load from the game data and play via the sample playback engine with optional synthesis augmentation.

Quake

Engine: id Tech 2 (Quakespasm / vkQuake reference) Licence: GPL v2 (engine); Quake C game code also GPL Assets: Commercial (id Software) — Quake data files required Free alternative: Quake Epsilon provides some replacement assets; Open Quartz provides complete free replacement data

The Hardware Match

Quake brought two major advances over Doom: true 3D geometry (floors and ceilings at arbitrary heights, sloped surfaces) and software-rendered texture-mapped polygons. The original engine used a BSP tree extended to handle 3D leaf nodes and a surface-cache rendering system to avoid redundant texture work.

The Ant64 maps this directly to hardware:

• BSP traversal engine — handles the extended 3D BSP tree for front-to-back sector ordering, exactly as for Doom but with 3D leaf geometry
• Blitter textured triangles with perspective-correct UV — the wall and floor polygon spans that Quake's software renderer computed in software
• SVO traversal engine and ray-triangle intersection hardware — shadow rays against the scene geometry, producing real-time hard shadows that Quake's original renderer could not do at all

The shadow capability is the headline. Original Quake has no real-time shadows — it uses pre-baked lightmaps calculated offline. The Ant64 version uses BVH traversal (parameterised from the SVO engine) against the level geometry to cast shadow rays per frame, producing dynamic shadows from the player's torch and from moving enemies. This was beyond real-time hardware until very recently.

Architecture

C906 big core (1GHz, bare metal)
  ├─ QuakeC VM — game logic, entity management
  ├─ BSP level management — PVS calculation, entity culling
  ├─ Physics — collision, movement
  └─ QSPI → FireStorm

FireStorm
  ├─ BSP traversal engine — 3D BSP, visible leaf set
  ├─ Blitter textured triangles — wall and floor polygon rendering
  │   perspective-correct UV, bilinear sampling from Graphics SRAM
  ├─ BVH shadow rays — per-frame dynamic shadows
  │   using SVO traversal engine parameterised for BVH
  ├─ Ray-triangle intersection — per shadow ray
  ├─ Hardware sprite layer — status bar weapon, some particles
  ├─ Bloom particle system — torch particles, explosions, gibs
  └─ Audio DSP — all SFX and music

Levels and Assets in Graphics SRAM

Quake levels (BSP compiled .bsp files) range from ~1MB to ~8MB. The Ant64's 1GB FireStorm DDR3 (Ant64/Ant64C) accommodates the full level plus texture atlas in Graphics SRAM with room for intermediate render buffers. The texture cache is warm throughout a level with no streaming required — every texture for the level is resident simultaneously.

The Ant64S (8MB PSRAM) loads levels in streaming mode with a texture cache backed by the SG2000's 512MB DDR3. Performance is reduced but playable.

Display Enhancements

Dynamic shadows — the most significant enhancement, described above. The BVH is built from the level's polygon geometry at load time (~50ms for a typical level). Shadow rays cast per frame from the player's position and from active light sources (torches, rockets, explosions). Hard shadows with optional PCF soft edges.

HAM24 sky — Quake's sky is a scrolling texture. The Ant64 version replaces the sky box with a HAM24 layer, giving photographic colour depth to the sky. The HAM24 sky scrolls via Copper per-scanline H_scroll register updates at no CPU cost.

Bloom and particle effects — torch flames, explosion particles, gib debris all use the bloom particle system. The Quake rocket explosion is enhanced identically to the Doom version: core flash, debris cloud, persistent smoke column.

Liquids — water, lava, and slime surfaces use the caustic light overlay from the display system. The underwater environment preset from the audio system activates when the player is submerged — the muffle, pressure wobble, and slow chorus apply immediately on water entry.

CRT simulation — the PC Monitor profile suits Quake's aesthetic. The PVM profile produces a striking high-contrast look for the dark Gothic environments.

Audio

Quake uses WAV sound effects and a CD audio track (or a MOD file in some distributions). The SFX run through the sample playback engine with synthesis augmentation. The music — if using a freely-licensed MIDI or MOD arrangement — runs through the EE MOD player with full synthesis arrangement options.

The Quake ambient sounds (dripping water, wind, machinery) are particularly enhanced by the environmental DSP presets. The cavern preset on ambient water drips; the metal pipe preset on the machinery sounds; the underwater preset automatically engaging on submersion.

Multiplayer

The original Quake UDP network protocol runs over AntOS TCP/IP on the little core. Two Ant64s can play over WiFi with acceptable latency for the turn-rate of the game. Colony Connection (Ant64/Ant64C) provides sub-millisecond LAN-speed play between physically adjacent machines.

OpenTTD

Engine: OpenTTD Licence: GPL v2 — full engine and base graphics Assets: OpenGFX (GPL), OpenSFX (Creative Commons), OpenMSX (GPL) — all included Commercial assets: Original Transport Tycoon Deluxe data files also supported

The Hardware Match

OpenTTD is an isometric tile-based simulation with enormous sprite counts — trains, buses, ships, aircraft, station buildings, infrastructure, passengers, cargo all rendered as sprites over a scrolling isometric world. The original game's bottleneck on period hardware was the sheer number of sprites per frame.

The FireStorm isometric rendering system is purpose-built for exactly this:

• Isometric scanline mapper — maps screen Y positions to world tile coordinates, the core inner loop of any isometric renderer
• Diamond span unit — fills the diamond-shaped ground tiles
• Hardware sprite layer — hundreds of sprites per scanline
• Depth buffer — correct occlusion of sprites behind terrain and buildings, eliminating the painter's algorithm sort that taxes the CPU in software renderers

The depth buffer is particularly significant. OpenTTD's original renderer uses a painter's algorithm (draw back-to-front) to handle sprite occlusion. This requires sorting all visible sprites every frame — a CPU-intensive operation. The FireStorm depth buffer eliminates this entirely: sprites are written in any order, the hardware resolves occlusion per pixel.

Architecture

C906 big core (1GHz, bare metal)
  ├─ Game simulation — trains, economy, pathfinding, AI
  ├─ Viewport management — visible tile range calculation
  ├─ Sprite list dispatch — position and tile ID per visible object
  └─ QSPI → FireStorm

FireStorm
  ├─ Isometric scanline mapper — Y → tile coordinate
  ├─ Diamond span unit — ground tile fill
  ├─ Hardware sprite layer — all trains, buildings, vehicles
  │   sorted by depth buffer, no painter's algorithm needed
  ├─ HAM24 terrain layer — photographic landscape colour depth
  ├─ Copper-driven sky — horizon gradient, day/night cycle
  └─ Audio DSP — ambient sounds, music

Display Enhancements

HAM24 terrain — the ground tiles use HAM24 for photographic colour depth. Grass transitions smoothly through dozens of greens. Snow gradients across the full tonal range. Water with genuine colour depth from the HAM24 layer. The original game's 8-bit palette limitation disappears.

Day/night cycle — OpenTTD has an optional day/night cycle. The Ant64 version drives this via Copper per-scanline palette modification — the global colour temperature shifts from warm daylight through golden hour to cool night across a realistic atmospheric gradient. This is pure Copper register writing at no CPU cost.

Atmospheric particles — weather effects use the bloom particle system: rain as thin near-vertical bloom line streaks (using blit.line with BLT_BLOOM), snow as white bloom particles with sinusoidal drift, fog as a sparse low-intensity particle layer at ground level. Each weather type maps to a blitter job dispatched per frame alongside the main render.

Locomotive steam and smoke — each steam locomotive emits a smoke particle stream from its chimney — 2–3 particles per frame per locomotive, rising and dispersing. At a busy station with multiple trains this produces visible smoke filling the air above the platforms. The effect is additive-blended so it accumulates realistically in confined spaces.

Town lights at night — building windows lit at night are identified by sprite type and a small bloom particle placed at each window position. Towns glow warmly from a distance at night, each building contributing a few warm amber points. The combined effect of hundreds of lit buildings produces a realistic city glow.

Audio

OpenTTD's ambient sounds — train whistles, engine noise, ship foghorns, aircraft engines — use the sample playback engine. The train engine sound is enhanced with a synthesised sub-bass drone underneath the sample, giving steam and diesel locomotives more physical weight.

The music (OpenMSX provides GPL-licensed tracks) plays through the full synthesis arrangement — the orchestral pieces benefit particularly from the FDN hall reverb and the full voice count.

Positional audio: each visible vehicle has its sound panned to its screen position. A train crossing from left to right produces a genuine Doppler-panned experience.

Multiplayer via Colony Connection

OpenTTD supports multiplayer over TCP — the AntOS network stack on the little core handles this natively. Two to four Ant64s can run a cooperative or competitive game over WiFi. Colony Connection (Ant64/Ant64C) provides the lowest-latency physical connection for machines in the same location.

Julius / Augustus (Caesar III Engine)

Engine: Julius / Augustus (Caesar III open-source reimplementation) Licence: AGPL v3 Assets: Caesar III data files required (GOG/CD) Free alternative: No complete free asset set currently available

The Hardware Match

Caesar III is isometric city building — Roman city construction and management rendered as an isometric tile grid with hundreds of walking citizens, buildings, farm workers, soldiers, and animated structures simultaneously visible.

The hardware path is identical to OpenTTD: isometric scanline mapper, diamond span unit, depth buffer, hardware sprite layer. Caesar III has a higher sprite density per screen than OpenTTD because of the citizen walkers — 100+ individual animated figures are visible at any time in a large city.

The hardware sprite layer handles hundreds of sprites per scanline at zero additional render cost. The citizen walkers that would tax a software renderer are free in hardware.

Display Enhancements

HAM24 terrain — the lush Roman countryside uses HAM24 for photographic colour depth. The Tiber river, the farm fields, the burnt plains — all with the full tonal range the original 8-bit palette could only approximate.

Fire and smoke — Caesar III's fire spreading mechanic (buildings catch fire and burn until destroyed) is dramatically enhanced. Each burning building emits a sustained bloom particle fire column — orange-yellow particles rising, dark smoke above, the characteristic Bonfire Night visual effect. Multiple buildings burning simultaneously fill the sky with visible smoke. A city fire is genuinely alarming rather than a sprite animation change.

Festival effects — when a festival is held, a confetti burst particle system fires from the forum — the same confetti effect used in the boot intro calendar themes. Citizens near the forum react with visible colour change in their attribute sprites (a Copper palette write for their sprite palette ID).

Day/night — as OpenTTD, driven by the Copper at no CPU cost.

The Citizen Walker Enhancement

The most CPU-intensive aspect of Caesar III is pathfinding for the walker citizens — each of the 100+ simultaneous walkers runs a pathfinding algorithm to find their route. On the original Pentium this was a significant load.

The SG2000's TPU provides optional AI pathfinding inference — a small trained model that approximates the pathfinding calculation for walkers whose routes haven't changed, reducing CPU pathfinding calls by up to 80% on a stable city. The full pathfinding algorithm runs for new routes; the TPU approximation runs for stable routes. The player cannot tell the difference; the CPU has substantial headroom freed for larger cities.

OpenRCT2 (RollerCoaster Tycoon 2)

Engine: OpenRCT2 Licence: GPL v3 Assets: RollerCoaster Tycoon 2 data files required (GOG/Steam) Free alternative: OpenGraphics — partial free replacement asset set, ongoing development

The Hardware Match

RollerCoaster Tycoon 2 is the most sprite-dense isometric game in this collection. A busy park with multiple operational roller coasters, dozens of ride vehicles, hundreds of guests, trees, paths, stalls, and animated scenery can have thousands of sprites simultaneously visible on screen.

The hardware sprite system handles this without penalty. The depth buffer eliminates the painter's algorithm sort. The isometric hardware handles the tile geometry. OpenRCT2 is the game that most thoroughly exercises every aspect of the isometric rendering system simultaneously.

Display Enhancements

Ride vehicle particle effects — every roller coaster produces visual effects the original engine cannot:

• Speed blur: fast coaster vehicles emit trailing bloom particles behind them — 2–3 particles per frame per car, fading quickly. At speed the particle trail is a convincing motion blur streak
• Launch smoke: launched coasters (Stealth, Rita, launch track rides) produce a massive smoke and exhaust burst on launch — the rocket-launch particle effect from the Doom document applied to a roller coaster
• Water splash: log flumes and water coasters produce a bloom particle water splash at the bottom of drops — 20–30 white particles fanning upward and outward
• Coaster sparks: wooden coasters emit sparks on the steepest drops — the spark trail effect, brief high-intensity orange particles

Fireworks — OpenRCT2 has a fireworks editor for park fireworks displays. The Ant64 version uses the full boot intro fireworks particle system — bloom bursts with correct trajectory physics, multiple simultaneous origin points, spark trails on every particle. A designed fireworks show looks like a real fireworks show.

Guest density fog — in very busy parks, a subtle low-level particle haze builds above high-density crowd areas. Barely visible individually; collectively it suggests a warm summer crowd in a way flat sprite rendering cannot.

Balloon release effects — balloon stalls and special events that release balloons use rising bloom particles with the lantern-rising effect — large radius, warm colours, slow ascent.

Armagetron Advanced

Engine: Armagetron Advanced Licence: GPL v2 Assets: All free — engine and assets GPL

The Hardware Match

Armagetron Advanced is a Tron light cycle game — motorcycles driving on a grid, each leaving a permanent wall trail, the goal being to force opponents into walls or their own trail.

The wall trails are straight lines. Glowing straight lines on a dark background. The Ant64's blitter bloom line system — blit.line_bloom with BLT_ADDITIVE — is literally designed for this. The wall trails are the canonical use case for blit.line_bloom. The named vector presets in the blitter documentation — Tempest, Asteroids, Star Wars — are direct ancestors of the Armagetron aesthetic.

This is not a game that benefits from the Ant64's hardware. This is a game that is the hardware demonstration.

Architecture

C906 big core (1GHz, bare metal)
  ├─ Game physics — cycle movement, collision detection
  ├─ AI opponents — pathfinding and strategy
  └─ QSPI → FireStorm

FireStorm
  ├─ blit.line_bloom — all wall trails, every frame
  │   BLT_ADDITIVE | BLT_BLOOM, additive accumulation
  ├─ blit.particle — cycle engine glow, collision sparks
  ├─ Floor plane — Mode 7 affine tilemap, perspective grid
  └─ Audio DSP — engine hum, wall impacts, music

The Rendering Approach

Every wall trail is a blit.line_bloom call with the cycle's current colour, a high intensity, and moderate falloff. The floor grid is a Mode 7 affine tilemap blit with a Copper-driven per-scanline scale for the perspective effect.

Because trails use BLT_ADDITIVE blend, intersections and near-misses accumulate intensity. A corridor formed by two parallel trails glows brighter along its length than the individual trails. Close calls — near-miss manoeuvres where two trails pass within a few tiles — produce a brief intensity spike visible as a hot point on the grid. This is physically correct additive blending producing emergent gameplay feedback.

Wall collisions produce a particle burst: 10–15 high-intensity particles in the cycle's colour radiating from the impact point, fading over 4–6 frames. The explosion of a cycle hitting a wall is brief, bright, and satisfying.

Display Options

Grid appearance:

• Classic Tron grid: dark blue background, bright cyan lines, Mode 7 perspective
• Dark void: pure black background with no visible floor grid
• HAM24 arena: a photographic floor texture visible through the grid lines
• Wireframe: the grid rendered as bloom lines rather than a solid surface

Cycle body rendering:

• Flat sprite (authentic)
• Bloom-lit solid: the cycle rendered as a small set of bloom line segments, fully luminous with the trail glow effect
• Particle trail density: configurable particles-per-frame for trail decoration

Multi-Tate mode — four players in a 2×2 Tate grid, each in their own quadrant with their own grid and walls. Colony Connection handles the multiplayer synchronisation; the display uses the dual Tate mode layout at 4K.

Audio

The engine hum for each cycle uses the VA engine's sine oscillator — a continuous note whose pitch follows the cycle's current speed. Faster cycles produce a higher pitch. Multiple cycles produce a chord that reflects the current game state: a flat hum means everyone is stationary; a rising chord means everyone is accelerating.

The wall trail impact sound uses the SFX engine — a short electrical crackle, synthesised from noise + high-pass filter + fast decay. The collision explosion uses the explosion SFX archetype.

The music — Armagetron's soundtrack is electronic — plays via the full synthesis arrangement path, the EE MOD player augmenting original tracks with VA voices.

Taisei Project

Engine: Taisei Licence: MIT (engine); CC0 and CC BY 4.0 (assets) Assets: All free — ships with the game

The Hardware Match

Taisei is an open-source Touhou-inspired bullet hell shooter — dense patterns of enemy projectiles filling the screen, a player ship weaving between them, large enemy sprites, screen-filling boss attacks. It is one of the most visually dense genres in gaming.

Two hardware capabilities are the primary match:

Tate mode — vertical arcade games displayed on a landscape screen with rotated CRT simulation. Bullet hell is a vertical genre; Taisei was designed for a portrait-oriented display. The Ant64 renders Taisei in 270×480 native resolution with Tate mode active — the game fills a portrait orientation within the landscape screen, with authentic rotated CRT scanlines.

Hardware sprites at scale — hundreds of enemy bullets are individual sprites. The hardware sprite layer handles hundreds per scanline. In the most dense Taisei bullet patterns, the sprite count that would tax any software renderer runs on the Ant64 without measurable frame impact.

Architecture

C906 big core (1GHz, bare metal)
  ├─ Game logic — enemy patterns, collision, boss AI
  ├─ Bullet physics — position and velocity for hundreds of bullets
  └─ QSPI → FireStorm

FireStorm
  ├─ Hardware sprite layer — all bullets, enemies, player
  │   Tate mode active — portrait orientation on landscape screen
  │   rotated CRT simulation — scanlines run vertically
  ├─ Bloom particle system — spell card effects, explosions
  │   BLT_ADDITIVE — bullet grazes produce accumulating flash
  ├─ HAM24 background — stage backgrounds with photographic depth
  ├─ Copper — spell card colour shifts, boss intro flashes
  └─ Audio DSP — SFX and music

Bullet Grazed Effects

In Touhou-style bullet hell, "grazing" a bullet — passing extremely close without being hit — scores bonus points and is a core skill expression. The Ant64 version makes grazes visually dramatic:

When the player ship passes within a configurable proximity of a bullet without being hit, a brief bloom particle burst fires at the bullet's position — 4–6 small particles in the bullet's colour, radiating outward. With rapid grazing sequences this produces a trail of small sparkle bursts following the player's path through the bullet pattern. The skill expression becomes visible.

Spell Card Effects

Taisei's boss spell cards (large-scale attacks) use the full Copper and particle system:

• Card activation: a full-screen Copper colour shift — the background palette changes colour temperature over 8 frames as the card activates
• Card background: HAM24 background swap to a spell-card-specific image, transitioning via a Copper-driven dissolve effect
• Danmaku burst: the initial bullet release uses the full fireworks particle system — multiple burst origins, bloom particles, spark trails — before the pattern settles into its repeating form
• Card timeout/defeat: a large explosion particle system, screen flash, audio impact — the most intense visual event in normal gameplay

Dual Tate Mode — Two Players

At 4K output, two Taisei instances run simultaneously in the dual Tate configuration: two 270×480 portrait viewport layers side by side, each with independent sprite lists, each with its own CRT simulation. Two-player co-operative or competitive play, each player managing their own portrait field.

The C906 runs two independent game instances — one per player — on the same core via task switching. The FireStorm sprite system handles two independent layers with independent horizontal offsets. The Copper manages two independent display regions.

Audio

Taisei's music is electronic, ranging from J-pop influenced to harder electronic styles. The full synthesis arrangement runs for all tracks — the original game audio was already produced at a quality level that benefits from the FDN hall reverb and the full voice count.

The bullet SFX — each projectile type has a characteristic sound — use the sample playback engine. Dense bullet patterns produce overlapping SFX that the 128-voice pool handles without voice stealing.

The graze SFX is procedurally synthesised via the SFX engine — a short rising frequency sweep, bright and satisfying. Different graze distances produce different pitch sweeps, providing audio feedback for near-miss skill expression.

Veloren

Engine: Veloren Licence: GPL v3 Assets: GPL v3 — all included

The Hardware Match

Veloren is an open-world voxel RPG — exploration, combat, crafting, and social interaction in a procedurally generated voxel world. The rendering challenge is the classic voxel problem: efficiently drawing a world made of axis-aligned cubes at varying distances with correct occlusion.

Two FireStorm hardware units address this directly:

Height-field voxel accelerator — for terrain rendering, the height-field approach (casting rays forward along the ground, tracking the terrain height envelope) is appropriate for Veloren's outdoor landscapes. The hardware DDA units handle the ray stepping; the height map sampler reads terrain height and colour simultaneously; the span renderer draws the visible terrain faces.

3D voxel DDA units — for detailed close-range rendering (the interior of buildings, cave systems, the player's immediate environment) the 3D DDA approach handles dense voxel grids at 1-cycle latency per step.

The combination — height-field for distant terrain, 3D DDA for near-field detail — mirrors how high-quality voxel engines separate their rendering passes by distance.

Architecture

C906 big core (1GHz, bare metal C++)
  ├─ Game logic — entity management, combat, crafting, networking
  ├─ World simulation — terrain generation (chunked), entity AI
  ├─ Camera and visibility — chunk frustum culling
  └─ QSPI → FireStorm

FireStorm
  ├─ Height-field DDA — terrain at distance, hardware ray casting
  ├─ 3D voxel DDA — near-field detail, interior spaces
  ├─ Blitter textured triangles — character models, equipment meshes
  │   polygon mesh rendering for non-voxel elements
  ├─ Bloom particle system — spells, weather, ambient
  ├─ HAM24 sky and atmosphere — photographic sky depth
  ├─ Environmental audio presets — cave, forest, rain, wind
  └─ Audio DSP — all ambient, SFX, and music

Terrain Rendering

Veloren's terrain is chunked — the world is divided into 32×32×32 or 64×64×64 voxel chunks, each loaded as the player explores. The height-field DDA approach works on a 2D heightmap derived from each chunk's visible surface — the maximum Y value per (X,Z) position.

For a view distance of 16 chunks (512 voxels), the height-field DDA casts rays across the horizontal extent of the view. At Standard resolution (480 columns) all rays cast simultaneously. The distant landscape visible from a hilltop renders in hardware with no CPU loop involvement.

Close-range detail — the voxel blocks of buildings, caves, dungeon interiors — switches to 3D DDA for accurate per-face rendering. The transition distance between height-field and 3D DDA is configurable and seamless from the player's perspective.

Atmosphere

Weather system — rain using bloom line streaks, snow with bloom particles and sinusoidal drift, fog as a low-intensity particle volume at ground level. The environmental DSP presets engage automatically with weather conditions — the rain preset on outdoor rain, the cavern preset inside caves, the forest preset under tree canopy.

Day/night cycle — the Copper drives a full atmospheric sky cycle across the HAM24 sky layer. Sunrise, daylight, golden hour, sunset, dusk, night are all Copper-driven colour temperature shifts over the HAM24 background.

Magic effects — Veloren's spell system produces bloom particle effects. Fireball spells use the rocket explosion particle system. Ice spells use blue-white particles with slow fade. Healing spells produce a soft upward bloom particle cloud around the target. Each spell type has a small authored particle behaviour (~200 bytes) that the blitter executes.

OpenXcom (X-COM: UFO Defense / Terror from the Deep)

Engine: OpenXcom Licence: GPL v3 Assets: X-COM data files required (GOG/Steam) Free alternative: OpenXcom data packs provide partial replacement content; OXCE (extended engine) has additional free content

The Hardware Match

X-COM has two distinct rendering modes: the strategic globe/base view (2D, relatively simple) and the tactical isometric combat mode (isometric tile grid with soldiers, aliens, terrain, and line-of-sight fog of war).

The tactical mode is the hardware showcase. It is an isometric renderer with per-tile visibility (fog of war), line-of-sight calculation, and a large number of animated unit sprites. The FireStorm isometric system handles the tile rendering and sprite management; the SG2000 TPU handles the line-of-sight calculation.

Architecture

C906 big core (1GHz, bare metal)
  ├─ Strategic layer — base management, research, production, globe
  ├─ Tactical AI — alien and civilian behaviour
  ├─ LOS calculation dispatch → TPU
  └─ QSPI → FireStorm

SG2000 TPU (0.5 TOPS INT8)
  ├─ Line-of-sight visibility calculation
  │   per-tile LOS from each unit's position
  │   replaces the CPU LOS loop with TPU inference
  └─ Results → big core → FireStorm layer enable/disable

FireStorm
  ├─ Isometric scanline mapper + diamond span unit
  ├─ Hardware sprite layer — all units, items, explosions
  ├─ Depth buffer — correct occlusion without painter's algorithm
  ├─ Fog of war layer — tiles hidden/revealed via layer enable per tile
  ├─ Bloom particle system — weapon effects, explosions
  └─ Audio DSP — all SFX and music

The TPU Line-of-Sight Enhancement

X-COM's original LOS calculation iterates ray casts from each unit's tile position to every other tile on the map, checking for blocking terrain. On a large map with many units this is expensive — the original game ran noticeably slowly during LOS recalculation on complex maps.

The SG2000's TPU runs a trained model that predicts LOS visibility for stable configurations (terrain unchanged, units stationary) and only triggers the full CPU ray cast for changed situations. The combined TPU precompute + selective full calculation reduces LOS time by 60–80% on stable tactical situations — alien turns in cover, soldiers maintaining position. This is the same pattern as the Caesar III citizen pathfinding enhancement.

Visual Effects

Weapon discharges — X-COM's laser rifles, plasma weapons, and conventional arms all use period sprite animations. Enhanced mode replaces these with bloom effects appropriate to the weapon type:

• Conventional weapons: muzzle flash particle burst, bullet streak bloom line to the target, blood or impact particles at hit
• Laser weapons: a single-frame high-intensity cyan bloom line from firer to target, no particle — the instant quality of lasers rendered as pure light
• Plasma weapons: a blob of green bloom particles travelling frame-by-frame to the target, leaving a faint trail
• Heavy plasma / blaster bomb: explosion particle system as per Doom/Quake

Alien psionic attacks — the purple haze of a mind control attempt uses a Copper-driven whole-screen purple tint that fades in over 3 frames, holds briefly, then fades out. One Copper register write per scanline during the effect duration.

UFO crash sites — the burning wreckage of a downed UFO uses the fire column and smoke particle effects. Multiple fire columns visible simultaneously, smoke persisting above them, the battlefield having a genuinely chaotic atmosphere.

Cave Story (NXEngine-evo)

Engine: NXEngine-evo Licence: GPL v3 — engine; game data CC0 / public domain Assets: Complete free game data included — no ROM or purchase required Source: github.com/nxengine/nxengine-evo

The Legal Situation

Cave Story is the cleanest entry in this collection from a licensing standpoint. The NXEngine-evo engine is GPL v3. The original game data — levels, graphics, music, sound — was developed by Daisuke Amaya (Studio Pixel) as freeware and is identified as free from known copyright restrictions, essentially public domain. The complete game ships with no ROM requirement and no purchase needed. It is the only classic platformer in this document where both the engine and the assets are fully free.

The Game

Cave Story (2004) is a side-scrolling action platformer with exploration elements — the game that effectively defined what an indie game could be. A character awakens in an underground cave with no memory, discovers a society of rabbit-like Mimigas, and works to uncover the truth of the island. The gameplay combines precise action platforming with non-linear exploration, multiple endings, and a narrative that genuinely surprised people in 2004.

It is also a technically interesting game. The original was built by one person in assembly over five years. Its physics, particularly the variable-jump and momentum system, have a distinctive feel that many subsequent platformers have tried to replicate. NXEngine-evo faithfully reproduces this behaviour at any target frame rate.

The Hardware Match

Cave Story is a 2D sprite game with many simultaneous entities — bullets, enemies, particles, environmental effects. The FireStorm hardware sprite layer handles the entity count without pressure. The bloom particle system enhances every weapon and explosion.

The most significant hardware match is audio. The original Cave Story music — composed by Daisuke Amaya on the Organya tracker format — has been covered, arranged, and re-released in multiple forms. The FireStorm audio DSP can do something none of these cover versions have done: play the original Organya-format note data through the full synthesis pipeline, giving the compositions the voice count and effects depth the original tracker could not produce while preserving every melody and harmony note-for-note.

Architecture

C906 big core (1GHz, bare metal C++)
  ├─ Game logic — entity AI, physics, level management
  ├─ Organya music player → FireStorm audio DSP
  └─ QSPI → FireStorm

FireStorm
  ├─ Hardware sprite layer — all entities, bullets, particles
  ├─ Bloom particle system — weapon impacts, explosions
  │   Missile explosions use the full rocket particle system
  │   Polar Star sparks — directional debris particles
  │   Blade weapon — wide bloom arc effect per swing
  ├─ HAM24 background layers — cave environments with full colour depth
  │   Mimiga Village warm lighting, Waterway blue-green depth
  ├─ Parallax scrolling layers — background/midground/foreground
  │   Copper-driven per-scanline H_scroll for wave effects
  ├─ Copper lighting — per-room ambient tone and brightness
  └─ Audio DSP — Organya note data → full synthesis arrangement

Display Enhancements

Native resolution — Cave Story's original resolution is 320×240. The Ant64 uses the 320×240 → 4:3 PAR mode: 320 native width × 240 native height scales to 3840×2160 at ×12×9, producing correct undistorted geometry at 4K.

CRT simulation — the generic SCART TV profile is the most authentic for Cave Story's aesthetic — warm, slightly soft, visible scanlines. The Aperture Grille profile produces a sharper alternative that suits the underground cave environments well.

HAM24 backgrounds — the original 8-bit palette backgrounds are replaced with HAM24 renders at full colour depth. The underwater Waterway area becomes a genuinely deep cyan-green gradient. The Hell area glows with physically plausible fire light against deep black.

Per-room lighting tones — each room in Cave Story has a characteristic colour palette. The Copper drives a subtle per-scanline colour temperature tint corresponding to the room type: warm amber in the Mimiga Village, cool blue in the Waterway, deep red in Labyrinth. The tint is applied at approximately 20% intensity — present but not overwhelming.

Weapon Effects

Cave Story's weapons are the heart of the game experience. Each has a distinctive behaviour that the Ant64 bloom particle system can express physically:

Polar Star — the standard blaster. Each shot leaves a small debris spark trail in the direction of travel. Impacts on walls produce a brief 3-4 particle concrete chip burst. The weapon's characteristic precise feel is reinforced by the focused particle geometry.

Fireball — the bouncing fire projectile. Each Fireball leaves a trail of 2-3 warm orange bloom particles per frame as it travels, arcing and bouncing. On impact, a small fire splash burst — 6-8 particles radiating at low angles, one frame, then dispersing.

Missile / Super Missile — the largest explosive weapon. On detonation: the full rocket explosion system — core flash, debris cloud, smoke column. A Missile explosion in a tight corridor fills the space with smoke that lingers for 3-4 seconds. The Copper writes a full-frame brightness flash on the detonation frame.

Blade — the melee weapon. Each slash renders as a blit.line_bloom arc — a curved glowing line tracing the weapon hitbox's path, high intensity, very fast fade (2-3 frames). The Blade Level 3 (the wide arc that fires projectiles) spawns 3 simultaneous bloom arcs plus bloom particle projectiles at the arc endpoints.

Bubbler — the bubble weapon. Each bubble is a bloom particle with large radius and very low falloff — a soft glow sphere. The Level 3 orbit of bubbles around the player renders as a persistent ring of low-intensity bloom particles at the player's position, rotating.

Audio — The Organya Enhancement

The original Cave Story music uses the Organya format: a simple tracker with wave tables, drum samples, and a limited synthesis model. It produces a distinctive tinny-yet-expressive sound that is part of the game's identity.

The Ant64 version plays the Organya note data through a layered synthesis approach:

• Organya authentic: the notes are played through VA voices configured to approximate the Organya waveforms — square, sawtooth, and the characteristic "bell" waveform. Period-accurate in character.
• Enhanced: the Organya voices remain as the melodic layer; a second synthesis pass adds a reverb tail (short FDN, cave-appropriate) and a subtle pad layer on sustained notes, giving the compositions more space without changing any notes.
• Full synthesis: each Organya channel is remapped to an appropriate VA or FM patch — leads to expressive VA voices, bass to the full ladder filter, percussion to physical modelling. The Cave Story soundtrack as a full modern synthesis arrangement. The melodies are unchanged; the timbre becomes what the compositions were always reaching for.

The option is selectable from the in-game settings menu. Authentic is the default.

Zelda 3 — A Link to the Past

Engine: snesrev/zelda3 C reimplementation Licence: MIT — engine code Assets: Nintendo commercial property — requires user-supplied ROM (zelda3.sfc) Source: github.com/snesrev/zelda3 Legal note: Same model as Doom — open engine, user provides their own data. Nintendo's IP enforcement history means commercial deployment should be assessed with legal advice.

The Game

The Legend of Zelda: A Link to the Past (1991) is the defining top-down action-adventure game. Hyrule's overworld and seventeen dungeons, two interconnected worlds (light and dark), a weapon and item progression system that remains the template for the genre. It is one of the most studied and most loved games ever made.

The snesrev reimplementation is a complete C rewrite that passes frame-by-frame verification against the original SNES behaviour. It is fully playable from start to end and includes quality-of-life additions: widescreen support, MSU-1 audio track support, additional item slot, inventory reordering.

The Hardware Match

A Link to the Past uses a top-down perspective with a hybrid tile/sprite rendering system. The Ant64's approach:

• Hardware sprite layer — Link, enemies, items, projectiles. The sprite count in a busy room (multiple enemies, Link's sword beam, thrown pots, enemy projectiles) is handled at zero additional render cost.
• Tilemap system — the overworld and dungeons are tile maps. The FireStorm tilemap hardware with per-tile palette IDs handles them directly, including the SNES's layered priority system for the under/over-ground effect.
• HAM24 backgrounds — the overworld gains full photographic colour depth. The Death Mountain peaks transition through genuine atmospheric gradients. The Sacred Grove's autumn palette has the full tonal range the SNES 15-bit colour could only approximate.
• Copper lighting — each area has a characteristic lighting tone. The Dark World's oppressive red-purple tint, the dungeons' torch-lit warmth, the Ice Palace's cold blue — all driven by Copper per-scanline palette modulation at no CPU cost.

Display Enhancements

The original game's native resolution is 256×224 (SNES standard). The Ant64 uses the 4:3 PAR mode at 256×224 native, scaling to 4K while preserving the correct pixel aspect ratio and SNES geometry.

The widescreen support in the snesrev reimplementation allows an extended horizontal viewport. On the Ant64 this fills to 480×270 Standard resolution — the additional tiles on each side are rendered from the existing tile map data. The camera sees further; the game's tile data is already there.

Magic and Spell Effects

The original game uses sprite animations for all spell and item effects. The Ant64 version adds bloom particle enhancements:

Sword beam — a bloom line travels from Link to the wall, full width of the active range. blit.line_bloom with the Asteroids preset intensity. On impact, a small spark burst at the wall contact point.

Silver Arrows / Magic Arrow — the Arrow beam effect adds a persistent bloom trail behind the projectile, tapering from bright to dim over 8 frames. The Silver Arrow's impact on Ganon adds the full explosion particle system.

Fire Rod / Ice Rod — Fire Rod projectile leaves a fire column particle effect at the landing point, persisting for 2 seconds. Ice Rod produces an expanding ring of blue-white bloom particles from the impact point.

Lightning — the Cane of Byrna and Cane of Somaria produce blit.line_bloom lightning arcs, jagged and brief. The Byrna shield circle is rendered as a rotating ring of bloom particles around Link.

Zelda's Rescue — the opening sequence where Zelda is rescued produces the Copper full-screen brightness flash described in the Doom section. The game's dramatic moments get physically real lighting events.

Audio

A Link to the Past's soundtrack by Koji Kondo is one of the most recognised in games. The SNES SPC700 sound chip produced its characteristic warm synthesis.

The Ant64 plays the game's event-driven audio through the FireStorm DSP with three options:

• SPC authentic — VA engine configured to approximate the SPC700's synthesis characteristics. The ADSR curves, the echo delay register (a characteristic SNES reverb effect), the instrument samples. The sound of 1991.
• Enhanced — SPC timbres preserved; the echo delay replaced with the FDN reverb at a short room setting; instrument sustain enriched with BBD chorus on appropriate voices (the string instruments particularly benefit).
• Full synthesis — the event data remapped to full VA/FM patches. The Light World overworld theme becomes a 20-voice orchestral arrangement. The Sanctuary theme gains the full hall reverb. The melodies are Kondo's; the machine behind them is new.

Super Metroid

Engine: snesrev/sm C reimplementation Licence: MIT — engine code (early stage, maturing) Assets: Nintendo commercial property — requires user-supplied ROM (sm.smc) Source: github.com/snesrev/sm Legal note: Same model as Doom and Zelda 3 above. Legal advice recommended for commercial deployment.

The Game

Super Metroid (1994) is the definitive expression of what became the Metroidvania genre. Samus Aran's exploration of planet Zebes — a non-linear world of interconnected areas where new abilities unlock new regions, where the map slowly fills in, where the atmosphere is maintained by music and lighting rather than dialogue. It defined the template for a genre that is still producing celebrated games.

The snesrev reimplementation is an early-stage but actively developing C rewrite, same team as Zelda 3 and SMW.

The Hardware Match

Super Metroid is an atmospheric game built on layered parallax scrolling, per-room lighting, and precise sprite physics. The Ant64's hardware is a strong match:

• Multi-layer parallax — the FireStorm layer system's independent per-layer H_scroll and V_scroll, driven by Copper per-scanline updates, produces Metroid's characteristic deep parallax backgrounds. The lava rooms' slowly scrolling deep background. Maridia's underwater light shafts.
• Hardware sprite layer — Samus, enemies, beams, dropped items. The sprite count in combat is well within the hardware sprite budget.
• Copper atmospheric lighting — each Zebes area has a characteristic lighting palette. Brinstar's green-tinged organic lighting, Norfair's deep red heat, Maridia's underwater blue, Tourian's cold mechanical white. All driven by Copper per-scanline colour temperature shifts.
• HAM24 backgrounds — the environmental backgrounds gain full colour depth. Norfair's lava glows with physically plausible light. The Wrecked Ship's pale grey geometry fades into darkness convincingly.

Atmosphere Enhancements

Super Metroid's atmosphere is its most celebrated quality. The Ant64 version enhances every system that contributes to it:

Lava — active lava sectors use the Copper bloom intensity register on lava-tagged scanlines. The lava surface emits upward-rising red-orange bloom particles — sparse, slow, persistent. The ambient light from lava tints Samus's sprite slightly warm when near it (palette tint via Copper on the sprite layer scanlines).

Water/liquid areas — the underwater environmental DSP preset engages automatically in Maridia and submerged areas: aggressive high-frequency rolloff, pressure wobble, slow chorus. The audio transition on entering and exiting water is physically convincing.

Darkness — certain rooms in Super Metroid are deliberately near-dark. The Ant64 uses the bloom system for ambient light sources: Samus's suit emits a faint bloom halo in total darkness. Glow-in-the-dark enemies cast a colour-appropriate bloom onto nearby surfaces.

The X-Ray Scope — in the original, the X-Ray Scope pulses the screen to reveal hidden passages. The Ant64 version renders the X-Ray effect as a Copper-driven scanline interleave — the same mechanism as the old skool transition glitch effect, but here used deliberately. The screen fragments into a revealing pulse pattern that is more physically evocative than the original palette swap.

Weapon and Ability Effects

Charge Beam — the charging glow is a bloom particle at Samus's arm cannon, growing in intensity over the charge time from dim to very bright. The Copper writes an ambient brightness increase proportional to charge level — a fully charged beam illuminates the immediate area.

Wave Beam — the sinusoidal projectile path uses blit.line_bloom with a Lissajous path rather than a straight line. The wave shape is accurate to the weapon's behaviour; the bloom glow makes it visually striking in a way the original sprite could not achieve.

Screw Attack — Samus rotating through enemies. Each rotation frame emits a ring of bloom particles radiating outward from Samus's position. The particle ring rotates with Samus and fades over 4 frames. In a crowded enemy group the Screw Attack produces a bloom corona.

Bombs/Power Bombs — Bomb: small central flash particle burst, 3-frame radius. Power Bomb: the largest single explosion in the game — full rocket explosion particle system, Copper full-screen white flash for 3 frames fading over 10, smoke column persisting for 5 seconds. A Power Bomb in a confined space fills the room with smoke that clears over several seconds.

Grappling Beam — the grappling hook renders as a blit.line_bloom from Samus to the grapple point, maintained while attached. The grapple line glows.

Audio

Super Metroid's soundtrack by Kenji Yamamoto and Minako Hamano is one of the most atmospheric game soundtracks ever recorded. The SNES SPC700 produced it; the FireStorm can do considerably more.

The same three-option audio model as Zelda 3 applies. The full synthesis arrangement option is particularly compelling for Super Metroid — the ambient, atmospheric compositions benefit most from the FDN reverb, the granular engine on sustained pads, and the full voice count. The Lower Norfair theme's industrial intensity becomes physically present. The Ceres Station opening theme's quiet dread becomes genuinely unsettling.

Super Mario World

Engine: snesrev/smw C reimplementation Licence: MIT — engine code Assets: Nintendo commercial property — requires user-supplied ROM (smw.sfc) Source: github.com/snesrev/smw Legal note: Same model as above. Legal advice recommended for commercial deployment.

The Game

Super Mario World (1990) is the SNES launch title, the game that defined what 16-bit platforming could be. 96 exits across a world map, Yoshi, Cape Mario, the interconnected secret world — it is one of the most complete and polished games ever made and one of the most analysed.

The snesrev SMW reimplementation is from the same group as Zelda 3 and Super Metroid, using the same build system and verification approach.

The Hardware Match

Mario World's rendering is tile-based platforming with a high sprite count and extensive use of Mode 7 (the SNES affine transformation mode) for certain special stages. The Ant64's hardware maps directly:

• Tilemap system — all levels are tile maps. The FireStorm tilemap hardware handles them with per-tile palettes and the SNES-authentic priority layering system.
• Hardware sprites — Mario, Yoshi, enemies, coins, powerup items. A crowded level section in World 4 has 20+ simultaneous sprites; the hardware sprite layer handles this at zero cost.
• Mode 7 affine tilemap blit — the Ant64's Mode 7 implementation is the exact hardware equivalent of the SNES Mode 7 that the Star Road and Special World stages use. The rotating/scaling floor planes are native to the blitter.
• HAM24 overworld — the top-down world map gains full colour depth. Chocolate Island's warm ochre, Forest of Illusion's deep greens, Star World's ethereal blues — all with the full tonal range HAM24 provides.

Visual Effects

Cape feather flight — when Mario uses the Cape to fly, trailing feather particles emanate from the cape on each swing — 2-3 small white bloom particles per swing frame, fading over 8 frames. Extended flight produces a long feather wake.

Yoshi's tongue — the tongue extension renders with blit.line_bloom as a brief glowing line from Yoshi's mouth to the target. One frame, then retracted. The glow is brief and not distracting but gives the tongue a physical presence the original sprite lacked.

Fire Mario — the fireball leaves a short bloom trail (2 particles per frame) and produces a satisfying bloom burst on enemy contact. Fire Mario's standard throw gains the same visual weight as a Missile in Cave Story.

Star power — invincibility star effects. The colour-cycling during Star power uses the Copper to produce true palette cycling with 24-bit colour — the full rainbow rather than the SNES's 15-bit approximation. The star trail following Mario's movement is a bloom particle stream.

1-Up mushroom collection — the 1-Up text appears as a rising bloom text particle (using the glyph blit at elevated bloom intensity), brighter and more satisfying than the original sprite text.

Boss explosions — Koopaling defeats use the full explosion particle system. Larry Koopa's final hit produces a genuine particle explosion rather than the sprite flash. The player gets a physically real payoff for completing a boss fight.

Mode 7 Enhancement

The Ant64's Mode 7 blitter implementation is equivalent to but not limited by the SNES hardware. The SNES Mode 7 had no texture filtering — the floor scaling at extreme angles showed pixel crawl. The Ant64 version uses bilinear filtering on the Mode 7 floor texture, eliminating the crawl while preserving the visual character. The horizon fog effect (the SNES's distance fade on Mode 7) is rendered via Copper-driven opacity reduction on the distant floor scanlines rather than a hard clip.

An Original Metroidvania — "The Vault"

No open source Castlevania-equivalent with free assets exists in a form suitable for a commercial product. The right answer is an original work.

Castlevania: Symphony of the Night (1997) established the Metroidvania genre — large interconnected castle, ability-gated exploration, levelling system, enormous bestiary, Gothic aesthetic. The Ant64's hardware is exceptionally well suited to this genre. The existing open source "Castlevania-like" projects either require Konami IP or are incomplete fan games.

The proposal here is an original Metroidvania — working title "The Vault" — designed from the ground up for the Ant64's specific capabilities and released as CC0 alongside the other original works in the demos document.

Why the Ant64 Hardware Suits This Genre Specifically

Sprites at scale — a Metroidvania room at peak combat density has the player, 10-15 enemies, 30-50 projectiles, 20+ particles from previous impacts all simultaneously active. The hardware sprite layer handles hundreds per scanline. The blitter handles the bloom particle accumulation. No sprite flickering. No performance-based visual compromise.

Multi-layer parallax depth — Metroidvanias use deep parallax backgrounds to create the illusion of large architectural spaces. The Copper-driven per-scanline H_scroll and V_scroll on independent layers produces the parallax depth these games require without CPU involvement.

Per-room atmospheric lighting — each room in a Metroidvania should have its own character: the torchlit stone of a castle corridor, the bioluminescent blue of a deep cave, the sickly green of a poison swamp. Copper-driven per-scanline colour tints and bloom intensity variation make this essentially free to implement and to vary smoothly between rooms.

Environmental audio DSP — the cave preset, the cavern preset, the underwater preset, the small room preset engage automatically per area type. The audio character of each zone changes without any additional engineering per-zone.

The bloom particle system as the visual vocabulary — Metroidvanias are defined by their weapon effects, ability unlocks, and environmental hazards. Bloom particles are the visual language of all of these. A whip that creates a brief blit.line_bloom arc. A fireball that leaves a trail. An invincibility shield that renders as a rotating bloom particle ring.

The Vault — Design Outline

An underground vault beneath an abandoned research facility. The player character discovers the vault has been sealed and the reason it was sealed is still alive inside. Exploration-first gameplay in the Metroidvania tradition with ability gating, backtracking, and a gradually revealed world map.

Aesthetic — retro-modern. The tile art is deliberately pixel-art at Standard resolution (480×270) — the FireStorm CRT simulation pipeline active, giving it the authentic feel of a high-quality 16-bit game. The HAM24 backgrounds behind the tile layers are photographic-quality atmospheric art — Gothic stonework, deep cave formations, flooded lower levels. The contrast between crisp pixel-art foreground and HAM24 background depth creates a specific aesthetic that no period hardware could produce.

The boss designs — each boss uses the full visual effects toolkit. The fire golem boss fills the room with fire column particles and bloom flashes. The ice construct boss produces expanding bloom ice crystal rings. The final guardian uses a combination of effects not possible on any period hardware simultaneously.

Audio — original composition, using the VA engine for Gothic orchestral arrangements. The castle areas: FDN hall reverb, string pads, harpsichord FM voices. The deep cave areas: granular ambient underneath sparse melodic voices, cavern environmental DSP. The final confrontation: full voice count, all effects.

This work would be released as CC0 alongside "Silhouette", "Copper", "Weight", and "Heritage". The vector tween system, bloom particle infrastructure, and EE bytecode modules developed for the other original works are all reusable here. "The Vault" is the game that demonstrates those modules in a gameplay context.

Oolite / Pioneer — Elite & Frontier-Style Space Games

Two open source games covering the two branches of the Elite lineage.

The Lineage

Elite (1984, David Braben and Ian Bell, BBC Micro) was the game that proved a home computer could contain a universe. Eight procedurally generated galaxies, 256 star systems each, wireframe 3D polygon ships, trading, piracy, bounty hunting, and a combat rating from Harmless to Elite. It fit in 22 kilobytes. It invented the open-world space game and directly inspired everything from Wing Commander to No Man's Sky to Elite: Dangerous.

The original Elite was wireframe vector graphics — lines drawn directly to screen with no textures, no fills, no lighting beyond the outline. This was a constraint of 1984 hardware. It was also, accidentally, an aesthetic — clean, precise, almost architectural. The ship designs read clearly across the void. A Cobra Mk III in wireframe is immediately recognisable in silhouette.

The Ant64's blit.line_bloom system — the same mechanism used in the boot intro's Boing Ball vector variant, in Armagetron's light cycle trails, in the vector CRT arcade demos — is the natural modern equivalent of Elite's wireframe rendering. Laser beams, ship outlines, navigation markers, the heads-up display: all are bloom lines. The aesthetic of Elite can be reproduced on the Ant64 with physically accurate light emission rather than a flat framebuffer draw, and it can be optionally layered with texture-mapped polygon rendering for those who want it. The wireframe and the modern are the same engine, the same hardware, the same choice the player makes.

Star Raiders (Atari, 1979) preceded Elite by five years with a first-person cockpit space combat game — an enemy scanner, energy management, sector navigation. It was the ancestor that proved the concept before Elite systematised it. The Ant64's lineage includes it, and an optional authentic mode for the space game collection can render ships in the Star Raiders style: simple filled polygon shapes against the star field, the scanner as a vector overlay.

Oolite

Engine: Oolite Licence: GPL v2+ — source code Assets: CC BY-NC-SA-3.0 — bundled assets (non-commercial use only) Commercial path: Port the GPL engine; create or source replacement assets under a commercial-compatible licence. The Oolite asset community is large and active. Source: github.com/OoliteProject/oolite

The Game

Oolite is a space simulation game and clone of Elite, in the spirit of the original, open-ended, single-player space trading and combat simulator. The player pilots a spacecraft through eight procedurally generated galaxies, trading between star systems, fighting pirates, taking on missions. The flight model is deliberately non-Newtonian — ships behave as Elite ships did, not as real spacecraft do. Speed proportional to thrust, no inertia, arcade dogfighting. There are over 700 expansion packs available through the in-game manager, ranging from new ships to new missions to graphical overhauls.

The Hardware Match

The original Elite was wireframe. Every ship, asteroid, and space station was a set of vertices connected by lines, drawn as vectors on screen. This is blit.line_bloom. Not as a simulation of Elite — as the literal technique Elite used, executed with physically accurate bloom rather than a simple framebuffer line draw.

The Ant64 Oolite implementation offers three rendering modes selectable per session:

Wireframe mode — ships, stations, and asteroids rendered as blit.line_bloom outlines. The Star Wars blitter preset on all lines — bright, saturated, correct bloom falloff. Enemy ships are a wireframe of light in the void. Laser beams are hot white bloom lines. Missiles leave a spark trail. This is what Elite looked like in 1984, rendered with hardware that could not have existed in 1984.

Filled polygon mode — ships rendered as flat-filled textured triangles via the blitter's textured triangle system, bilinear sampling from Graphics SRAM. Closer to the Frontier: Elite 2 visual aesthetic. Correct perspective. Still no OpenGL dependency — pure FireStorm blitter.

Hybrid mode — ships at distance render as wireframe; close-range ships acquire texture detail as they approach. The transition happens per-ship based on screen area. A distant Cobra is a glowing outline; the same Cobra at docking range has hull plates, markings, running lights.

The space environment audio DSP preset activates immediately — the silent vacuum with sub-bass engine drone, crystalline distant instrument sounds, the dry close audio of the cockpit. The ship engine sound is a VA oscillator sweep that responds to throttle position. Laser fire is a brief high-intensity bloom line with a matching SFX archetype pulse. Hull impacts shake the audio with a deep broadband noise burst.

Laser Combat Effects

The laser bolts that are the primary weapon in the Elite tradition are blit.line_bloom primitives — exactly as they appear in the vector CRT demo scene. Each bolt is a single line from the firing point to the target or edge of range, high intensity, moderate falloff, additive blend. Multiple lasers firing simultaneously from different positions accumulate brightness on the target — a ship absorbing multiple simultaneous hits glows hot at the impact zone. The convergence of lasers at a single point produces a brightness spike exactly as the physics of additive light emission demands.

Ship explosions use the full particle system: core flash, debris cloud, persistent spinning fragments that drift as individual bloom particles, a slow smoke-equivalent cloud of dim large-radius particles that persists for 10–15 seconds. A destroyed Cobra leaves a debris field visible from hundreds of metres.

The witchspace (hyperspace) jump uses a Copper full-screen tunnel effect — a set of concentrically shrinking rings drawn as bloom line circles, contracting toward the vanishing point over approximately two seconds, with a deep sub-bass audio sweep using the VA engine's oscillator. The witchspace tunnel that Elite displayed as two-colour ASCII art on the BBC Micro becomes a physically light-emitting vortex on the Ant64.

Procedural Planets and HAM24

Oolite's planets are texture-mapped spheres procedurally generated from a seed. The Ant64 version uses the same seed but renders the planet texture as a HAM24 layer — photographic colour depth on the planet surface. Gas giants with full atmospheric gradient. Terrestrial worlds with continent shapes in genuine earth-toned HAM24 colour. The space station's docking bay interior renders with HAM24 texture mapped across the blitter's textured triangle primitives.

Asset Replacement Path

The bundled Oolite assets carry the CC BY-NC-SA-3.0 licence which prevents commercial use. The replacement path:

• Ship model geometry is compact data — wireframe rendering requires only vertex positions and edge indices, a few hundred bytes per ship. Original wireframe ship designs take hours to author, not days.
• In wireframe mode, textures are irrelevant — the visual is entirely bloom lines.
• In polygon mode, simple flat-colour or procedurally generated textures per ship hull bypass the asset question entirely.
• The Oolite community has produced hundreds of OXP ships under various licences. Commercially compatible OXP assets can be selected selectively.

The practical minimum viable asset set for wireframe mode is close to zero additional storage — just vertex and edge tables for 10–20 ship types, a few KB total.

Pioneer

Engine: Pioneer Licence: GPL v3 — engine and all assets Assets: All included, GPL v3 Source: github.com/pioneerspacesim/pioneer

The Game

Pioneer is a free and open source space trading and combat simulator inspired by Frontier: Elite 2, set at the start of the 33rd century in a procedurally generated galaxy of millions of star systems. The player can explore and trade between millions of star systems, land on planets, slingshot past gas giants, try piracy, run courier missions, or fight for various factions. Where Oolite follows the original Elite's arcade flight model, Pioneer uses a realistic flight and orbital model based on Newtonian physics and includes a rudimentary atmospheric model with drag and heat build-up.

Pioneer is Frontier: Elite 2's open source spiritual successor in the same way that Doom's GPL release enabled countless source ports. It is GPL v3 throughout — engine and assets — which is the cleanest licensing situation of any game in this collection after Cave Story.

The Hardware Match

Pioneer's Newtonian flight model means ships have actual mass, inertia, and momentum. A combat encounter in Pioneer involves orbital mechanics as much as reflexes — chase curves, intercept trajectories, burn and coast. The SG2000's 1GHz C906 handles the Newtonian physics simulation for multiple ships simultaneously with computational headroom.

Planetary surfaces — Pioneer has full planetary landing. Approaching a planet from orbit through atmosphere, landing on the surface, taking off again. The terrain is procedurally generated per planet from a seed. The Ant64's height-field voxel hardware applies to Pioneer's planetary terrain rendering exactly as it does to Veloren — the hardware DDA units ray-cast the terrain height map for the approach and surface phases. At orbital altitude, the planet is a HAM24-textured sphere. At low altitude, the terrain is height-field rendered with hardware DDA. On the surface, close-range detail is 3D DDA. The same three-tier approach Veloren uses, in a space context.

Ship polygon rendering — Pioneer's ships are 3D polygon meshes. The blitter's textured triangle system handles them — BSP ordering for the mesh faces, perspective-correct UV, bilinear sampling. The same pipeline as Quake's polygon rendering, applied to spacecraft.

The star field — Pioneer's procedural star field is a natural match for the Ant64's multi-layer parallax system. Nearby stars are large bloom particles; mid-range stars are smaller bloom points; distant stars are the standard parallax starfield. The bloom falloff on nearby stars gives them the correct optical character — a star at 3 light-years is a point source with an Airy disc bloom, not a flat pixel.

Atmospheric Entry

Pioneer's atmospheric entry is one of its most dramatic sequences. The Ant64 enhances it:

• Heat glow — on atmospheric entry, a Copper-driven orange-red bloom tint applies to the ship's position on screen, increasing in intensity with entry velocity. The ship silhouette gains a heat plasma halo.
• Plasma particles — ablation particles stream backward from the ship's leading edge — high-intensity orange-white bloom particles at 20–30 per frame, fading rapidly.
• Atmospheric audio — the atmospheric environmental DSP applies as density increases: rushing air noise synthesised from broadband noise through a band-pass filter, Doppler shift on any radio communications, the structural creak SFX archetype as the hull flexes.
• Turbulence — at high entry velocity, the Copper writes brief random scanline displacement on the ship's screen region — simulating atmospheric optical distortion. The same Copper mechanism as the April Fools glitch effect, used purposefully.

The Docking Sequence

Elite's manually docked approach through the rotating Coriolis space station is one of gaming's most iconic sequences. Pioneer inherits it. The Ant64 renders the station's rotating wireframe as bloom lines that transition to texture-mapped polygons as the player approaches — the hybrid rendering mode at its most dramatically useful. The interior of the docking bay renders with HAM24 texture depth and Copper-driven directional lighting from the hangar lights overhead.

An Original Ant64 Space Game — "Veil"

Proposed as an original work in the CC0 collection.

There is a gap in the open source space game landscape that exactly matches what the Ant64 can uniquely do: a space game that starts in 1984 wireframe and optionally evolves to contemporary rendering, treating the aesthetic progression as a feature rather than a legacy compromise.

"Veil" is proposed as an original CC0 space trading and combat game in the Elite tradition, designed from the ground up for the Ant64's capabilities and the playing philosophy of the original: open world, no handholding, reputation-earned progression, the galaxy as a space to inhabit rather than a story to complete.

The Design Concept

The player starts in wireframe. Not as a retro affectation — as the game's stated aesthetic. The universe begins as vectors and lines, clean and abstract. As the player accumulates trade credits, the ship can be upgraded. One upgrade path improves the ship's systems — faster, better weapons, cargo capacity. The other upgrade path improves the ship's rendering system — from wireframe to filled polygons, from filled polygons to textured, from textured to fully lit with dynamic shadows.

This is the progression as a mechanical layer. The universe is the same universe. The stars are the same stars. But a player in wireframe and a player in fully-lit mode are having different visual experiences of the same game world. Two players comparing their view of the same space station would see completely different-looking things depending on their progression.

The final rendering tier — available only to players who have achieved Elite combat rating and amassed significant trade wealth — uses the FireStorm SVO traversal engine for real-time ray-traced ship hull rendering. At this tier, the Cobra Mk III that began as a wireframe outline is now ray-traced, reflection-mapped, casting hard shadows from the nearest star. The journey from 1984 to 2026 is encoded in the game's progression system.

Technical Implementation

Wireframe tier — blit.line_bloom for all geometry. Ship vertex/edge tables as compact flash assets (~500 bytes per ship). 20 ship types plus stations and asteroids: approximately 12KB total. The entire wireframe universe fits in the Ant64's flash budget rounding error.

Polygon tier — blitter textured triangles, flat-colour or procedurally generated textures. Graphics SRAM holds the active zone's polygon data.

Textured tier — HAM24 textures on planet surfaces and large structures. Ship hulls use the Graphics SRAM texture atlas with bilinear sampling.

Ray-traced tier — SVO traversal engine with BVH for the player's ship and immediate combatants. Dynamic shadows from the star. This tier is available only in combat — the performance budget is spent on the combat geometry, not background ships.

Navigation — the galaxy map renders as a point cloud of bloom particles, one per star system, colour-coded by economy type and government. The player's current position is a bright white bloom point; visited systems are dimmer; unvisited systems are the faintest. The map is entirely blit.particle calls — zero stored data, just the procedural star system positions computed from the same seed as the game world.

Audio — the space environmental DSP throughout. Engine hum as VA oscillator tracked to engine output level. Laser fire as bloom line + SFX archetype burst. Missile lock tone as a rising FM sweep. The witchspace tunnel as a deep VA sub-bass sweep into silence, then the new system materialising from silence into the ambient drone of local space. The docking computer's guidance tone as a four-note FM sequence that resolves to a landing confirmation chord.

The Elite rating announcement — when the player achieves Elite, a single bloom line draws across the screen — just one line, corner to corner, full intensity, Asteroids preset — and holds for two seconds. Then it fades. No fanfare, no particle burst. Just the line. Anyone who has been waiting for it will understand.

Star Raiders Reference Mode

Both Oolite and Pioneer, and the original Veil, support an optional Star Raiders Reference Mode — a visual mode that renders ships in the 1979 Atari style: flat filled polygon silhouettes, no textures, limited colour palette, the characteristic angular ship designs of that era. The sector map renders as a grid of text characters via the text rendering system. The scanner renders as a simple vector circle with dot markers.

This is not emulation — it is the Ant64 hardware voluntarily constraining itself to the aesthetic of 45 years ago, using the full rendering pipeline to produce something that looks like it came from a machine with 1/10,000th of its capability. The same creative principle as the old skool transition in the boot intro, applied to a playable game mode.

The Star Raiders reference mode is the demo scene homage philosophy applied to gameplay: you know what it is, you know why it looks the way it does, and the machine knows that you know.

Storage

Oolite engine (C++ port, GPL):                    ~25 MB
Oolite replacement wireframe assets:               ~1 MB
  (vertex/edge tables for all ship types)
Pioneer engine (C++, GPL):                        ~40 MB
Pioneer game data (GPL assets):                   ~200 MB
Veil (original game, CC0):                        ~30 MB
  (procedural universe, compact ship tables,
   audio patches, EE modules)
──────────────────────────────────────────────────────
TOTAL:                                            ~296 MB

Racing Games — OutRun / Ridge Racer Style

Three perspectives on the racing genre: the original pseudo-3D sprite scaler, full 3D polygon racing, and a proposed original Ant64 work in the spirit of both.

The Two Technical Traditions

OutRun (Sega, 1986) and Ridge Racer (Namco, 1993) represent two fundamentally different rendering approaches to the racing game. Both are worth implementing on the Ant64, and the hardware maps to each in a different but equally direct way.

Pseudo-3D sprite scaling (OutRun tradition) — the road is rendered as a series of horizontal strips with perspective foreshortening applied per-strip. Roadside objects are sprites scaled according to their distance from the camera. No 3D geometry — just carefully calculated horizontal lines and scaled sprites. Sega's Super Scaler hardware of 1986 did this with dedicated sprite-scaling chips. The Ant64's Copper, writing a new affine transform matrix on every scanline, produces the same perspective effect with contemporary precision and 24-bit colour.

Full 3D polygon racing (Ridge Racer tradition) — the road is texture-mapped polygon geometry. Opponent cars are polygon meshes. Perspective-correct UV mapping on every surface. This is the blitter's textured triangle system with depth buffering — the same pipeline used for Quake, applied to a racing track.

The two traditions produce completely different feels. OutRun is about the sensation of speed in landscape — the road curving into the distance, the scenery rushing past, the horizon rising and falling. Ridge Racer is about the car and the circuit — the road surface texture streaming beneath the tyres, the opponent geometry in your mirrors, the precise geometry of corners.

Both belong in the Ant64 games collection.

Cannonball — Enhanced OutRun Engine

Engine: Cannonball (C++ rewrite of the OutRun arcade engine by Chris White) Licence: Engine source available on GitHub — licence terms require verification before commercial use; the project has been maintained as open source but the specific commercial terms of the engine licence should be confirmed with the author. Assets: Sega OutRun ROMs required — commercial property of Sega. User must supply original ROMs. No free replacement asset set available for OutRun's specific graphics. Source: github.com/djyt/cannonball Note: If engine licence or ROM rights present commercial obstacles, the rendering techniques are implementable in an original game — see "Sunrise Drive" below.

What Cannonball Is

Cannonball is a complete C++ rewrite of the OutRun arcade game's 68000 and Z80 assembly code, by Chris White, with enhancements including higher frame rate, widescreen support, and numerous bug fixes from the original. It requires the original OutRun revision B ROM set for graphics and audio data. The engine code is the rewrote; Sega's assets are not reproduced.

The Hardware Match

OutRun's rendering technique — per-scanline perspective calculation for the road, scaled sprites for roadside objects — is one of the most direct Copper/hardware-sprite showcases in the entire games collection.

Road rendering — Copper per-scanline affine

The OutRun road is a flat plane extending to a horizon. At each scanline, the road has a specific horizontal position (curve offset), width (perspective scale), and colour (stripe pattern). In the original arcade hardware, dedicated Super Scaler chips computed these per-scanline values. On the Ant64, the Copper writes a new affine transform matrix to the Mode 7 tilemap layer on every scanline, with the road geometry computed by the EE each frame and loaded into the Copper command list. The result is a continuously updating perspective road at zero CPU cost during raster.

The road stripe pattern — the alternating white and coloured bands that give OutRun its distinctive rhythm — cycles through the Copper's palette registers per scanline. The exact colours, stripe frequency, and road banking angle are all Copper parameters updated per frame.

Roadside objects — hardware sprites at scale

Roadside trees, signs, buildings, and traffic are sprites at varying screen scales corresponding to their distance. In OutRun these were pre-scaled to five size frames per object — the hardware selected the appropriate frame per distance. On the Ant64 the hardware sprite layer renders each roadside object at its computed screen scale via the sprite attribute table's per-sprite scale parameters. No pre-scaled frames needed — the hardware scales continuously. The trees at the horizon are tiny; the trees at close range are large; the scaling is smooth and exact rather than stepped through five discrete frames.

The sky — HAM24 gradient

OutRun's sky is a simple two-colour horizontal gradient fading from upper blue to lower horizon haze. On the Ant64 this is a HAM24 layer behind the road — the sky gradient has photographic colour depth rather than a palette-limited approximation. Sunsets, coastal haze, mountain atmosphere all render with genuine tonal range.

Traffic — hardware sprites

The sparse traffic on OutRun's roads — other cars to navigate around — are hardware sprites with collision rectangles maintained by the C906. The hardware sprite layer handles the count without performance penalty. Traffic density can be increased beyond the original's limits without any frame impact.

Display Enhancements

CRT simulation — the JAMMA Arcade profile is the authentic choice, reproducing the character of the sit-down OutRun cabinet's monitor: bright, slightly warm, punchy. The SCART TV profile reproduces the home console port aesthetics most European players experienced.

HAM24 sky environments — beyond the original's fixed sky gradient, different road sections can use different HAM24 sky backdrops: coastal sunset, mountain pass, Alpine pass, desert. The Copper transitions between them at the route-select fork points. A coastal sunset with a genuine atmospheric gradient of 24-bit colour depth behind OutRun's sprite-scaled road produces a combination the original 1986 hardware could not have imagined.

Bloom on headlights and brake lights — each car sprite has a headlight/brake-light region tagged in its sprite attributes. A bloom particle is placed at the headlight positions each frame — warm white for headlights, red for brake lights. In the night variants of roads (if added as a track option) the trail of brake-light bloom from slowing traffic ahead is physically convincing.

Road surface reflections — when it has rained (a track atmospheric option), the road surface reflects the sky above. The Mode 7 road layer uses a second HAM24 sample of the sky, horizontally flipped and composited at reduced opacity on the road surface. The reflection updates per frame via the Copper road command list. Puddle splash particles — short-lived bloom particle bursts — fire from the tyres as the car drives through wet sections.

Audio Enhancement

The original OutRun audio — Hiroshi Kawaguchi's legendary FM synthesis soundtrack — played through Sega's custom FM sound hardware. The three iconic tracks ("Magical Sound Shower", "Passing Breeze", "Splash Wave") are some of the most recognisable pieces of game music ever written.

FM authentic mode — the C906 parses the ROM's FM audio data and drives the FireStorm audio DSP with the equivalent operator configurations and algorithms. The specific FM waveforms, envelopes, and operator relationships that Kawaguchi programmed are reproduced on the VA/FM engine. This is how the music was designed to sound — on FM hardware.

Enhanced mode — FM timbres preserved; the FDN reverb added at a short outdoor setting (the music was mixed for a large cabinet speaker in an open arcade floor); the BBD chorus added to the lead synth voices, giving them the warm spatial character the FM synthesis was always reaching for.

Full synthesis mode — each FM channel remapped to VA/FM patches with the full voice count. "Magical Sound Shower"'s bass line on the full ladder filter. The lead synth on a 6-operator FM voice with extended operator routing. The percussion on physical modelling. The composition is Kawaguchi's; the machine behind it is new.

Engine audio — the Ferrari engine sound is a VA oscillator sweep tracking the player's current RPM and gear. The pitch rises through the rev range, drops on gear change, builds again. This is not a sample — it is synthesised in real time from the engine state. The exhaust note changes character with gear — higher gears have more harmonic complexity in the upper register. Tyres squealing on corners use the noise generator with a band-pass filter sweep proportional to lateral acceleration.

Positional audio for traffic — each traffic car's engine sound pans with its screen X position and attenuates with distance. Passing a car produces a genuine Doppler-shifted audio event. The traffic that surrounds you becomes an audio landscape.

SuperTuxKart

Engine: SuperTuxKart Licence: GPL v3 — engine and game code; assets are GPL, CC BY, CC BY-SA, and Public Domain — all commercially compatible Assets: All included, fully free Source: github.com/supertuxkart/stk-code

The Game

SuperTuxKart is a full 3D kart racing game in the Mario Kart tradition, featuring the mascots of open source projects. It has been in active development since 2006, with the most recent 1.5 release in October 2025 setting the stage for the Evolution development phase. It is the most mature and complete racing game in this document from a content standpoint — many tracks, numerous characters, single player, local and network multiplayer, full AI, story mode.

It is Mario Kart style rather than OutRun or Ridge Racer style — karts with items and weapons rather than high-speed sports cars and road obstacles. This is a different feel to the OutRun tradition but a legitimate and well-loved racing game genre in its own right.

The Hardware Match

Full 3D polygon track — kart racing tracks are polygon meshes. The blitter's textured triangle system renders them with perspective-correct UV and bilinear sampling. The depth buffer handles correct occlusion between track geometry, karts, and items without painter's algorithm sorting.

High sprite count — karts, item boxes, banana peels, missiles, star effects, coin trails. In a full 8-kart race with items active the sprite count is high. The hardware sprite layer and blitter handle this simultaneously.

Item effects — SuperTuxKart's power-up items are the visual centrepiece of kart racing. The Ant64 bloom particle system enhances every one:

• Star (invincibility) — the rotating star trail around the kart is a ring of bloom particles orbiting the kart position, gold/white, persistent. The kart itself emits a continuous particle stream while invincible.
• Swatter — the swatter slap that eliminates nearby karts produces a cartoon-style impact particle burst — 10-15 bright particles radiating from the contact point.
• Cake/bowling ball — projectile trails use the bloom particle trail system. Impact explosions use the full rocket explosion particle system.
• Nitro — the blue flame nitro boost emits a backwards bloom particle stream from the exhaust — dense, bright blue-white, fading over 8 frames. The boost acceleration is accompanied by a VA engine roar sweep that tracks the speed delta.
• Anchor — the anchor slowdown effect uses the Copper to apply a brief per-scanline distortion on the kart's screen region, simulating weight and drag.

Track atmosphere — each track has an environmental DSP preset:

• Beach tracks: subtle outdoor reverb with wind ambient
• Cave/underground tracks: cavern preset, early reflections from walls audible on engine echo
• Night tracks: the ambient noise floor drops; the engine sounds more isolated; the Copper drives a darkened colour temperature on non-lit surfaces

Audio

SuperTuxKart's music plays through the full synthesis arrangement. The kart engine sounds use VA oscillators tracking speed and gear state. The item SFX use the SFX archetype system — each power-up type has a characteristic synthesised sound rather than a pre-recorded sample.

The crowd audio — audience reaction to race events — uses the granular engine processing a single sustained crowd-noise seed, with grain density and pitch scatter modulated by race excitement level (position changes, item hits, final lap).

Sunrise Drive — An Original OutRun-Spirit Game (CC0)

An original work in the Ant64 CC0 collection. No Sega IP. No ROM requirements.

The OutRun aesthetic — the open coastal road, the sunset, the FM synthesis music, the pure sensation of speed through beautiful landscape — is not Sega's property. The feeling is. The idea of driving a sports car through a European coastal road as the sun sets, choosing routes at forks, racing against a timer rather than opponents, the road as a thing to be enjoyed rather than conquered — that is available to anyone.

"Sunrise Drive" is an original game in this tradition, designed around what the Ant64 hardware specifically enables, released as CC0 with all assets.

The Rendering System

The OutRun rendering technique is one of the most elegant in all of gaming: a flat plane, per-scanline perspective, scaled sprites. No 3D geometry. The Ant64 implements this with its native hardware rather than emulating period silicon:

The road — a Mode 7 affine tilemap layer with the Copper writing a new transform matrix on every scanline. The EE computes the road geometry each frame — curvature, banking, elevation — and pre-loads the Copper command list. The road stripe pattern cycles through palette registers per scanline. The computation is a tight inner loop on the EE; the Copper does the actual scanline work. Zero CPU cost during raster.

The road has three surface types distinguished by texture and audio:

• Tarmac: standard road, neutral tyre audio
• Coastal road: slightly textured, sea spray ambient audio
• Mountain pass: gravel shoulder visible at road edge, echo on tyre squeal

The horizon and sky — a HAM24 background layer. Not a gradient — a full photographic-quality atmospheric sky specific to the time of day and route. Morning routes have golden low-angle light with long shadows on the road surface (Copper shadow-strip darkening). Afternoon routes have high bright sky. The final route — the hardest — ends at sunset, the sky a full 24-bit gradient from deep orange at the horizon through amber to pale blue at the zenith.

The landscape — roadside objects at scale: trees, signs, buildings, pylons, coastal cliffs, café terraces. Each object is a hardware sprite at a scale computed from its distance table position. The Ant64 uses continuous scaling rather than the period hardware's 5-frame stepped scale, so objects grow and shrink smoothly as they approach.

Environmental layers at different parallax depths: foreground objects (trees, signs, barriers), mid-ground structures (buildings, cliffs), background (mountains, coastline), sky (HAM24). Each layer has independent Copper-driven scroll, producing genuine depth at zero CPU cost during raster.

Other traffic — hardware sprites at computed scale, colourful, sparse or dense per-route. When a traffic car is overtaken, a brief bloom wake particle burst fires from its rear — the disturbed air of a car you've just passed. Near-miss events produce a bloom flash at the margin.

The Audio

"Sunrise Drive"'s music is an original composition in the outrun electronic music tradition — warm FM synthesis, human-feeling rhythms, the specific production character of mid-1980s Japanese arcade music. Three tracks, one per route section. Each track shifts arrangement slightly between sections — the same composition more developed, more layered, as the route progresses.

FM authentic mode — the compositions are authored specifically for the VA/FM engine's DX7-compatible operator architecture. The timbres are designed to evoke the specific FM synthesis character of 1986 arcade hardware — metallic bass, warm pad chords, bright arpeggio leads — while using the full 24-bit precision and 128-voice count the FireStorm engine provides.

The engine sound — a dedicated VA oscillator system tracks the player's speed, current gear, throttle position, and lateral acceleration simultaneously. Smooth acceleration produces a clean rising tone. Flooring the throttle in a lower gear adds harmonic distortion at the top of the rev range. Hard cornering adds a continuous tyre squeal from the noise generator with band-pass filter tracking lateral G. The engine sound is synthesised, not sampled — it responds to every nuance of car state.

Spatial audio — the coastline ambient (sea, wind, occasional seagull from the SFX engine) is spatialised to the appropriate screen direction. Traffic cars each have their own engine VA oscillator that pans with screen position. Passing through a tunnel briefly applies the metal pipe environmental DSP preset — the engine echo bouncing off concrete walls — then releases back to the open-air preset as the car emerges.

The checkpoint siren — when time is running low, a specific FM patch plays the countdown tone. The full-synthesis arrangement means this tone has proper attack and character rather than a beep. A dedicated VA voice handles it so the music continues underneath without voice stealing.

Route Design

Five routes, five destinations. The route structure is a binary tree of choices at forks — left or right at each split. At a fork, the road ahead divides; the player chooses by steering. Each destination has a different environmental character:

1. Coastal village (easy route) — flat coastal road, warm, tourist-season traffic
2. Mountain pass — elevation changes, banking corners, sparse traffic
3. Airport — long straight sections, fast traffic, heat shimmer on the tarmac (Copper per-scanline colour modulation on road scanlines)
4. Vineyard hills — winding ascent, dappled light through trees, afternoon atmosphere
5. Sunset cliff (hardest route) — requires the most skillful driving; the sky is the most spectacular HAM24 backdrop; the route ends as the sun touches the sea

The Feel

"Sunrise Drive" is not a racing game in the competitive sense. There are no opponents. The timer is generous by design. The goal is to reach a destination and see the ending — a brief static illustration rendered in HAM24 at full colour depth, with a specific ending phrase from the music that only plays on successful completion.

The game is about the drive. The road, the landscape, the music, the sunset. It is a piece of interactive atmosphere in the OutRun tradition — the game that understood that a racing game could be about beauty rather than competition.

Designed for the Ant64's CRT simulation output on a large display: the JAMMA Arcade profile on HDMI, the bloom-enhanced sprites, the HAM24 sky, the FM synthesis audio through the speakers. This is what the machine is for.

Storage: ~25 MB (route data, sprite tables, HAM24 sky assets, audio patches, Copper command lists, EE bytecode). Released CC0 with all source material.

Enhanced Effects and Audio — A Framework for All Racing Games

The racing genre has a specific set of enhancement patterns that apply across all three games above. Rather than documenting them redundantly, the common framework is noted here:

Speed blur — at high speed, the peripheral view blurs. Implemented as a Copper per-scanline horizontal offset that increases with speed — the outer scanlines shift slightly relative to the centre, simulating optical blur from peripheral motion. The effect is strongest at extreme speed and absent at low speed. One Copper register write per scanline, computed from the current speed value.

Heat shimmer — on hot routes (desert, airport tarmac, sun-baked roads), the road surface ahead shimmers. Implemented as a Copper per-scanline vertical offset with a sinusoidal modulation of small amplitude (~1-2 pixels) applied to road-surface scanlines. The modulation frequency and amplitude scale with temperature setting.

Weather system — rain on the windscreen is a fullscreen layer of near-vertical bloom line streaks at varied angles, BLT_ADDITIVE, at low intensity so the track is visible through them. Heavy rain accumulates particle streaks; light rain is sparse. The audio DSP simultaneously applies a high-frequency attenuation and a rain ambient noise layer. Wet road surface reflections via the road reflection system described above. Entering and leaving rain happens per-route-section — the transition frame shows the rain beginning or stopping.

Motion blur on fast objects — high-speed cars (player at top speed, fast traffic) emit trailing bloom particles behind them at 3-5 per frame. At maximum speed the trail length matches the perceived speed visually. Each bloom particle fades over 4 frames.

Tyre smoke — aggressive braking and cornering produce tyre smoke: upward-rising grey bloom particles from the tyre positions at the road surface, slow dispersion, additive blend at low intensity. In competitive racing (SuperTuxKart) multiple karts braking simultaneously fills corners with smoke.

Engine audio universal — all racing games use the same VA oscillator engine audio model: frequency tracks RPM, harmonic content changes with gear and throttle position, noise component increases at high load. The tyre squeal uses noise through a band-pass filter with centre frequency tracking lateral acceleration. This model is authored once as a shared audio module and parameterised per-game for the specific vehicle character.

Crowd audio (SuperTuxKart) — spectator reaction using the granular engine is documented above. For the OutRun tradition (no spectators) the crowd audio is replaced by ambient environment audio: sea, wind, mountain echo, urban traffic noise. Each applies automatically via the environmental DSP preset system.

Positional audio for all moving objects — the pan matrix writes vehicle sound position in real time from screen X position. All vehicles: the player's car (centre), opponent cars (their screen position), ambient traffic (their track position projected to screen). The sound world is a direct reflection of the visual world.

Shoot-em-ups — Gradius/Salamander and Ghosts 'n Goblins Style

The Genres

Gradius/Salamander (horizontal scrolling shoot-em-up) — the player's ship scrolls right through waves of enemies, collecting power-up capsules that fill a selectable options bar. Speed, missiles, laser, option drones — the power-up system is the game's mechanical identity as much as the shooting. Bosses are large architectural entities with a core that must be destroyed. Salamander (known as Life Force in some regions) added simultaneous two-player co-op and alternated between horizontal and vertical scrolling stages. The genre defines the 16-bit arcade experience as much as any other.

Ghosts 'n Goblins / Ghouls 'n Ghosts — a platform action game where Arthur, in his suit of armour, battles through graveyards, haunted forests, and castle dungeons against rising ghosts, walking skeletons, flying demons, and large armoured bosses. The defining mechanical features: enemies spawn continuously from off-screen at unpredictable positions; the player is one hit away from losing their armour (becoming a vulnerable knight in underwear); a second hit kills. The Gothic atmosphere — dark skies, flickering torchlight, enemies emerging from the ground — is as important as the gameplay.

Both genres have a specific problem for open source: no production-quality GPL game with fully free assets exists in either tradition. The Gradius clone landscape is thin and incomplete. The only significant open source Ghosts 'n Goblins engine requires the original Capcom ROMs for graphics and audio. The right approach for both is an original work designed around the Ant64's specific capabilities.

Powermanga — Vertical Shmup

Engine: Powermanga Licence: GPL v3 — engine and all assets Assets: All included, fully free Source: github.com/tlk-games/powermanga

The Game

Powermanga is a vertical scrolling shoot-em-up with 41 levels and over 200 enemy sprites, developed by TLK Games and released under GPL v3 with all resources included. It is the only complete, production-quality shmup in the open source landscape with fully free assets. While it is a vertical scroller rather than the horizontal Gradius tradition, it is the correct starting point for an Ant64 shmup implementation — a real game with real levels rather than an incomplete clone engine.

The gameplay involves flying a small spaceship through waves of enemies that fly in formation patterns, with power-ups, end-of-level bosses, and a classic arcade difficulty curve. It is closer to Galaga or Star Force in feel than to Gradius's option-bar system.

The Hardware Match

Hardware sprites at scale — Powermanga at peak density has the player ship, dozens of simultaneous enemy ships in formation flight, multiple bullets from all parties, power-up items, and explosion sprites all simultaneously on screen. This is exactly what the FireStorm hardware sprite layer was designed for. Hundreds of sprites per scanline, zero additional render cost.

Tate mode — Powermanga is a vertical shooter. At 4K output, Tate mode renders it in portrait orientation with correct rotated CRT scanlines. The dual Tate mode supports two simultaneous instances for co-op play, each player's field independent and side by side.

Bloom particles for explosions — every enemy death is currently a sprite animation. The Ant64 enhancement replaces this with a blit.particlelist bloom explosion — the same system used across all other games, here scaled appropriately for small space objects. Formation enemy explosions chain — multiple ships destroyed in rapid succession accumulate bloom at the impact zone, the density building as a formation is cleared.

Parallax star field — the scrolling background star field uses the multi-layer parallax system. The current Powermanga uses a simple scrolling field; the Ant64 version replaces this with the three-layer depth parallax of the space environment variant, with bloom halos on nearby stars.

Audio Enhancement

Powermanga's audio is functional but sparse. The Ant64 version replaces it with:

• Weapon sounds — each weapon variant gets a distinct VA synthesis voice: the basic shot as a brief high-pitched FM pulse, the spread shot as three simultaneous pulses with slight pitch offset, the laser as a sustained sine with fast attack and slow decay
• Enemy audio — formation entry uses a procedural approach: the engine synthesises a characteristic sound per enemy type from small SFX patch parameters (50 bytes per enemy type)
• Music — an original electronic composition in the classic Japanese shmup tradition: FM synthesis, percussive rhythms, melodic urgency. Three tracks (early levels, mid-game, final approach) with the full synthesis arrangement

An Original Horizontal Shooter — "Vic Raider"

An original horizontal scrolling shoot-em-up in the Gradius/Salamander tradition. CC0. All original assets.

There is no clean open source Gradius equivalent. The right response is to build one — and to build it as a showcase of what the Ant64 can do rather than as a faithful port of a period game.

"Vic Raider" is an original horizontal scrolling shoot-em-up in the power-up bar tradition. Original ship design. Original enemies. Original levels. Released CC0.

The Gradius Power-Up System — Mechanically

The defining mechanic of Gradius is the power-up capsule system. Every capsule the player collects advances a cursor along a selection bar at the bottom of the screen: Speed, Missile, Double, Laser, Option, Shield. Pressing the power-up button acquires the currently highlighted item and resets the cursor. The player manages which items to acquire across the run — choosing between chaining multiple Speed upgrades for manoeuvrability or waiting for Option drones for firepower.

This is a pure game logic system — no rendering dependency. It runs entirely on the C906 game loop. The Ant64 renders the power-up bar as a HAM24 UI layer at Hires resolution, sharp and precise, floating above the game layer.

The Hardware Match

Option drones — the Gradius Option drone is a small ship that follows the player's path and mirrors their shots, trailing behind. The Ant64 version renders each Option as a bloom particle cluster — not a static sprite but a persistent glow that follows the exact path history of the player ship. The bloom radius makes each Option look like a small reactor trail. Four Options in full-power configuration produce a trail of glowing reactors behind the player that is visually distinctive on the Ant64 in a way no period hardware could achieve.

Laser — the Gradius laser is a sustained horizontal beam from the player's position to the screen edge. On the Ant64 this is a blit.line_bloom call with the Sharp vector preset — maximum intensity, high falloff, maintained for the duration of the fire input. Multiple power-up stages widen the beam: Stage 1 is a single thin line; Stage 2 is three parallel lines; Stage 3 is a wide devastating bloom bar that fills a significant vertical extent with additive light. Enemies caught in the Stage 3 laser visibly glow at the impact point before being destroyed.

Moai Easter Island heads — the Gradius series' most iconic enemy. Large stone heads mounted on walls that fire ring-shaped projectiles. The Ant64 version renders the ring projectiles as blit.line_bloom circles — expanding bloom rings rather than sprite animations. A Moai under fire from a sustained laser develops a growing bloom hot-spot at the contact point before exploding.

Terrain — Gradius levels have complex terrain geometry: ground-hugging cave sections, ceiling stalactites, alien organic structures. The Ant64 uses the tilemap system for terrain tiles with the clip table producing the terrain's arbitrary contour shapes. Player and enemy sprites clip against the terrain geometry via the clip table's per-scanline boundaries.

Boss cores — Gradius bosses have a core that must be exposed and destroyed. The core in the Ant64 version is a bloom particle cluster at the boss's centre — a pulsing glow that brightens as damage accumulates. The destruction sequence: the core bloom particle expands rapidly to maximum radius, a Copper full-screen white flash fires for two frames, then a large explosion particle burst radiates from the boss position. The boss sections that remain drift apart as individually physics-animated fragments before disappearing.

Background landscapes — HAM24 layers for the far background: space nebulae, alien planetary surfaces, deep cave formations. Each Salamander-style level stage has a HAM24 background specific to its theme (volcanic, aquatic, organic). The Copper drives a subtle colour temperature shift between level sections — the volcanic stages are warmer, the aquatic stages cooler.

Two-Player Co-op — Colony Connection

Salamander's defining innovation over Gradius was simultaneous two-player co-op. Both players fly simultaneously in the same field, their shots combining, their power-up states independent. The Ant64 supports this in two configurations:

Split-screen co-op — at Standard resolution, two horizontal strips using the layer clip table with diagonal or straight split. Each player's section shows the same game field; the split moves with the action.

Shared full-screen — both ships visible simultaneously in the single game field. This is the original Salamander approach and the more satisfying co-op mode. Colony Connection (Ant64/Ant64C) allows two machines to run co-op over the hardware link with sub-millisecond latency. Each machine renders the full scene; each player's ship is the primary for their own machine's audio positional system.

Audio

An original FM synthesis composition designed specifically for the VA/FM engine's DX7-compatible operator architecture, in the tradition of Konami's arcade soundtracks. The Salamander/Life Force music — some of the most beloved game music in the genre — established an FM synthesis vocabulary that the Ant64 can reproduce authentically and extend.

Three stage tracks, a boss track, a high-score track. All authored as note sequences for the FM engine, stored as compact data alongside the EE bytecode. The audio system demonstrates the FM engine at its core strength: the specific harmonic character of operator FM synthesis for game music, where FM voices have been the standard since the mid-1980s.

An Original Ghosts 'n Goblins-Style Game — "The Long Dark"

An original platform action game in the Gothic horror tradition. CC0.

The Ghosts 'n Goblins family — GnG (1985), Ghouls 'n Ghosts (1988), Super Ghouls 'n Ghosts (1992) — has no clean open source equivalent. The existing open source implementation requires Capcom ROMs. The alternative is an original game that captures what makes the genre distinctive and demonstrates the Ant64 hardware that is most appropriate to it.

"The Long Dark" is an original platform action game in the Gothic horror tradition — a knight moving through graveyards and castle dungeons against continuously spawning undead enemies. One-hit armour loss, two-hit death. Original IP throughout.

What Makes This Genre Distinctive

The Ghosts 'n Goblins feel comes from three things: the continuous enemy spawning from unexpected positions (ghosts rising from ground tiles, birds swooping from above, skeletons walking in from both sides simultaneously), the atmospheric environments (the flickering torchlight of graveyards, the dark corridors of castles, the eerie silhouette landscapes), and the deliberate enemy patterns that feel relentless but learnable.

All three are game-logic concerns. The rendering is 2D sprite platforming. The Ant64 hardware enhances the atmosphere specifically:

The Hardware Match — Atmospheric Lighting

The defining visual quality of the Ghosts 'n Goblins series is the Gothic atmosphere. Dark environments lit by sources that are individually identifiable — torches, candles, moonlight. The player's position in relation to light sources affects the visible environment around them.

Per-torch bloom lighting — every torch in a level is a permanent bloom particle at its world position, warm orange, flickering at ~8Hz with randomised per-torch phase. The same system used in the Doom torch enhancement. In a graveyard level with eight torches, each casts a visible warm glow onto the ground and nearby headstones. The player's sprite, passing near a torch, is warmed by its Copper per-scanline palette tint.

Moonlight — the level background has a large dim bloom circle (the moon) in the upper portion of the HAM24 sky layer. Its Copper-driven tint affects the entire level with a cold blue-white ambient that the torch light fights against. The visual relationship between warm torch light and cold moonlight is the defining lighting palette of the Gothic genre.

Enemy emergence effects — ghosts rising from the ground use the dissolve particle effect from the Halloween boot intro variant: particles drift upward and converge into the ghost shape as it materialises. Skeletons walking in from off-screen cast a brief shadow (a dark region ahead of them from the Copper shadow-strip system). Flying demons enter from above with a brief wing-shadow sweep across the ground.

The armour loss — when Arthur is hit and loses his armour (transitioning to the underwear sprite), the Copper fires a full-screen brief desaturation pass — the colour temperature drops suddenly then recovers over 8 frames, the brief moment of vulnerability made physically real. The underpants sprite emits a faint embarrassed pink bloom halo. The humour and the horror are the same event.

The death sequence — Arthur's death plays as a bloom particle expansion from his position, the sprite dissolving into particles that drift upward, the Copper driving a brief darkening of the entire level, then the player's name and score appearing in the HAM24 layer. The Gothic death scene that Capcom made famous, executed with the full particle and Copper system.

Enemy Variety and Spawning

The genre's difficulty comes from enemy density and unpredictable spawn positions. The Ant64 hardware sprite layer handles the simultaneous count:

A fully-loaded level might have:

• 12 walking skeletons
• 8 flying knights
• 4 ghosts rising from ground
• 6 projectiles from various sources
• The player character

That is 30 simultaneous sprites. The hardware handles hundreds per scanline. The C906 managing the spawn logic and AI has complete computational headroom for dense, complex spawn patterns that would have been impossible on the original hardware.

The Copper for difficulty feedback — as enemy density increases (more spawns per second in later levels), the Copper slightly increases the ambient bloom intensity on enemy sprites — they appear slightly more luminous, as if the supernatural menace of the level has increased. This is a subliminal difficulty-communication mechanism that uses the Copper for a purely atmospheric purpose.

Audio

The Gothic orchestral audio uses the VA engine with the full voice count, FDN reverb at long hall settings, and BBD chorus on string voices. The enemy audio uses the SFX archetype system — each enemy type has a compact SFX patch (50-100 bytes) defining its characteristic sound. The level ambient uses the cavern and outdoor environmental DSP presets appropriately — graveyards get outdoor reverb with wind ambient; castle interiors get the cavern preset with stone resonance.

The music is in a minor key, orchestral, with a pulse-like rhythm that tracks the player's survival state — the tempo increases slightly as enemy density increases, creating urgency without a UI indicator.

Common Shmup and Action Platform Effects Framework

Several enhancement patterns apply across both shooter and platform action genres:

Formation enemy explosion chains — when multiple enemies are destroyed in rapid succession (a formation cleared by a laser or wide shot), the explosion particle systems at each position are additive-blended. Nearby simultaneous explosions accumulate bloom at the overlap region, producing a visually denser destruction event that rewards accuracy.

Bullet count management — both genres involve many simultaneous bullets on screen. Bullets are hardware sprites (small, simple), but each bullet additionally emits a single-frame bloom particle at its position — not persistent, just one frame per update — that gives enemy bullets a slightly glowing quality that makes them more readable against complex backgrounds. The bloom is very low intensity and does not obscure the bullets; it adds a slight phosphor-glow quality.

Boss health bloom — a convention shared across both genres: boss enemies become more visually agitated as health decreases. The Ant64 implements this by scaling the boss sprite's associated bloom intensity with inverse health — undamaged bosses are calm; near-death bosses flicker, their bloom particles intensifying. The visual state communicates the gameplay state without a health bar.

Screen shake — large explosions (boss deaths, player bomb weapons) write a brief Copper per-scanline horizontal offset displacement — a few pixels, decaying over 6-8 frames — that produces a screen shake effect. One Copper list, one frame computation, physically convincing shockwave feedback.

Two-player split audio — in co-op modes, each player's positional audio is independently weighted. Player 1's ship sounds come from the left; Player 2's from the right. Enemies between them are centred. The audio space reflects the spatial relationship of both ships simultaneously.

Deluxe Pixel Games — Original Works by Anthony Ball

All games in this section are original works by Anthony Ball / Deluxe Pixel Limited. No licence concerns. No ROM requirements. No third-party IP dependencies. These are native Ant64 titles — designed for the hardware, released as part of the Ant64 software library.

The Ant64 versions of these games are Luau-scripted applications running on the C906, offloading all rendering to FireStorm. They are the first games in this collection where the author of the game and the author of the hardware are the same person.

Dungeons

Original game: Deluxe Pixel Limited Genre: Gauntlet-style top-down action — shoot everything, survive the horde Ant64 version: Native Luau + FireStorm rendering, full Gothic lighting system

Dungeons is a Gauntlet-style game. Players move through dungeon rooms from a top-down perspective, shooting or melee-attacking continuous waves of enemies that pour from monster generators. Keys open doors. Food restores health. Health drains continuously — the dungeon is trying to kill you by attrition as much as by combat. Up to four players simultaneously, each a different character class with different weapon ranges and movement speeds.

The defining property of the Gauntlet genre is enemy density. At full difficulty the screen is thick with enemies simultaneously — ghosts, grunts, demons, lobbers, sorcerers, death — all moving toward the players, all requiring hits to kill, while generators continue spawning more until destroyed. The hardware sprite layer exists for precisely this situation.

Enemy density — hardware sprites

A full Gauntlet-style room at peak spawn density can have 60–80 simultaneous enemy sprites on screen, plus player sprites, projectiles, food, keys, and potions. The hardware sprite layer handles this count at zero performance cost. The C906 manages AI and physics for the full entity list; FireStorm renders every sprite in one pass.

The sprite density communicates the game's central feeling: the dungeon is overwhelmingly populated. The hardware enables enemy counts that would have been impossible on the original arcade hardware.

Monster generators

Generator tiles pulse with a bloom halo in the colour of the enemy type they spawn:

• Ghost generators: cold blue-white pulse, moderate spawn rate
• Grunt generators: warm red pulse, rapid spawn rate
• Demon generators: deep orange pulse, slower but the demons are dangerous
• Sorcerer generators: purple pulse, low spawn rate but sorcerers can create ghost clones of the players

The generator's bloom intensity increases with its remaining health — a nearly-dead generator pulses brighter and faster. Destroying a generator fires a large bloom burst at its position and the spawn flow from that location stops. Prioritising generators is the core tactical decision; the hardware makes every generator's status visually readable across the room at a glance.

Atmospheric lighting

The Gauntlet dungeon is lit by sources: wall torches, floor braziers, magical generator glow, loot item halos. The same per-source bloom system as "The Long Dark" applies here, with the difference that Gauntlet rooms are brighter and more readable by genre requirement — the player needs to see the full room's enemy state at all times.

Torches provide warm orange pools. Generator bloom provides coloured ambient in their zone of the room. Player projectiles — arrows, magic bolts, axes — emit brief bloom trails during flight. The room's lighting is a live composition of all these sources simultaneously, driven by the hardware bloom system.

Player classes — visual distinction

Each character class has a distinct bloom signature:

• Warrior: no ranged bloom; melee impacts fire a bright impact flash at contact. Personal halo is warm gold — the warrior is lit as if armour-polished
• Valkyrie: shield reflects projectiles with a brief deflection bloom flash. Personal halo is silver-white
• Wizard: magic projectiles as blit.line_bloom bolts, blue-purple. Personal halo is cool blue. Magic blast (area attack) is the largest player-emitted bloom event in the game
• Elf: arrow flight uses a thin warm-yellow bloom trail, faster than other projectiles. Personal halo is green. The elf's high speed means their bloom trail is briefly visible as a motion streak

Health drain — the Copper

Gauntlet's defining mechanic is continuous health drain. As a player's health falls, the Copper drives a gradually deepening desaturation of that player's screen region — the colour slowly leaving the game as health approaches zero. At critical health the screen is near-monochrome, with only the bloom colours retaining saturation. This is the most direct possible use of the Copper for game state communication: the player feels the danger in the colour of the world around them.

Food items glow with a warm amber bloom — highly visible across the room, prioritised by the visual system because food equals survival. Keys glow gold. Potions glow in their effect colour (blue for health restore, red for area-damage). The loot visual hierarchy is entirely in bloom colour.

Death and "Thy dungeons are replete with danger"

When a player dies, the Copper fires a brief full-screen desaturation to grey, then the respawn sequence begins (if the player has lives remaining). The classic Gauntlet announcer voice — in synthesised form via the FM voice architecture — delivers the floor-specific warning phrases. The announcer voice is a specific FM patch: a booming bass formant with long reverb tail, convincingly authoritative.

Four-player — Colony Connection

Four Ant64 units on a Colony network, one player each, all rendering the same dungeon room simultaneously. Each player's screen shows the full room. Colony Connection's sub-millisecond latency makes the four-player melee — all four characters attacking, all enemies responding, projectiles from all sources simultaneously — feel tight and immediate. The dungeon is lit by the bloom of all four players' personal halos plus the room's fixed sources plus all active projectiles. At full four-player capacity the room is alive with overlapping coloured light.

Audio

The dungeon ambient uses the cavern environmental DSP preset calibrated to room size. Each monster type has a characteristic synthesised audio signature — grunts are percussive, ghosts are a sustained formant, sorcerers are a high FM oscillator event. The generator spawn sound is a brief rhythmic pulse matching the generator's bloom pulse rate. The warrior's melee impact is a heavy noise burst; the wizard's magic bolt is a FM sweep event; the elf's arrow is a brief high-pitched FM click. The room soundtrack uses the full VA voice count with long hall reverb — percussive, driving, urgent.

RetroStar

Original game: Deluxe Pixel Limited Genre: Star Raiders-style — first-person space combat with strategic galactic map Ant64 version: blit.line_bloom wireframe combat, Copper scanner, sector strategy

RetroStar is a Star Raiders-style game. The player flies a fighter defending a galactic sector map against Zylon (or equivalent) fleets that move strategically between sectors, attacking starbases and accumulating pressure. The game has two distinct modes that alternate: first-person combat (engage the enemy in the current sector) and the strategic galactic map (hyperspace to the right sector before starbases are destroyed). Energy management threads through both — combat costs energy, hyperspacing costs energy, docking at a starbase restores it.

Star Raiders was the first game to do this — the combination of immediate first-person action and strategic map pressure, with resource management linking them. It defined a genre that Elite and later space games built on. The "retro inspired" framing is explicit: this is Star Raiders-style play on Ant64 hardware.

First-person combat view

The combat view is first-person, looking forward from the cockpit. Enemy ships appear as wireframe objects at range, growing as they close. The original Star Raiders used vector-style flat wireframe; the Ant64 renders every ship as a blit.line_bloom wireframe — the lines glow, bloom accumulates at vertices, additive blending makes near-misses from crossing bolts visually intense.

Enemy ships at distance are small wireframe outlines; at close range they fill a significant portion of the view and the bloom on their hull lines is vivid. A damaged enemy ship has broken bloom lines — segments of the wireframe missing or flickering, the structural damage communicated in the wireframe itself.

The targeting reticle is a blit.line_bloom crosshair — not a flat sprite, a glowing overlay that pulses briefly when an enemy is in the kill zone.

Photon torpedoes and lasers

Torpedo fire produces a bright bloom line extending forward from the ship's nose at high speed, BLT_ADDITIVE, maximum intensity. A hit on an enemy ship produces a brief bloom burst at the contact point then the enemy wireframe expands rapidly outward (the explosion as an expanding wireframe sphere) before disappearing. The wireframe explosion is pure blit.line_bloom — an expanding icosahedron drawn in glowing lines, fading over 8 frames.

Laser fire is sustained — a thinner, continuous blit.line_bloom beam held for the duration of the trigger. Energy drains faster with laser than torpedo. The energy trade-off between weapons is a gameplay decision driven by the combat situation.

Shield impacts

When the player takes a hit, the Copper fires a brief per-scanline horizontal displacement — a physical shockwave distortion of the entire view, decaying over 4 frames. The intensity of the shockwave scales with hit energy. A direct torpedo hit produces a large distortion; a glancing blow is a minor shudder. The energy shield level is visible in the cockpit HUD as a bloom intensity bar — the shield glows brighter when full, dims as it depletes.

The galactic map — Copper scanner

The strategic map is the game's other half. The original Star Raiders rendered it as a simple grid overlay. The Ant64 version renders the galactic map as a full-screen Copper-driven display — the classic green-phosphor scanner aesthetic of a 1979 tactical screen, executed with HAM24 colour depth.

The map grid is a blit.line_bloom lattice at low intensity — the grid lines glow faintly as if on a CRT phosphor. Each sector is a cell: empty sectors are dark, sectors containing enemy fleets have a red bloom point, starbases have a blue bloom point, the player's current sector has a bright white bloom point. Enemy movements between sectors are visible as brief bloom trails crossing grid lines — the fleet relocating in real time.

The Copper drives a gentle horizontal scan-line sweep across the map, the scanner beam moving top-to-bottom at a constant rate. This is the Star Raiders scanner effect — the beam illuminating the grid as it passes, the map revealed and updated by the sweep. The full sweep cycle is ~2 seconds. The Copper writes a slightly brighter scanline at the beam position each frame; sectors below the current beam position show their last-scanned state.

Selecting a destination sector highlights it with a pulsing bloom outline. The hyperspace jump cost (energy) appears as a HUD overlay. Confirming the jump initiates the hyperspace sequence.

Hyperspace sequence

The hyperspace jump is the game's most spectacular single animation. Star-lines extend from the centre of the screen outward as the ship accelerates — the classic hyperspace star-streak effect. On the Ant64 this is a blit.line_bloom radial burst: dozens of bloom lines extending from the screen centre to the edges, their intensity rising rapidly over 6 frames then cutting to black as the jump completes. The destination sector then fades in — if it contains enemies, their wireframes appear immediately at distance.

The audio for hyperspace is a VA oscillator sweep: a rising pitch from the engine note through the audible range and beyond (implied), the BBD chorus widening to maximum, then cutting to the silence of the destination sector.

Starbases and docking

A starbase is a blit.line_bloom wireframe structure larger than any enemy ship — a rotating geometric form (the original used a cube; the Ant64 version uses a more complex polyhedron) visible at distance as a complex glowing wireframe. Approaching to dock produces a docking alignment UI: bloom guide lines extending from the starbase docking port. Successful docking triggers the energy restore sequence — a rapid bloom intensity rise on the HUD energy bar.

If an enemy fleet reaches a starbase sector and the player is not there, the starbase is destroyed — a large bloom burst on the galactic map at its grid position, the blue point extinguishing. Losing all starbases is the primary fail condition. The pressure of watching fleet bloom points move toward starbase bloom points on the scanner is the game's central strategic tension.

Energy management — the Copper HUD

The cockpit HUD is a dedicated Copper layer: energy bar, shield bar, weapon mode indicator, sector quadrant display. All parameters update each frame as Copper register writes. The energy bar depletes visibly as combat and hyperspacing consume it — the Copper bar shortens in real time. At critical energy the bar pulses red. No UI code required during gameplay; the Copper manages the display.

Audio

The cockpit ambient is the engine note — a low VA oscillator hum that responds to throttle. Torpedo fire is a sharp FM percussion event; laser is a sustained FM tone. Enemy fire is a distinct FM event with a different harmonic character. Shield impact uses the shockwave VA event. The scanner has a low continuous sweep tone — a slow FM oscillator cycling at the scanner beam rate, giving the galactic map a sonar quality. Starbase destruction on the map produces a brief, sombre FM chord. The music uses the full synthesis voice count with the space environmental DSP preset — vast reverb, isolated engine hum fighting against an expansive pad arrangement.

Zombies!

Original game: Deluxe Pixel Limited Genre: Lemmings clone — guide, assign abilities, save the horde Ant64 version: Hardware sprite crowd, Copper terrain, bloom ability effects

Zombies is a Lemmings-style game. A stream of zombies enters from one side of the level and walks forward mindlessly, falling off ledges and walking into hazards, until the player assigns abilities to specific individuals to navigate them safely to the exit. The Lemmings formula is one of the most mechanically elegant puzzle designs in gaming: the challenge is entirely in understanding the terrain, planning the sequence of ability assignments, and executing at the right moment.

The zombie framing is a natural fit — the mindless forward shuffle of a lemming is tonally identical to a zombie horde, and the comedy of individual zombies being assigned different roles (this one digs, this one builds, this one stops the others) maps well to the undead theme.

The zombie horde — hardware sprites

A full Lemmings-style level can have dozens of active zombies simultaneously: the incoming stream, those navigating the terrain, those being blocked, those digging. The hardware sprite layer handles the full simultaneous count with no performance cost. Each zombie is an independently animated sprite; the C906 manages individual state (walking, falling, ability active, dead) and updates each sprite's position and animation frame each tick.

The horde emits a low collective bloom — individually each zombie has a barely- perceptible sickly green halo, but a crowd of 30 zombies accumulated at a bottleneck produces a visible green ambient glow at that position. The crowd lighting is an emergent property of individual bloom emitters, not a separate system.

Abilities and their visual vocabulary

Each ability is visually distinct via bloom effects so the player can read the state of multiple ability-assigned zombies simultaneously across a busy level:

• Blocker: the assigned zombie stops and stands with arms outstretched, blocking the horde behind them. A steady red bloom halo — the visual signal that this zombie is holding position
• Digger: digs straight down through earth tiles. A shower of earth bloom particles sprays upward from the dig position each tick — the same dirt-cloud system as Zombie Rocks, here applied vertically
• Basher: tunnels horizontally through earth. The tunnel direction produces a forward-pointing debris bloom trail
• Builder: lays a staircase of tiles. Each placed tile emits a brief construction bloom flash as it appears — the staircase grows visibly, tile by tile
• Climber: scales vertical walls. A brief grip-bloom flash at the hand position each animation frame, indicating active climbing
• Floater: the zombie produces a visible parachute sprite (or umbrella) and descends slowly; the parachute emits a gentle lifting-air bloom at its edge
• Exploder: the assigned zombie begins a countdown (flashing red at increasing frequency via the Copper per-sprite tint), then detonates — a large bloom explosion that destroys surrounding terrain tiles. The explosion radius is communicated by the pre-detonation bloom expansion

Terrain

The level terrain is a tilemap layer: earth (destructible), steel (indestructible), trap tiles (kill on contact), water (drowning), and exit tiles. Destructible earth tiles clear to empty space on dig or explosion — the same tilemap write mechanism as Zombie Rocks. The terrain structure is visually clear: earth tiles have a warm brown texture, steel tiles have a cold metallic character with a faint specular bloom.

Trap tiles have a hazard bloom indicator — a pulsing red halo that communicates danger to the player. The player learns to read bloom colour as hazard status.

The save counter

The Lemmings save counter — "save at least X of Y" — is the game's primary tension. As zombies reach the exit the counter climbs; as zombies die (fall into traps, drown, explode without reaching safety) the counter drops toward the minimum. When the minimum becomes unreachable, the Copper drives an increasing desaturation of the level — the colour draining from the scene as the save run fails. A successful save completion fires the level clear bloom celebration.

Audio

The zombie shuffle uses a continuous low-frequency footstep rhythm from the VA engine, its density tracking active zombie count — more zombies, denser footstep rhythm. Each ability has a characteristic sound: the basher's horizontal digging is a rhythmic crunch, the builder's tile placement is a brief tap per tile, the exploder's detonation is the full bloom audio event. The exit uses a brief ascending FM sting per saved zombie. The collective "sigh" of saving the final required zombie — just making the target — uses a specific FM event that the player will come to recognise as relief.

Zombie Rocks!

Original game: Deluxe Pixel Limited Genre: Boulder Dash clone — dig, collect, survive falling rocks Ant64 version: Tilemap cave system, physics simulation, bloom destruction effects

Zombie Rocks is a Boulder Dash-style game. The player digs through an underground cave of earth, collecting brains (the game's equivalent of Boulder Dash's diamonds) while avoiding rocks that fall under gravity when the earth supporting them is removed. The witch's curse framing means the player is a zombie who must collect brains to survive — the Boulder Dash diamond mechanic wearing Gothic horror comedy.

The genre is entirely about physics simulation and spatial planning: understanding which rocks will fall, in which direction, when you dig where. Get it wrong and a rock falls on you. Get it right and a falling rock crushes an enemy.

The cave as tilemap

The cave is a grid of tile types rendered by the tilemap hardware: solid earth (diggable), empty space (dug or pre-existing), rocks (fall under gravity), brains (collectibles), indestructible walls, and enemy-specific tiles. The entire cave state lives in the tilemap layer — the C906 runs the physics simulation each tick and writes changed tile entries to the tilemap hardware. The hardware renders the result; the CPU models the physics.

Earth tiles have a slightly textured appearance distinguishing them from empty space. When the player digs into an earth tile it clears to empty space in a single tilemap write — instant, zero-overhead removal. A brief dirt-cloud particle burst fires at the dig position: a small brown bloom scatter, 3–4 frames, communicating the physical act of digging.

Rock physics

A rock tile falls if the tile directly below it is empty. A rock resting on another rock slides left or right if the diagonal below-and-left (or below-and-right) is empty space. This cascade logic — Boulder Dash's defining physics — runs on the C906 each game tick as a sweep through the rock tile list.

Falling rocks produce a continuous trail of brief bloom particles as they descend — a thin vertical smear of grey-brown light marking the fall path. When a rock lands, an impact bloom burst at the landing position: bright, brief, scaled to how far the rock fell. A rock that has fallen from the top of the cave to the bottom produces a significantly more dramatic impact than one that has dropped a single tile.

Rock-on-player impact: the Copper fires a brief full-screen red flash (one frame), the player death particle burst fires, and the level resets. The rock that killed you sits on the empty space where you were.

Rock-on-enemy impact: the enemy death produces a bloom burst appropriate to the enemy type — a brief bright flash, the enemy sprite disappearing, a small particle scatter. Using rocks as weapons against enemies is the game's primary tactical depth. The satisfaction of engineering a rock-fall that crushes an enemy is made physically real by the impact bloom and the enemy's destruction burst.

Brain collection

Brains glow with a warm pink-green bloom halo — visible across the cave, drawing the player's attention and helping them plan routes. When a brain is collected, a brief ascending bloom burst at the collection position. The remaining brain count is tracked; when the target count is reached, the cave exit unlocks with a brief bloom flash at the exit tile position.

Enemies

Enemy types follow the Boulder Dash model — creatures that roam the cave, that can be crushed by rocks, and that kill the player on contact. Each enemy type has a characteristic bloom signature:

• Fireflies: warm orange bloom halo, erratic movement, explode on contact with a rock or the player (producing a large bloom burst that destroys surrounding earth)
• Butterflies: cool blue bloom halo, more predictable patrol movement, transform into brains when crushed by a rock — a key mechanic for brain farming
• Shambling undead: green bloom halo (fellow zombies), slow but numerous

The time pressure

Boulder Dash's tension comes from the ticking clock combined with the physics. As time runs low, the Copper drives an increasing red tint on the cave ambient — the urgency of the deadline communicated atmospherically. No UI required.

Audio

Digging uses a rhythmic earth-crunch VA percussion event. Rock falls produce a rumble that pitches slightly with fall distance — a short fall is a dull thud, a long fall is a lower, heavier impact. Brain collection uses a brief wet FM event (deliberately comic — it is a brain). Firefly explosion uses the full bloom audio event: a sharp broadband burst followed by a brief resonant decay. The cave ambient uses the cavern preset with early reflections tuned to the current cave size.

Footy Manager

Original game: Deluxe Pixel Limited Genre: Sensible Soccer / Kick Off style — top-down arcade football with management layer Ant64 version: Dual-mode — management (AntOS UI) and top-down arcade (hardware sprites)

Footy Manager combines a football management layer with Sensible Soccer / Kick Off style top-down arcade match play. The management screens handle squad, tactics, transfers and season progression; the matches play out as fast top-down arcade football — small player sprites, the ball with its own physical momentum independent of the players, aftertouch on shots and passes, the fast direct gameplay of Sensible Soccer rather than a simulation.

Management mode — AntOS terminal

Squad lists, match fixtures, transfer market, league tables, tactics board, training, finances — all run as an AntOS Luau application with the standard terminal UI. Text-mode management screens are fast, legible, and appropriate to the genre. The tactics board is a simple top-down sprite pitch diagram showing formation positions. No 3D rendering required; the management layer is pure data and Luau logic.

Arcade match mode — top-down hardware sprites

When a match kicks off the game transitions to the FireStorm sprite pipeline. The view is directly top-down, scrolling to follow the ball — the classic Sensible Soccer / Kick Off perspective.

The pitch is a flat tilemap layer: green turf tiles with white line markings at the centre circle, penalty areas, and goal lines. The tilemap scrolls with the action via the hardware scroll registers — zero CPU cost.

22 player sprites simultaneously on the hardware sprite layer, plus the ball. The ball is a separate sprite with its own physics state — position, velocity, spin — updated each tick by the C906. This is the Kick Off model: the ball is not glued to a player, it has momentum, it rolls, it deflects off players and posts, it curves with aftertouch applied after the kick.

Ball physics and aftertouch

The ball's spin state drives aftertouch curl after a kick or pass. A shot with aftertouch applied bends toward the near post; a through-ball with backspin slows after the initial pace. At high speed the ball has a brief bloom motion trail — a single-frame smear of bloom particles behind it in the direction of travel, giving it visible pace. A shot that hits the post produces a sharp deflection bloom flash at the contact point.

Player sprites

Players are small hardware sprites identified primarily by shirt colour — the Sensible Soccer model. The currently controlled player has a faint blit.line_bloom chevron above them as a cursor indicator.

The crowd

The crowd is a HAM24 layer at the pitch edge — photographic-quality stadium crowd in the home team's colours. The Copper tints the crowd layer with the home team's colour temperature. The crowd audio uses the granular engine: grain density and pitch scatter track match excitement in real time. A goal produces a 3-second roar at maximum grain density. Near-misses produce a shorter sharper reaction. Own goals produce a roar that resolves into a confused murmur — the audio system differentiates.

Goal celebrations

Bloom burst at the net position, expanding outward. Copper fires a 2-frame full-field colour flash in the scoring team's colours. The goalscorer's sprite briefly emits a larger personal bloom halo.

Two-player — Colony Connection

Head-to-head via shared screen or Colony Connection for two machines each with their own display, synchronised ball and player state at sub-millisecond latency.

Ping Pong DX

Original game: Deluxe Pixel Limited Genre: Breakout/Arkanoid-style arcade with enhancements and power-ups Ant64 version: Hardware sprite field, bloom brick destruction, power-up vocabulary

Ping Pong DX is a Breakout-style game: a paddle at the bottom, a ball bouncing through a field of bricks, power-ups dropping from destroyed bricks. The "enhancements and power-ups" in the original description are the mechanical identity of the game — the brick field is varied in arrangement and brick type, and the power-up system changes what the ball and paddle can do mid-level.

The Ant64 hardware maps to this genre directly and richly. The brick field is a tilemap hardware layer. Bricks are tile entries — destroying a brick writes a blank tile entry at its position, which is a single BSRAM write. The overhead of clearing a brick is essentially zero. The ball is a hardware sprite. Power-up items are hardware sprites falling under physics. The paddle is a hardware sprite. The entire visual state of a full brick field plus ball plus multiple falling power-ups is the hardware sprite layer doing what it was designed for.

The brick field

The field is a tilemap layer. Each brick type is a distinct animated tile entry: standard bricks in the hardware sprite palette colour, reinforced bricks in a distinct texture, indestructible bricks in a heavy stone tile, explosive bricks with a faint pulsing bloom halo indicating their volatile state, invisible bricks with no tile entry at all until hit. The tilemap hardware renders the full field at zero CPU cost.

When a brick is destroyed, a blit.particlelist bloom burst fires at its grid position — the brick's colour determines the burst colour. Standard bricks produce a brief mid-intensity burst. Reinforced bricks require multiple hits; each hit produces a crack particle effect (sharp thin bloom lines radiating from the impact point) before the final destruction burst. Explosive bricks chain: the initial destruction triggers a delayed burst that destroys adjacent bricks, each producing their own burst in a ~6-frame cascade. A large explosive chain lights up a section of the field like a fireworks string.

The ball

Not a square. A bloom particle cluster at the ball position updating every frame. The bloom radius scales with current speed — at low speed it is tight and focused; at high speed it expands, the ball visibly luminous with velocity. A trail of decaying bloom particles in the direction of travel gives the ball readable momentum at high speed.

Ball contact with a brick fires a bright impact flash at the contact point in a complementary colour to the brick. At high speed with multiple balls active (a multi-ball power-up), the simultaneous impacts across the field produce a continuous scatter of bloom flashes — the field is being lit up by the destruction.

Power-ups

Power-ups drop as hardware sprites from destroyed bricks, falling under gravity. Each power-up type has a characteristic bloom halo colour so the player can identify it while it falls and decide whether to catch or avoid it:

• Multi-ball — splits the current ball into three; warm white bloom halo. The most spectacular visual state: three balls with independent bloom trails all moving simultaneously, impacts firing across the field at once.
• Wide paddle — paddle sprite widens; the paddle bloom halo broadens with it.
• Laser paddle — the paddle fires vertical laser bolts as blit.line_bloom lines from its edges, bright and sharp, destroying bricks directly. The laser mode makes the field feel like it is being cut rather than bounced through.
• Sticky ball — the ball adheres to the paddle on contact; cyan bloom halo. The stuck ball pulses gently while held, indicating it can be aimed and released.
• Slow ball — the ball slows; the bloom radius tightens back to minimum.
• Fast ball — the ball accelerates; the bloom radius expands immediately to maximum. A dangerous power-up in a crowded field.
• Fireball — the ball destroys bricks without bouncing (passes through); deep orange-red bloom trail, significantly larger radius than the normal ball. The fireball carves channels through the field, the bloom trail lingering briefly after each brick position it passes through.
• Shield — a horizontal bloom line appears at the screen bottom, a safety net for one missed ball. The shield line pulses gently, visible but not distracting.
• Bomb — drops onto the field and destroys a radius of bricks with a large bloom explosion; the largest single-event bloom burst in the game outside of a full level clear.

Negative power-ups — some drops are adverse: narrow paddle, fast ball, ball reversal. The player must read the falling item's bloom colour and avoid it if it is harmful. The bloom colour vocabulary makes avoidance possible at game speed.

Level completion

When the last destructible brick is cleared, a level completion bloom wave radiates from the final brick position, sweeping across the empty field in ~12 frames. The Copper fires a brief full-field colour flash. Then the next level's brick formation fades in via the tilemap hardware — new bricks appearing tile by tile in an inward-spiral or cascade pattern.

The Copper for field atmosphere

Each level set has a Copper ambient colour character — not just the background colour but the ambient tint across the entire field. Early levels are warm and bright. Mid-game levels have cooler, more alien colour temperatures. Late levels are darker with more vivid brick bloom colours fighting against the ambient. The Copper drives this atmosphere completely independently of the game logic.

Audio

Brick impacts use a short, sharp FM percussion event tuned to the brick's row position — higher rows produce a slightly higher-pitched impact, lower rows slightly lower. This is not a deliberate musical system but the emergent effect is that a ball moving through the field produces a pitched sequence as it travels. The paddle hit is a distinct duller impact. The wall bounces are briefer, sharper. Power-up collection uses a brief ascending FM sting specific to the power-up type — the player learns the audio vocabulary and can partially identify power-ups by their collection sound. Multi-ball activation uses the most dramatic sting, appropriate to its visual impact. Level completion uses a short synthesised fanfare.

Match 3 Martians!

Original game: Deluxe Pixel Limited Genre: Chain-linking puzzle — draw strings through a grid to connect matching items Ant64 version: Hardware sprite grid, bloom chain trails, length-scaled destruction

Match 3 Martians is a grid-linking game rather than a falling-piece match-3. The player draws a continuous chain through adjacent matching items in the grid — the longer the chain, the better the score and the more spectacular the effect. Chains must be continuous paths through adjacent (including diagonal) matching items; the player traces the path with the jog dial or cursor, and the chain commits on release.

The mechanic combines elements from games like Puzzle Bobble's chain logic, Pokémon Puzzle League's linking, and chain-based mobile puzzlers — but with the Ant64's hardware making the chain itself a visual event.

The chain

As the player traces through matching items, each connected item in the growing chain is highlighted. The highlight is a bloom halo that intensifies with each additional link — a 3-item chain glows modestly; a 10-item chain is blazing. The chain path between linked items renders as a blit.line_bloom connecting line in the Martian's colour, updated in real time as the player extends the path. The chain is literally drawn in bloom light across the grid.

A long chain becomes a visually complex structure — a glowing path threading through the grid, each node pulsing, the connecting lines bright, the whole formation anticipating the moment of release.

The commit burst

When the chain is released and committed, all linked items clear simultaneously. Rather than a uniform burst, the bloom explosion cascades along the chain path in sequence — from the first linked item to the last — at a speed proportional to chain length. A 3-link chain clears in 3 frames. A 15-link chain produces a bloom wave that travels visibly along the entire path over ~6 frames before all items disappear. The longer the chain, the more the destruction is an event rather than an instant.

After the cascade, a final convergent burst fires: particles from all cleared positions travel toward the chain's centroid and collide in a single concentrated bloom flash. This is the payoff for a long chain — a visual culmination that is physically proportional to the effort.

Chain length rewards

The bloom intensity of the commit burst scales directly with chain length:

• 3 items: standard burst, Martian green
• 5–7 items: brighter burst, slight Copper colour temperature shift
• 8–11 items: large burst, Copper fires a brief field-wide tint in the Martian colour
• 12–15 items: full sustained bloom event, blit.line_bloom arcs radiating from the centroid, Copper full-field flash
• 16+ items: the board-wide celebration normally reserved for level completion, triggered mid-level. Earning this in play is the game's highest visual reward.

Grid refill

When items clear, new Martians drop in from above (or slide from the sides, depending on the level variant). New items arrive with a brief spawn bloom — each new item appearing with a small pop of light before settling to its idle halo. The grid is always alive, always slightly glowing.

HAM24 backgrounds — each level set has a HAM24 background showing the Martian landscape at that story location. The grid sits over a photographic-quality alien environment — a presentation depth the genre has not had on any previous platform.

Level types — the chain mechanic supports several level variants:

• Clear to target: clear a set number of specific Martian types
• Score target: reach a score within a move limit — rewards long chains
• Timed: maximise score before the clock; rewards fast chain identification
• Obstacle: some grid positions are blocked by rocks or ice that require adjacent chains to clear before the underlying Martian is accessible

Rainbow 2048

Original game: Deluxe Pixel Limited Genre: Puzzle — colourful 2048 variant (no numbers) Ant64 version: Hardware tiles, Copper colour progression, bloom merge effects

"A colourful 2048 for those that don't like numbers" — the tiles slide and merge by colour rather than number. The 2048 mechanic is the same; the presentation is chromatic rather than numeric.

Tile colours and the Copper — each tile value corresponds to a specific hue. The Copper palette cycling system drives the tiles' exact shade rather than hardcoded palette entries — the colours are live, breathing, shifting slowly through the game. Two tiles of the same value have perfectly matching hues because both read from the same Copper palette entry.

The merge — when two tiles merge, a brief intense bloom at the merged position in the new tile's colour, scaling with the value of the merge — a 512-tile merge produces a significantly more impressive bloom event than a 4-tile merge. Reaching 2048 (or whatever the win condition is) produces the full level-completion bloom celebration: pulsing Copper colour cycling at maximum rate, board-wide bloom burst, a hold on the final colour.

The near-full board — as the board fills, the ambient light of the HAM24 background shifts to reflect the accumulated tile density. A near-full board is visually tenser and slightly warmer than a sparse board. The Copper ambient tracks tile count — purely atmospheric, no UI required.

Sudoku Challenge

Original game: Deluxe Pixel Limited Genre: Puzzle — single/multiplayer Sudoku Ant64 version: Clean AntOS UI with bloom completion effects

"The best single/multiplayer Sudoku game in the World!" — a bold claim that the Ant64 can support with one specific hardware feature: the multiplayer dimension.

The UI — Sudoku is primarily a number-placement puzzle. The AntOS terminal rendering system provides a clean, precise grid layout at the Hires text resolution. The grid lines are sharp. The numbers are clear. No visual noise.

Correct placement feedback — when a correct number is placed, a brief bloom flash at the cell position in a neutral white-gold colour. The feedback is immediate and satisfying without being distracting. Wrong placements (if the game allows them) produce no bloom — silence from the effects system communicates the error.

Completion — a completed Sudoku grid produces a wave bloom: cells light up in a spiral pattern from the last placed number outward, reaching every cell in ~20 frames. The completed grid glows briefly then settles to a steady gentle bloom on all cells, the completed state held until the player moves on.

Two-player race — the multiplayer mode of Sudoku Challenge on the Ant64 is a Colony Connection head-to-head: two players on separate machines racing to complete the same puzzle. Each player's progress is invisible to the other. When one player completes, their machine sends the completion event over the connection — the winning player's display fires the completion bloom wave; the losing player's display fires a different, more subdued event. No shared screen required.

Integrated Editors — ImGui Hardware Rendering Layer

Every game in this collection ships with an integrated level and data editor accessible via the FireStorm ImGui hardware rendering layer. This is not a separate desktop tool or a PC companion application — it is a native Ant64 editor that overlays the live running game on the same hardware.

The Architecture

The FireStorm ImGui layer is a dedicated compositor pass that sits above the full game rendering pipeline. It renders ImGui draw lists directly in hardware — panels, widgets, sliders, colour pickers, node graphs — at zero cost to the underlying game frame. The game continues running at full frame rate behind the editor. A single jog dial press (or keyboard shortcut in the simulator) toggles the ImGui layer in and out.

This produces the defining property of the Ant64 editor system: you are always editing against the real hardware output. A bloom intensity slider in the editor updates the live bloom system and you see the change on the actual display — not a preview render, not a simulation, the physical hardware output at that moment. A torch position dragged in the dungeon editor is immediately lit by the actual Copper/bloom system. A wave formation adjusted in the shmup editor spawns against the actual sprite layer.

The editor is Luau-scripted using the imgui module, which maps to the hardware ImGui renderer via the same FFI mechanism as all other AntOS system modules. Each game registers its editor nodes at startup; the editor host instantiates them. Adding a new editor panel to any game is a Luau function that calls imgui.begin(), widget calls, and imgui.end().

Shared Editor Infrastructure

All games share a common set of editor nodes provided by the AntOS editor host:

Scene Inspector — lists all active hardware sprites, their positions, animation frames, scale, and bloom parameters. Click any entry to select it; drag in the scene view to reposition. Changes write back to the game's entity table immediately. The inspector shows the live state — if an enemy is moving, its position in the inspector updates in real time while selected.

Bloom Editor — a dedicated panel for the bloom particle system. Lists all active bloom emitters in the scene: position, colour, intensity, radius, decay rate, particle count. Each parameter has a slider with live feedback. The bloom editor is the most immediate demonstration of the editing-against- hardware approach: slide the intensity of a torch emitter and the warm glow on the surrounding dungeon tiles updates in the same frame.

Copper Editor — exposes the current Copper command list as an editable timeline. Each command entry (palette write, scanline offset, ambient level, etc.) can be adjusted with the hardware effect visible immediately. For games with significant Copper usage (racing games, platform games with area tinting) this is where the visual atmosphere is tuned.

Audio Node Editor — a node graph view of the current audio patch routing: VA oscillator nodes, filter nodes, envelope nodes, FDN reverb, BBD chorus, output mixer. Connecting and disconnecting nodes updates the running audio synthesis. The audio node editor is the same architecture as a modular synthesiser patch editor — it is a modular synthesiser patch editor, because the audio system is a modular synthesiser.

Environmental DSP Selector — a panel showing the current environmental DSP preset with per-parameter sliders. Slide the reverb tail time and the game audio changes immediately. This is where "does this cave sound like a small chamber or a cathedral?" gets answered in the actual running game.

DBFS Browser — the AntOS database file system browser, integrated into the editor. Lists all save files, level data files, and configuration data for the current game. Load, save, duplicate, rename — without leaving the game's editor overlay.

Per-Game Editor Nodes

Beyond the shared infrastructure, each game registers editor nodes specific to its content type:

Dungeons — Level Editor

The most fully featured editor in the collection. A complete room and dungeon authoring environment for the Gauntlet-style game — the same tool used to create the shipped levels.

Tilemap Painter — the tilemap layer renders live in the background. The editor overlays a grid with tile palette: floor, wall, indestructible wall, exit tile, pit, water, lava, trap. Paint by clicking and dragging. Changes write directly to the live tilemap hardware — the dungeon updates as you paint. Undo/redo buffer of 64 operations.

Generator Placer — drag generator objects onto the map: ghost, grunt, demon, lobber, sorcerer generators. Each placed generator immediately emits its characteristic bloom pulse in the running hardware — the colour of the spawn type is visible as you place. Set the generator's health (hit points to destroy it) and spawn rate via the properties panel.

Light Source Placer — place torches, braziers, and magical light sources. Each source emits its bloom immediately on placement. Adjust intensity, colour temperature, and flicker rate while selected. The dungeon is lit by the actual bloom system as you author it.

Loot Placer — place food, keys, potions, treasure. Each item type renders with its characteristic bloom halo. Food density is a level design parameter: more food makes the level more survivable; sparser food increases the attrition pressure. Set item respawn timers where appropriate.

Room Graph Editor — a node graph showing the dungeon's room structure: rooms as nodes, doorways as edges, key-lock relationships shown as coloured connections. Navigate to any room by double-clicking its node. The graph makes the dungeon's structure legible and lets the designer plan key placement against the expected player path.

Spawn Wave Editor — beyond the generators, define scripted wave events: specific enemy counts spawning simultaneously at a trigger condition (player enters a zone, a generator is destroyed, time elapsed). Wave events create the Gauntlet sense of escalation within a room.

Player Start Placer — set the four player start positions (Warrior, Valkyrie, Wizard, Elf) with facing direction. Preview the starting room state at all four simultaneous character bloom halos.

RetroStar — Sector and Mission Editor

Galactic Map Editor — the sector grid shown as a node graph. Click to place enemy fleets, starbases, and debris fields in sectors. The map renders live using the Copper scanner system — placed fleets appear as red bloom points, starbases as blue, immediately visible in the scanner display. Set fleet strength (number of ships per sector), fleet movement behaviour (aggressive toward starbases, defensive, patrolling), and initial positions.

Fleet AI Editor — per-fleet parameters: movement rate (sectors per game cycle), target priority (nearest starbase, player sector, random), aggression level. A simulation button runs the fleet AI for 10 cycles without player input, animating the bloom points moving across the galactic map so the designer can verify that the strategic pressure pattern produces the intended experience.

Sector Content Editor — within a sector, place asteroid fields (density and distribution), debris, and the specific enemy ship compositions the player will face. Enemy ship types have distinct wireframe geometries — set per encounter which types appear and in what numbers.

Weapon and Physics Tuner — torpedo speed, laser energy drain rate, shield recharge rate, hyperspace energy cost per sector distance. All as sliders against the live combat scene. Test fire from the cockpit view with a button.

HUD and Copper Editor — adjust the cockpit HUD layout: energy bar position and colour, shield bar, weapon mode indicator. The Copper editor exposes the scanner sweep parameters: scan rate, grid line bloom intensity, fleet point bloom colour and pulse rate. Changes to the scanner appearance update the live galactic map display immediately.

Zombie Rocks!

Level Layout Editor — top-down view of the current arena. Place walls, obstacles, brain spawn points, hazard zones. The atmospheric lighting from the bloom system — the zombie's personal glow, the graveyard torches — is live behind the editor overlay.

Enemy Wave Editor — configure which enemy types appear, their spawn rate, and the escalation curve. A graph shows enemy density over time for the current configuration. Adjust the curve and the projected density updates immediately.

Atmosphere Tuner — sliders for the Copper ambient colour temperature, bloom intensity on the zombie character, brain pickup glow colour. This is pure atmosphere tuning — all parameters exposed and live.

Zombies! — Level Editor

Terrain Painter — the level terrain is a tilemap; paint earth, steel, water, trap, and exit tiles. The terrain renders live behind the editor. Destructible earth is visually distinct from indestructible steel — the editor tile palette matches the in-game visual exactly.

Entrance and Exit Placer — set the zombie entrance point, entrance rate (zombies per second), total zombie count, and the exit position. The entrance and exit bloom markers are visible immediately in the live scene.

Object Placer — place pre-existing obstacles, hazards, and bridges. Each object type renders with its in-game appearance and bloom state immediately.

Save Target Editor — set the minimum save percentage required for level completion, and the maximum achievable count. The tension between "you must save at least X" and "you can only save Y at most" is a level design parameter.

Ability Allocator — set the ability counts available to the player for this level: how many Blockers, Diggers, Bashers, Builders, Floaters, Climbers, Exploders. The allocation defines the puzzle solution space. Too many abilities makes the level trivial; too few makes it impossible. A solution validator button tests whether a known solution path works with the current terrain and ability counts.

Playthrough Recorder — record a complete playthrough of the level within the editor to verify solvability. The recording can be played back to show the intended solution.

Zombie Rocks! — Level Editor

Cave Grid Editor — paint the cave: earth, empty space, indestructible wall, rock (placed), brain, exit tile, firefly, butterfly, undead. Rocks placed in the editor follow the physics simulation immediately — if you place a rock above empty space, it falls in the live game. The cave physics is active behind the editor overlay.

Brain Count and Exit Trigger — set how many brains must be collected before the exit opens, and the time limit for the level. The tension between "collect enough" and "don't get crushed while doing it" is the design parameter.

Enemy Placement — place initial enemy positions and set their roam behaviour parameters. A physics preview button runs the level from the start state for 5 seconds to show early rock-fall patterns without player input — useful for verifying that the initial rock configuration doesn't immediately create an unwinnable state.

Difficulty Tuner — time limit, brain target count, initial enemy count, and the rock density slider (ratio of rock tiles to earth tiles in a generated section). Higher rock density means more physics interaction — more danger and more opportunity to use falling rocks as weapons.

Footy Manager — Pitch and Physics Editor

Ball Physics Tuner — the most important editor panel in the game. Ball speed, friction decay rate, aftertouch curl strength, bounce coefficient off posts and players, spin transfer on player contact. Every parameter as a slider against the live running match. The feel of the ball is entirely in these parameters — this is where Kick Off becomes Sensible Soccer or neither. Adjust and play immediately; the ball responds in the same frame.

Player AI Tuner — per-position AI parameters: closing speed, tackle aggression, positioning tendency (wide, central, forward-pressing). The AI behaviour updates in the live running match as sliders are adjusted. Useful for tuning the opponent difficulty without leaving the game.

Formation Editor — 11 drag-points on a top-down pitch diagram, each representing a player's nominal position. Drag to set formation shape. The formation is also accessible mid-match via a pause — the manager overlay appears over the frozen pitch, allowing tactical adjustment between passages of play.

Pitch Editor — select pitch condition (firm, soft, wet, muddy) which adjusts ball friction and player speed parameters. Wet and muddy conditions also enable bloom splash particles from the ball on ground contact. Set the stadium HAM24 crowd background and the home team Copper colour temperature.

Crowd Audio Tuner — the granular engine parameters for crowd reaction: grain density range (quiet to roar), pitch scatter, response speed to goal and near-miss events. Play a test match and adjust the crowd's emotional character in real time.

Ping Pong DX — Level and Feel Editor

Brick Field Designer — a grid editor showing the current level's brick layout. Click to place brick types: standard, reinforced, indestructible, explosive, invisible. The placed bricks appear immediately in the live tilemap hardware behind the editor overlay. The bloom halos on explosive bricks and the absence of tile for invisible bricks are visible in the live game as you author the layout. Copy/paste rows and columns; fill region; mirror horizontally or vertically. Save and load named layouts to the DBFS.

Brick Type Properties — select a brick type to edit its hit points, point value, power-up drop probability table (each brick type has a weighted probability for which power-up it drops), and bloom burst parameters on destruction. Adjust the explosive chain radius and delay timing; trigger a test explosion in the live field with a button press to see the cascade.

Power-up Editor — the full power-up vocabulary with per-item parameters: bloom halo colour, fall speed, paddle effect duration, ball speed multiplier for speed modifiers. A "test drop" button spawns the selected power-up in the live game immediately from the top of the field.

Physics Tuner — ball speed at level start, maximum speed ceiling, paddle size default, bounce angle spread, gravity on power-up drops. Every parameter as a slider against the live running game. The primary balance tool: play while adjusting, feel the change immediately.

Bloom Tuner — ball bloom radius at rest and at max speed, per-brick-type destruction burst intensity, laser paddle line brightness, fireball trail radius, shield line pulse rate. The bloom tuner is the visual feel editor — the entire character of the game's destruction feedback lives here.

Copper Atmosphere Editor — per-level-set ambient colour temperature, background palette, and the Copper transition behaviour between levels. Preview the full level-set atmosphere with a single button — the Copper commands fire on the live hardware to show the intended colour character of that level group.

Level Sequencer — the ordered list of levels in a level set, with drag-to-reorder. Each level entry shows its brick layout thumbnail, par time, and target score. Add, duplicate, and remove levels. The level sequencer is the top-level authoring tool — brick field layouts are children of level entries, which are children of level sets.

Match 3 Martians! — Level and Chain Editor

Grid Designer — define the starting grid configuration: item types at each position, fixed/locked cells, blocked positions (rocks, ice). The grid renders live in the hardware behind the editor; items glow with their idle bloom halos immediately. Paint cells by clicking and dragging.

Objective Editor — set the level goal: collect X of a specific Martian type, reach a score target within a move limit, survive a time limit, or clear a specific set of obstacle tiles. A preview panel shows the objective as it will appear to the player.

Chain Effect Tuner — bloom intensity per chain node at each length threshold (3, 5, 8, 12, 16+), the commit burst cascade speed, the centroid convergence burst intensity, the blit.line_bloom trail colour and width for the in-progress chain path. Trigger a simulated chain commit at any length via a button to see the burst on the live hardware.

Refill Behaviour — configure how cleared cells refill: drop from above, slide from sides, random spawn. Preview the refill animation on the live grid.

Difficulty Curve Editor — a graph of parameters over the level sequence: grid density, item variety (more types = harder to form long chains), move limit, target count. The current level's position on the curve is highlighted.

Rainbow 2048 — Colour and Merge Editor

Tile Colour Mapper — the mapping of tile values to Copper palette entries. A colour picker per tile value; changes update the live running game immediately. The full tile value sequence (2, 4, 8, 16 ... 2048) is visible as a colour ramp. Adjust any entry and all tiles of that value update on the live board.

Merge Effect Tuner — bloom intensity scaling per merge value, the maximum intensity at the 2048 merge, decay rate. A "preview merge" button triggers a test merge animation at the currently selected value on the live hardware.

Sudoku Challenge — Puzzle Generation Parameters

Puzzle Generator Controls — the Sudoku generator's parameters: minimum given count (difficulty), symmetry style, uniqueness constraint. Generate a test puzzle with the current parameters and see it rendered immediately.

Completion Effect Tuner — the wave bloom completion sequence: wave speed, bloom intensity, colour, and hold duration. Preview the completion animation on the running hardware with a single button.

Multiplayer Race Parameters — for the Colony Connection head-to-head mode: time limit (if any), hint penalties, puzzle synchronisation seed. The race parameters editor also shows a simulated race progress view.

The Editor as Demonstration

The ImGui editor layer has a secondary role beyond game content creation: it is a real-time demonstration of the hardware rendering system for anyone who wants to understand what the Ant64 is doing.

Open Dungeons. Enable the editor. Open the Bloom Editor panel. Select a torch. Slide the intensity from zero to maximum — the warm pool of light on the dungeon tiles appears and disappears as you slide. Slide the colour temperature from warm to cold — the torch becomes a ghost light. Slide the flicker rate from 0 to 30Hz — the torch becomes a strobe. Every parameter of every hardware effect is exposed, live, in the running game.

This is the Ant64's interactive technical documentation. The editor does not describe what the hardware can do — it shows it, with immediate feedback, on the physical hardware output.

Nintendo 64 — Decompiled Games

The N64 decompilation community has, over 2020–2025, produced matching source code reconstructions of the majority of the platform's landmark titles. A decompilation is a reverse-engineered recreation of the game's original C source code — byte-for-byte matching the compiled ROM when built with the same toolchain. The decompilation code itself is the community's original work; the game assets (textures, models, audio) remain Nintendo's property and are not included. An Ant64 build requires the player to supply their own legally-owned N64 ROM, from which assets are extracted at build time. Legal advice is recommended before distributing builds.

All titles in this section run as bare-metal C906 applications with FireStorm handling all rendering. The N64's RCP (Reality Co-Processor) — the RSP geometry processor and RDP triangle rasteriser — is replaced entirely by FireStorm's blitter and display pipeline. The N64's MIPS R4300i at 93.75MHz is replaced by the C906 at 1GHz. The result is native Ant64 hardware rendering of N64 game logic, not emulation.

The N64 → Ant64 Hardware Mapping

The N64's rendering pipeline is a good match for the Ant64's blitter:

RDP → FireStorm blitter — the N64's Reality Display Processor rendered textured, Z-buffered triangles with perspective-correct UV and bilinear filtering. FireStorm's blitter does the same with 24-bit colour depth, higher precision UV interpolation, and a resolution ceiling far above the N64's 320×240 native output. The same triangle submission model; the same depth buffer; better output.

RSP → C906 — the N64's Reality Signal Processor handled geometry transformation (vertex transform, clipping, lighting) and audio mixing on its MIPS vector unit. The C906 at 1GHz handles all of this on the main processor. The N64's RSP ran at 62.5MHz; the C906 at 1GHz has roughly 16× the throughput.

Draw distance and fog — N64 games used heavy distance fog to hide geometry pop-in caused by the limited RDRAM bandwidth and the RSP's transform throughput. With the C906's headroom and FireStorm's blitter bandwidth, the fog plane can be pushed substantially further. Games designed around fog as a visual element retain it; games that used fog purely as a technical crutch can have it reduced.

Resolution — N64 native was typically 320×240 (lo-res) or 640×480 (hi-res, rarely used due to performance cost). The Ant64 renders all N64 games at minimum 720p, with the increased polygon count required to fill the higher resolution handled by the C906's headroom over the original hardware.

Frame rate — many N64 games targeted 20fps, some 30fps, a few 60fps. The Ant64 targets 60fps for all titles. The C906's headroom over the R4300i means the game simulation runs faster; the blitter fills frames faster. Some games require frame rate unlocking patches (already present in most decompilation ports); others run freely at 60fps once the CPU ceiling is removed.

Audio — the N64 used the RSP for audio mixing, driving a custom sample- based synthesis system with a 64-voice limit and ADPCM-compressed samples. The Ant64 audio enhancement replaces the sample playback with the full FireStorm audio DSP: FA/FM synthesis for music tracks, the FDN reverb replacing the N64's own reverb unit, and the BBD chorus on lead voices. Sample-based SFX can remain as samples or be replaced with synthesised equivalents.

The Legend of Zelda: Ocarina of Time

Decomp: zeldaret/oot — complete Source: github.com/zeldaret/oot ROM required: N64 Ocarina of Time (various regional versions) Legal note: Nintendo IP; ROM user-supplied

One of the most complete and thoroughly documented N64 decomp projects. The code is fully named and commented; the data structures are understood. OoT is the most ported N64 game from a decomp base — PC ports with widescreen, 60fps, and HD texture packs are well established. The Ant64 version starts from this base and applies the hardware rendering system.

Rendering enhancements:

• Hyrule Field at extended draw distance: the fog ring that originally surrounded the field at close range pulls back dramatically, revealing the full geometry of the field and the distant Death Mountain. The mountain's snowcap emits a persistent cold bloom halo visible at distance.
• The Great Deku Tree's interior: darkness lit only by Navi's blue-white bloom halo and the spore particles from Gohma's egg sac. The dungeon ambient uses the cavern DSP preset with early reflections matching the tree's hollow interior volume.
• Zora's Domain waterfall: the cascade produces a sustained bloom emission at the base — the same water splash particle system as the Super Metroid waterfall sections. The ice variant (adult Link) encases the bloom in a blue-tinted static glow.
• The Temple of Time's interior: the Copper drives the stained-glass window light shafts as per-scanline bloom lines, warm gold, angled with the game's sun position.
• Din's Fire, Nayru's Love, Farore's Wind: spell casts use the full bloom particle burst system. Din's Fire is a large-radius orange-red expanding sphere of bloom particles. Nayru's Love creates a persistent crystalline bloom shield around Link — a rotating bloom line polyhedron. Farore's Wind leaves a green bloom marker at the warp point.
• The Light Arrows in the final battle: each Light Arrow is a blit.line_bloom projectile of maximum intensity, warm white, leaving a brief bloom trail. Impact on Ganon produces the largest bloom event in the game.
• Navi: her idle flight trail is a continuous stream of tiny bloom particles, blue-white, fading over 6 frames. The "Hey! Listen!" attention call fires a brief bloom burst. Navi is always visible as a bloom source regardless of screen position.

Audio: The N64 OoT soundtrack — Koji Kondo's compositions — used the N64's sample-based synthesis with custom instrument patches. The Ant64 enhanced mode routes these through the FireStorm audio DSP: the FDN reverb replaces the N64's own reverb with spatially appropriate settings per area (the vast hall of the Temple of Time, the tight reverb of a small cave), and the BBD chorus is added to the ocarina instrument voice — the ocarina is the game's central audio identity and it deserves the warmth that BBD chorus produces.

The Legend of Zelda: Majora's Mask

Decomp: zeldaret/mm — complete Source: github.com/zeldaret/mm ROM required: N64 Majora's Mask Legal note: Nintendo IP; ROM user-supplied

The darkest Zelda. The three-day cycle, the moon descending, the masks. Visually the most atmospheric N64 Zelda — and the atmospheric rendering system is exactly where the Ant64 hardware applies most directly.

Rendering enhancements:

• The moon: a large persistent bloom sphere in the sky layer, growing in radius and intensity as the three-day cycle progresses. On Day 1 the moon is a distant bloom point. By the final hours it fills a significant portion of the sky with a sickly yellow-white bloom that tints the Copper ambient of Clocktown below with its light. The approaching moon is the most direct use of bloom as a dread mechanism in the games collection.
• The Happy Mask Salesman's laugh: the Copper fires a brief desaturation at specific narrative moments. Purely atmospheric.
• Termina Field: like Hyrule Field, fog draws back to reveal the full geometry. The four cardinal regions (mountain, swamp, ocean, canyon) are visible simultaneously in clear weather. Each region emits its characteristic ambient light — the swamp has a sickly green Copper tint at distance, the snow mountain emits cold white bloom.
• The Great Bay Temple: underwater environmental DSP engages automatically on submersion. The water surface above emits a caustic bloom pattern (animated ripple bloom particles projected on the geometry below).
• Stone Tower Temple inverted: when the tower inverts, the Copper fires a full-field colour inversion event over 8 frames — the sky becomes ground and the entire colour temperature shifts as the world turns. The most dramatic single Copper event in the games collection.
• Gibdo/Redead paralysis scream: the Copper fires the desaturation event plus a brief per-scanline shockwave displacement — the scream has physical distortion. The fear is in the hardware.

Super Mario 64

Decomp: n64decomp/sm64 — complete Licence: CC0 (decompilation code) Source: github.com/n64decomp/sm64 ROM required: N64 Super Mario 64 (for assets) Legal note: Code is CC0; Nintendo assets user-supplied

The decompilation code itself is CC0 — the most permissive licence in this entire collection for a game of this significance. The assets (textures, models, audio) remain Nintendo's and are extracted from the user's ROM.

Rendering enhancements:

• Bob-omb Battlefield: the cannonballs in flight have a brief bloom trail. The cannon explosion emits a large particle burst. The Chain Chomp's stake post has a faint ground bloom at its base.
• Lethal Lava Land: lava emission bloom — the same upward particle drift and warm orange glow as the Super Metroid lava implementation. The lava casts warm light on the geometry above it via Copper ambient tinting.
• Hazy Maze Cave: cave environmental DSP preset, darkness lit by bloom point sources at toxic gas vents (sickly green) and the poison river.
• The 8 Red Coins star: each collected coin fires a bloom burst in the coin's yellow-orange colour. The star appearance — the game's iconic jingle moment — fires a full-screen bloom radiance expanding outward.
• Bowser battles: Bowser's fire breath is a sustained bloom arc. His ground shockwave is the screen-shake Copper displacement event. The arena's lava rim emits continuous warm bloom.

Widescreen and 60fps: Both are standard features of the SM64 decomp port ecosystem. The Ant64 version targets 60fps natively — the C906 has more than enough headroom over the R4300i.

GoldenEye 007

Decomp: n64decomp/goldeneye (MIT) Source: github.com/n64decomp/goldeneye ROM required: N64 GoldenEye 007 Legal note: Nintendo/Rare/MGM/Eon IP; ROM user-supplied

The game that defined console first-person shooters. The decomp is complete and MIT-licensed. A native port on the Ant64 runs at 60fps with widescreen — the two things the original hardware was famously unable to provide.

Rendering enhancements:

• Muzzle flash bloom: every weapon's muzzle produces a brief high-intensity bloom burst at the barrel position. In close quarters with multiple guards firing simultaneously, the muzzle flash bloom fills the room with strobing white-yellow light. The original game had no dynamic lighting; the Ant64 version has a fully reactive light environment driven by gunfire.
• Bullet impact sparks: every bullet impact on a metal surface produces a brief spark bloom scatter — 3–5 small bright particles radiating from the hit point. Stone impacts produce dust bloom; wood impacts produce splinter bloom at lower intensity.
• Explosion bloom: grenade and rocket launcher explosions use the full three- stage particle system. The Frigate's explosive barrels chain.
• Guard death falls: no bloom effect — the deaths are more affecting without visual embellishment.
• The Dam level: the outdoor environment uses the outdoor reverb DSP preset. The bungee jump sequence at the opening is played with the dam's full acoustic character audible.
• Facility ventilation shafts: the tight metal space uses the metal pipe DSP preset — the same narrow resonant echo applied to tunnel sections in other games.
• The multiplayer modes: Colony Connection supports four-player split-screen with each player's display on a separate machine at full resolution, rather than the quartered 320×240 of the original. Four machines, four displays, one game state, sub-millisecond latency.

Perfect Dark

Decomp: n64decomp/perfect_dark (MIT) Source: github.com/n64decomp/perfect_dark ROM required: N64 Perfect Dark Legal note: Rare/Nintendo IP; ROM user-supplied

GoldenEye's successor. More complex geometry, more ambitious AI, a full campaign with cutscenes. The decomp is MIT-licensed and complete.

All the GoldenEye rendering enhancements apply. Additional:

• The DataDyne building's glass and chrome surfaces: reflective bloom highlights on curved geometry — specular bloom point placed at the camera- relative reflection position each frame.
• Alien technology weapons: the Farsight XR-20's targeting system uses a blit.line_bloom sight line to the locked target — a thin sustained beam across any distance, visible through walls. The CMP150 simultaneous burst fires three parallel bloom traces.
• The Carrington Institute hub world: a large indoor environment where ambient bloom from equipment and displays creates the sense of an active facility. Each terminal and display surface emits low-level bloom.
• Simulant AI: Perfect Dark's deep Simulant difficulty levels and complex AI behaviour has room to breathe at the C906's processing headroom. The original hardware frequently dropped frames in complex scenes; the Ant64 version holds 60fps through the most complex combat scenarios.

Mario Kart 64

Decomp: Complete (reached 100% May 2025) Source: github.com/n64decomp/mk64 ROM required: N64 Mario Kart 64 Legal note: Nintendo IP; ROM user-supplied

Five years of work reaching completion in May 2025. The racing game complement to the Ant64's original racing game section — Mario Kart 64 is the N64's top-down kart racer, and the hardware treatment follows the SuperTuxKart model with N64-specific enhancements.

Rendering enhancements:

• The kart boost pad arrows: each activated boost pad fires a brief forward-pointing bloom burst in the pad's colour as the kart crosses it.
• Item effects — all the SuperTuxKart bloom vocabulary applies: lightning bolt hit flash, star invincibility orbit, blue shell explosion.
• Rainbow Road: the bloom additive blending system makes Rainbow Road the most visually spectacular track. The road's rainbow segments are bloom- emitting surfaces; a full field of karts at maximum speed on Rainbow Road at night is a bloom particle light display. The stars in the background layer are HAM24 deep-sky quality rather than the N64's flat starfield.
• Track draw distance: the N64's limited RDRAM meant Toad's Turnpike's oncoming traffic appeared from close range. Extended draw distance lets oncoming vehicles appear from further away with scale perspective.
• 60fps: Mario Kart 64 targeted 30fps. At 60fps the kart handling's input latency halves — the game feels substantially more precise.

Banjo-Kazooie

Decomp: n64decomp/banjo-kazooie — complete Source: github.com/n64decomp/banjo-kazooie ROM required: N64 Banjo-Kazooie Legal note: Rare/Microsoft IP; ROM user-supplied

Rare's 3D platformer — the bear and the bird. One of the most beloved N64 games and one of the most complete decomps.

Rendering enhancements:

• Jinjo world markers: each Jinjo has a small persistent bloom point above its head in its characteristic colour, readable across the level.
• Mumbo's transformation magic: the transformation spell fires a full bloom particle burst in Mumbo's skull-and-bone colour palette — the most dramatic single-spell visual event in the game.
• Gruntilda's lair: extensive atmospheric lighting via the dungeon bloom system. Each torch, cauldron, and glowing crystal emits characteristic bloom. The lair shifts colour temperature as the player descends — warmer near surface, colder and more purple in the deep sections.
• Treasure Trove Cove underwater: the underwater DSP preset engages on submersion. The sand has a warm caustic bloom pattern.
• The Rusty Bucket Bay engine room: industrial bloom sources — steam vents, engine exhausts, warning lights. The confined metal space uses the metal pipe DSP preset.
• Notes and Jiggies: each collected note fires a bloom burst in the note's colour. Jigsaw piece collection fires the largest bloom event — the Jiggy dance sequence accompanied by a full particle celebration.

Star Fox 64

Decomp / Recomp: Complete; Starfox64Recomp available Source: github.com/sonicdcer/Starfox64Recomp ROM required: N64 Star Fox 64 Legal note: Nintendo IP; ROM user-supplied

The all-range and on-rails space shooter. The Ant64 hardware match is direct — Star Fox 64's polygon space combat maps to the same rendering pipeline as RetroStar's wireframe/polygon modes, and the bloom system enhances the weapon and explosion vocabulary that defines the game.

Rendering enhancements:

• Laser bolts: blit.line_bloom in the Fox team's characteristic green, the Andross fleet's red. Additive accumulation on near-misses. In dense combat with multiple friendly and enemy lasers crossing, the bloom accumulation creates a genuinely intense visual space.
• Explosions: the three-stage particle system (core flash, debris cloud, expanding wireframe sphere) applied to all ship destructions. Wingmate deaths use a distinct, more sombre bloom event — brief, red-tinted, no debris spray. The gameplay communicates the loss.
• The Great Fox: a persistent bloom presence in the HUD stages — the carrier's engine banks emit warm orange glow at distance.
• Corneria city: building surfaces reflect laser impacts with brief bloom sparks. The river below Corneria has the same caustic bloom pattern as Treasure Trove Cove.
• The boss cores: core exposure events use the same pulsing bloom intensity progression as the Vic Raider boss cores — undamaged cores are calm, near-death cores flash and pulse. The Ant64 boss language is consistent across all games.
• Barrel roll bloom: the barrel roll produces a brief rotation bloom smear around the Arwing — a motion trail that is visually distinct from straight flight and communicates the evasion manoeuvre clearly.

Paper Mario

Decomp: papermar.io — complete Source: github.com/pmret/papermario ROM required: N64 Paper Mario Legal note: Nintendo IP; ROM user-supplied

The RPG. Paper characters in a 3D world — a visual style that is immediately distinctive and maps interestingly to the Ant64's display system. The paper aesthetic is flat sprites with 3D perspective; this is exactly what the hardware sprite layer does.

Rendering enhancements:

• The paper metaphor taken seriously: each character's sprite shadow is a soft bloom circle on the ground plane below them, as if backlit. The paper edge of each character emits a very faint white bloom line — just enough to give the paper a physical presence in the 3D environment.
• Star Spirits and Star Power: each Star Spirit has a characteristic bloom colour. Star power attacks fire the most extravagant bloom events in the game — attack animations designed to feel like the full power of a wish.
• Bowser's Castle: the lava sections use the lava bloom emission. The darkness between light sources is genuine darkness via the Copper ambient system.
• The battle system: turn-based combat with bloom-enhanced attack animations. Hammer strikes produce impact bloom. Jump attacks produce landing bloom. Status effects (burn, freeze, electrify) use their characteristic bloom colours sustained for the effect duration.

N64 Games — Shared Framework

All N64 decompilation ports on the Ant64 share a common enhancement layer:

60fps target — the C906 at 1GHz runs all N64 game logic at a frame budget that the original R4300i at 93.75MHz could not sustain. All ports target 60fps with the frame rate unlocking patches already standard in the decomp port ecosystem.

Widescreen — 16:9 output is standard. Widescreen patches are a first addition to every decomp port project. The Ant64 HDMI output is natively widescreen; no letterboxing.

Draw distance — fog plane pushed back by a configurable factor (default 2×, up to 4×). Games that used fog as pure technical crutch benefit the most. Games where fog is intentional atmosphere (Majora's Mask's clock-tower fog, GoldenEye's outdoor environments) retain appropriate defaults.

Environmental DSP — every enclosed space in every N64 game applies the appropriate DSP preset automatically, triggered by the area transition events already present in the decomp code. Caves get cavern. Metal corridors get metal pipe. Underwater gets the submersion preset.

ROM requirement and legal note — all N64 titles require the player to supply their own legally-owned N64 ROM. The decompilation code is the community's work; the game assets are Nintendo's (or Rare's / other publisher's) property. Building and playing on personal hardware from a personally-owned ROM is the intended use case. Distribution of pre-built binaries with embedded assets would be infringing; distribution of the build toolchain and source code is the approach used by all these projects.

Shared Infrastructure

All games share the same underlying infrastructure:

Input handling — the big core polls the keyboard, mouse, and Pulse jog dials via DeMon. All games support jog dial navigation as an alternative to keyboard, with RGB feedback appropriate to game state.

Audio system — all games use the same FireStorm audio DSP via the same QSPI register write path. SFX augmentation, synthesis arrangement options, and environmental DSP presets are available to all games via a shared audio library.

Display system — all games use the same CRT simulation pipeline with the same named profiles. Display profile selection is a global option accessible from any game's option menu via DeMon.

Save management — save games stored in DBFS alongside AntOS data. The gossip P2P network on the little core can optionally sync save states between machines.

Network — TCP/IP on the little core handles all game multiplayer. Colony Connection (Ant64/Ant64C) provides hardware-level low-latency for same-room play.

Storage

All games and their free assets live on the 256GB internal SD card. Commercial asset files are user-supplied.

Game binaries (all, bare-metal C++):             ~50 MB
FreeDoom IWADs (with Doom — see doom doc):       ~600 MB
Taisei (all assets included, GPL):               ~500 MB
Veloren (world generator + assets):              ~2 GB
Oolite engine + replacement assets:               ~26 MB
Pioneer engine + GPL game data:                  ~240 MB
Veil (original space game, CC0):                  ~30 MB
# N64 decomps — build from ROM; sizes after asset extraction
Zelda: Ocarina of Time:                           ~64 MB ROM
Zelda: Majora's Mask:                             ~64 MB ROM
Super Mario 64:                                   ~12 MB ROM
GoldenEye 007:                                    ~64 MB ROM
Perfect Dark:                                     ~64 MB ROM
Mario Kart 64:                                    ~12 MB ROM
Banjo-Kazooie:                                    ~64 MB ROM
Star Fox 64:                                      ~16 MB ROM
Paper Mario:                                      ~40 MB ROM
Cannonball engine (GPL, user supplies ROMs):       ~5 MB
SuperTuxKart (GPL, all assets included):         ~800 MB
Sunrise Drive (original racer, CC0):              ~25 MB
Powermanga (GPL, all assets included):            ~80 MB
Vic Raider (original shmup, CC0):                 ~20 MB
The Long Dark (original platform action, CC0):    ~25 MB
Dungeons (Deluxe Pixel, native Ant64):            ~40 MB
RetroStar (Deluxe Pixel, native Ant64):           ~30 MB
Zombies! (Deluxe Pixel):                          ~15 MB
Zombie Rocks! (Deluxe Pixel):                     ~15 MB
Footy Manager (Deluxe Pixel):                     ~15 MB
Ping Pong DX (Deluxe Pixel):                       ~5 MB
Match 3 Martians! (Deluxe Pixel):                 ~20 MB
Rainbow 2048 (Deluxe Pixel):                       ~5 MB
Sudoku Challenge (Deluxe Pixel):                   ~5 MB
OpenTTD + OpenGFX + OpenSFX + OpenMSX:          ~150 MB
Armagetron Advanced (all assets):                ~50 MB
Julius engine binary:                             ~5 MB
OpenRCT2 engine binary:                          ~20 MB
OpenXcom engine binary:                           ~10 MB
Cave Story (NXEngine-evo, engine + all assets):  ~50 MB
Zelda 3 / Super Metroid / SMW engines:           ~15 MB
──────────────────────────────────────────────────────
TOTAL (excluding commercial assets):            ~3.5 GB

Commercial assets (Quake, Caesar III, RollerCoaster Tycoon 2, X-COM) are not included and are user-supplied from GOG or physical media. The 256GB SD card has essentially unlimited capacity for the games collection.

Hardware References

• FireStorm FPGA — EE, blitter, DSP pipeline, Copper, layer compositor
• Display System — isometric system, Tate mode, DDA ray cast, BSP, voxel hardware, HAM24, CRT simulation, native resolutions
• Blitter — particle lists, bloom lines, textured triangles, clip table, Mode 7, isometric rendering
• Audio System — 128-voice DSP, OPL2 emulation, environmental presets, synthesis augmentation, FDN reverb, BBD chorus
• SG2000 — big core C906 at 1GHz, TPU at 0.5 TOPS INT8
• DeMon — supervisor, input routing, display profile management
• Pulse — jog dials, RGB feedback, MIDI, Colony Connection
• Overview — full system architecture
• FreeDoom — free Doom replacement IWAD
• OpenTTD — transport simulation, GPL
• Julius — Caesar III engine, AGPL
• OpenRCT2 — RollerCoaster Tycoon 2 engine, GPL
• Armagetron Advanced — Tron light cycles, GPL
• Taisei Project — bullet hell, MIT
• Veloren — voxel RPG, GPL
• OpenXcom — X-COM engine, GPL
• NXEngine-evo / Cave Story — GPL v3, CC0 game data
• snesrev/zelda3 — A Link to the Past C reimplementation, MIT
• snesrev/sm — Super Metroid C reimplementation, MIT
• snesrev/smw — Super Mario World C reimplementation, MIT
• Oolite — Elite-style space sim, GPL v2+
• Pioneer — Frontier-style space sim, GPL v3
• zeldaret/oot — OoT decompilation
• zeldaret/mm — Majora's Mask decompilation
• n64decomp/sm64 — Super Mario 64, CC0
• n64decomp/goldeneye — GoldenEye 007, MIT
• n64decomp/perfect_dark — Perfect Dark, MIT
• n64decomp/mk64 — Mario Kart 64
• n64decomp/banjo-kazooie — Banjo-Kazooie
• Starfox64Recomp — Star Fox 64 recomp
• pmret/papermario — Paper Mario
• Cannonball — enhanced OutRun engine, C++ rewrite
• SuperTuxKart — kart racing, GPL v3
• Powermanga — vertical shmup, GPL v3