Everyone’s Retro 3D Is a PlayStation

This is the first thing to get right, because it is the thing almost every “retro 3D” shader gets wrong, and because getting it wrong makes everything downstream look like the wrong decade.

Volthaven implemented snapping first — like everyone does. Then it measured a Level 1 yaw pan and counted how many times a vertex moved backwards against the direction of the camera:

The removal had to happen in two shaders. The ticket named one file. The identical block also sat in the water material, and patching only the one named would have fixed 1 material and skipped 335. That is a lesson about tickets as much as about rasterisers.

Source

35,791lines across 81 files

Tests

359cases · 10,365 lines

Test ratio

1.20lines of test per line of game

Sectors

5each with one boss

Soundtrack

22,563 B15 pieces, 0 B of bundle

Render target

426×240short axis pinned

The rail is the whole architecture

A level is not a mesh you walk on. It is a curve. A single scalar railT describes how far along the track the player is, and world position is derived from it by sampling the curve. Gaps are ranges of railT with no floor. The camera follows the curve rather than the player. Everything — enemies, checkpoints, the flood, boss arenas — is placed by a position along that one parameter.

This is why the whole game fits in 35,791 lines. It is also why one arithmetic error in a curve length can make an entire level unreachable, which happens in Module 12.

The five abilities, as the code actually enforces them

Arc Strike       J          cost  0   ·  8-frame cooldown  ·  12 dmg  ·  reach 2.5 h x 2.0 v
Surge Dash       K          cost 15   ·  deducted  ·  12.0 rail units  ·  15 frames i-frames
Overcharge Slam  Down + J   cost 30   ·  deducted TWICE (direct + buffered hop)  ·  40 dmg
Arc Tether       L          cost  0   ·  gated on charge >= 20 and NEVER DEDUCTED
Discharge Nova   I          cost 50   ·  deducted  ·  30 dmg  ·  radius 12

Most N64 titles ran at 320×240. A few used a 640×480 high-resolution mode, usually with the expansion pak. The pixels you remember are 320×240 stretched to a television.

Volthaven does not hardcode 320×240, and the reason is worth stealing:

constructor   target created at 320 x 240
resize()      overwrites it — only the SHORT axis stays 240

    16:9 window   ->  426 x 240
    4:3  window   ->  320 x 240
    portrait      ->  240 x 520

Hardcode 320×240 on a 16:9 display and you must either letterbox or stretch. Stretching gives you non-square pixels, which reads as a bad emulator rather than as a console. Pinning the short axis keeps every pixel square at every aspect ratio, and the cost is that a widescreen player sees more of the level than a 1998 player would.

The upscale is one CSS property, and it is the property that does the most visible work in the entire codebase:

imageRendering: 'pixelated'

The default browser behaviour when scaling a canvas up is bilinear smoothing. That turns a crisp 426×240 image into a blurry mess and undoes every other technique on this page. pixelated makes each source pixel a hard square.

Quantisation happens once, at the end, in the blit shader. Not per material — if you quantise per material you get different banding on overlapping surfaces and the illusion falls apart at every intersection.

c.r = floor(c.r * 31.0 + 0.5) / 31.0;   // 5 bits — 32 levels
c.g = floor(c.g * 63.0 + 0.5) / 63.0;   // 6 bits — 64 levels
c.b = floor(c.b * 31.0 + 0.5) / 31.0;   // 5 bits — 32 levels

Those multipliers are 5-6-5. So the implementation matches the comments, and both are the wrong console’s format. Green gets 64 levels where the hardware gave it 32.

Find the other three

Colour is not the only place this codebase says one thing and does another. Three rounds below, each a real inspection from the render layer. Every listed line is real, and in each round exactly one is not doing what it appears to do.

  0   8   2  10
 12   4  14   6
  3  11   1   9
 15   7  13   5        / 16.0  ->  offset added before floor()

The detail almost everyone gets wrong

The matrix is indexed by the source texel, not by gl_FragCoord.

Index by screen position and the dither pattern is fixed to the display. Move the camera and every surface appears to swim through a stationary checkerboard — the pattern crawls. Index by the texel and the pattern is attached to the surface, so it moves with the geometry the way a real texture would.

The project verified the result the only way that means anything: it counted 4×4 screen blocks that were not uniform after quantisation, and got 0 of 76,800. Every block on screen resolves to a single quantised value, which is what tells you the grid survived the whole pipeline intact.

The baker evaluates a five-term model per vertex — not a single dot product. The terms give you something that reads as lit rather than merely shaded, and because it costs nothing at runtime you can afford to be generous with geometry.

That last point is the real payoff. Volthaven's levels carry a great deal of decor — pillars, gantries, kerbs, lamps — and none of it costs anything to light. On hardware with a real-time lighting budget you would have to choose. Here the choice is made once, at build time, and the budget at runtime is zero.

Unlit basic material N64 material + bake + fog

Unlit Lit

Four kilobytes means a 16-bit texture of roughly 32×64 in one load, and four-bit 64×64 textures were common. Volthaven generates its textures procedurally at 64×64 in JavaScript rather than shipping image files, which keeps the constraint explicit and the bundle empty.

Filtering is the second wrong-console mistake

This one is nearly as common as vertex snapping, and it comes from the same instinct: retro means pixels, so make the texels sharp.

The N64 applied three-point filtering and mipmapping. Its textures looked blurry. The pixelation you remember is the framebuffer being upscaled — it is not the texture. Sharp nearest-neighbour texels on a low-poly model is a PlayStation and PC look.

far-field shimmer      11.7x lower with trilinear filtering + mipmaps

why: a 64x64 texture on a distant surface samples far apart in UV space;
     without mipmaps consecutive frames grab unrelated texels and the
     surface boils. Mipmaps pre-average; trilinear blends between levels.

