VIRTUAL RED SHIFT private beta

Virtual Red Shift · how it's made

Counted, not estimated

This port was built with an AI coding assistant. That invites an assumption: that someone typed a prompt and the game appeared. This page is the record of what happened instead, read from the git history and the session logs by a script that runs every time the site is rebuilt.

Built from Terry Cavanagh's source

VVVVVV is Terry Cavanagh's game. In 2020 he published its source code "for others to learn from, to inspire new work". This port exists because of that: it reads the game's logic from that source -- his game, as carried to C++ by Simon Roth and to SDL2 by Ethan Lee -- and takes his level data -- the room layouts, where every entity stands, the text of every scene. The rooms you play are his rooms.

What it does not take: the art, the music and the sound, which are not part of the published source and stay his and Magnus Pålsson's. Every graphic is redrawn for a 384 by 224 screen in four shades of red; the port plays sixteen original chiptune tracks. The Virtual Boy adds one thing the original never had: depth.

VVVVVV is still for sale at thelettervsixtim.es, with the art and the soundtrack this port does not have.

Checked against the original

The original runs its logic at 29.41 frames per second; the Virtual Boy runs at 50, so speeds, accelerations and delays are converted from the original values in 8.8 fixed point. 28 purpose-built checks compare the port with the published source; on 2026-09-26, 26 passed and 2 failed (an epilogue token still drawn with a placeholder, and one final-level announcement). What the passing checks establish:

• The player's collision box (12 by 21 pixels) and walking-animation cadence are read from the original source and match.
• Gravity, terminal fall speed, vertical friction and top running speed are the original values converted; the worst rounding is 0.64 %, and a 240-pixel fall drifts by 0.07 of a pixel. Walking acceleration and stopping do not yet follow the original's model: the port starts and stops faster.
• All 418 room layouts of the five zones come from the level data, and no room's collision differs from the original.
• 163 moving enemies and platforms, simulated over 1,500 original frames, stay within one step of the original paths; the 20 wrap-around rooms match frame by frame.
• The 204 checkpoints respawn at the original spot and orientation; the 16 teleport tokens and the 35 scripted room jumps lead where the original sends them.
• The Super Gravitron's 27 wave states are transcribed with the original delays and spawns; about one spawn in twenty is dropped for lack of sprite slots.
• All 158 scripts and the original's 473 dialogue boxes are converted; 47 scripts play in the game so far, and the crew conversations cannot be started yet.
• Death timing, and the trinket, save and ending texts, come from the original, letter by letter.

What these checks do not do: they read data and code, not the game running. That part is the tester's, below, and the console's.

The record

Measured on 2026-09-26, by the rules written in the measuring script.

These sessions ran next to other projects, so the logs are mixed. Nothing is guessed: a command counts for the port only when it ran in the port's folder or named its files, and a prompt only when the work it started did. Session time is the sum of the gaps shorter than ten minutes between those events, watched or not; the hours more than an hour after a person's last message are the loop working alone.

Where the work went

Every program the assistant ran for the port, by what it was. These are floors: a run that names no project is not counted.

For every build, about 7 programs checked the game: audits, auto-player runs and keyboard sessions together. In git, more commits touch the checks (417) than the game itself (369).

Six roles

The assistant worked from six written briefs, one per role, 3,972 lines in all. Their content stays private.

The tester at work

The game is played by an automatic player: an emulator started minimised, with no keyboard and no window focus, told which room to start in and how many frames to play, writing what happened to its save memory. Several run side by side, faster than real time.

These are floors: the long runs of the nights went to the background, and a run does not always name its length. Every room of the game prints a four-character code, so a run -- or a tester -- can report exactly where something broke.

The loop, in one picture

The gate

The plan lives in one file, rewritten rather than appended: the history shows it replaced 163 times. The verdict lives in another, rewritten 37 times, and 32 of those verdicts passed a build. The flashing script reads the verdict and refuses any ROM whose fingerprint it does not carry: of its 30 runs, 23 wrote a ROM to the cartridge.

What we will not claim

It is tempting to say this would have taken years by hand. Nobody built this port without the assistant, so there is no way to know, and a multiplier invented for a page like this would be exactly the kind of number it argues against. The level design, the characters, the story and the rules are Terry Cavanagh's; the port's job was to carry them to a different machine without losing them.

The part that is not automated

No emulator reproduces how a Virtual Boy feels: the red, the depth, whether a spike stays readable against a bright wall. So the ROM was written 23 times to a real cartridge, for a person to play on the console. Two depth ideas were dropped after that kind of test.

To start your own: VUEngine, Mednafen, the Planet Virtual Boy development forum, a flash cartridge. Questions about this port: the forum thread.