Two techniques in this class pull in opposite directions and both are correct: nearest-neighbour on the final blit, so the framebuffer grid survives to the display, and trilinear on the textures, so surfaces do not boil. Getting these the wrong way round is the most common way to build something that looks retro in a screenshot and wrong in motion.

N64 or PlayStation?

Six techniques below. Some belong to the machine this game is imitating. Some belong to a different one, or to the television it was plugged into. Call each before you reveal it.

3 layered fog bands        near / mid / far, each with its own colour and curve
sky dome                   so the far plane never shows as an edge
near / far plane           0.1 / 100 — the far plane is LOCKED
arithmetic pop guard       geometry fades to fog before it crosses the plane

The far plane stays fixed and the fog adapts to it, rather than the other way round. That ordering matters: a moving far plane changes your depth-buffer precision as you play, and z-fighting that appears only in some rooms is among the least pleasant bugs to chase.

With near at 0.1 and far at 100, the depth buffer has a workable distribution. Push near down to 0.01 to stop clipping something close to the camera and you spend precision you cannot get back — distant coplanar surfaces start flickering. The near plane is a budget, not a convenience.

That trade is the whole lesson. A soft glow spends screen area to say “something happened.” A hard shape with real contrast says it in less room and reads instantly at 240 lines, which is the resolution the player is actually looking at.

The art programme, measured

Every art ticket in this project had to prove its effect with a rendered pixel or a timed frame. Seven of those measurements are below. Judge each one: does the number actually support the claim it was filed under?

Delta time is the modern default and it is usually right. It keeps a game feeling the same on a 60 Hz laptop and a 144 Hz monitor. It also makes your game a floating-point simulation whose outcome depends on the exact frame times of the machine it ran on.

Frame counting gives you the opposite trade:

ARC_STRIKE_COOLDOWN_FRAMES = 8       an integer, not 133 milliseconds
boss phase durations                 240f, 600f, 120f — exact, reproducible
telegraph windows                    counted, so a test can assert them exactly

BUYS   a headless test can run 3,000 frames and get the same result every time
COSTS  the game is tied to its tick rate; a different rate is a different game

The payoff shows up in Module 12. A test suite that can drive thousands of deterministic frames is what makes it possible to say “the player was within horizontal reach for 44 frames and vertical reach for 1,966, and within both simultaneously for zero” — a sentence that is meaningless if every run produces different numbers.

The N64 is the interesting case here. It had no dedicated sound chip at all. Audio ran on the Reality Signal Processor as a microcode task, competing directly with graphics for the same silicon. Every voice you played was frame time you did not spend rendering. That is the constraint the design is answering.

Instruments

11synthesised in JS

Sample rate

22,050Hz, 4-bit quantised

Packed

22,563 B0 B of bundle

Voices

24quietest-then-oldest stealing

Pieces

15all 32 beats

Effects

23also sequencer tracks

The loop is bit-exact, not crossfaded

This is the best idea in the audio system and it generalises far beyond games.

Most looping audio is faded: play to the end, crossfade into the start, hope nobody notices. Volthaven inverts the problem. It picks the loop length first, then constrains every partial in every instrument to an integer multiple of rate / L. Every sine component therefore completes a whole number of cycles across the loop, so the final sample joins the first at a zero crossing by construction. There is no seam to hide.

Attacks are built the same way — the identical additive summation, run at negative frame indices — so the attack transient is part of one continuous function rather than an envelope spliced onto the front.

The sound effects are music

All 23 effects are sequencer tracks on the same instrument bank, on dedicated channels, authored in milliseconds at a fixed 120 BPM so that changing the music tempo cannot drag them. One synthesis path, one voice pool, one bus. Nothing in the game plays a sample file.

Trace the chain

Below is the actual signal path from a synthesised instrument to your speakers. Click any highlighted line to see what it does and what breaks if it is missing.

Silhouette first, everything else second

The same discipline applies to the ordinary enemies, and the numbers there are more extreme:

The cone is the instructive one. Measured by perimeter squared over area, it scored 31.6 from the front and 31.5 in profile — nearly identical, because a cone of revolution looks the same from every angle. After redesign the same enemy measures 609.0 front and 707.7 in profile. An enemy that reads identically from all sides gives the player no information about which way it is facing, which at this resolution is most of what they have to go on.

The five fights, in one table

One · The flood nobody could outrun

water rise    0.25      units per frame   (original)
player climb  0.0135    units per frame   (maximum, measured)

              18.5x faster than the fastest possible ascent

after         0.01681   units per frame

Level 3 was unwinnable at any skill level for the entire history of the project. Not hard — impossible. No amount of play could produce a win, and nothing crashed, logged, or failed. It took a headless bot running the level deterministically and a test that asserted completion to surface it.

Two · The boss nobody could hit

Aeros finished ten consecutive naive campaign runs on 550 of 550 HP. Never scratched.

frames the player was within HORIZONTAL melee reach      44
frames the player was within VERTICAL melee reach     1,966
frames within BOTH at the same time                       0

Each axis looked fine on its own. Either measurement alone would have closed the ticket. The bug only exists in the intersection, which is exactly the shape of defect a human playtester reports as “the boss feels weird” and cannot localise.

Three · The enemy that followed you into the wrong fight

deaths caused where it stood                     0
damage dealt after following the player into
the Ascendant's arena                          555   (5x the boss itself)

deleting that ONE spawn:   Level 5 completion   3/10  ->  10/10

Zero deaths where it was placed. It was not a hard enemy. It was an enemy in the wrong place at the wrong time, and it was doing five times the damage of the final boss during the final boss fight.

Play Volthaven 64