The first ports could read code but missed the movement.
Priyan Rajeevan describes a series of AI-assisted attempts to rebuild the 1989 Prince of Persia in C#. The first version parsed rooms, tiles, gates, and guard positions. It still moved the prince one tile at a time. The original uses frame sequences with smaller movement steps. Later surface fixes did not repair that wrong design.[1]
This is one person's experiment, not a controlled model benchmark. The prompts, tools, and code changed between rounds. The lesson still travels: a port can parse the right data and render familiar shapes while missing the behavior that makes the system itself.
A rebuild needs a witness that can disagree with plausible code.
The agent gained a reference it could operate.
Rajeevan reports that later sessions used skills to control DOSBox, send keys, and capture screenshots from a personal copy of the DOS game. The agent compared its port against the running game. It then replaced the tile-grid movement design with a frame-sequence design and used data from the original game files at runtime.[1]
The published repository has a headless mode that writes one PNG per tick. It accepts scripted key sequences. Its README separates working behavior from unfinished work, including guards, sword fighting, sound, palace art, and exact landing positions. That boundary matters more than a broad claim that the game was ported.[2]
Prior art supplied the missing map.
The final drawing work did not come from the DOS binary alone. Rajeevan says the agent found SDLPoP and ported its room-drawing routine. SDLPoP describes itself as an open-source port based on a disassembly of the DOS version. Its documentation credits earlier technical work and Jordan Mechner's released Apple II source.[3]
Mechner's repository contains the original 6502 assembly source from 1985 through 1989. Its README says the archive was recovered from old floppy disks and published for study. It also states that the source release grants no rights in the Prince of Persia franchise.[4]
This makes the evidence chain specific. The Apple II source explains an original design. SDLPoP reconstructs DOS behavior. The operator's DOS copy supplies runtime data and screenshots. The new C# port can then compare its output against a reference. None of those sources can replace the others.
A tiny pixel count can hide a large test gap.
Rajeevan reports that one checked room fell from 8,429 differing pixels to two. The repository uses narrower wording: room drawing is pixel-exact on the rooms checked against DOSBox. It also says only one DOS copy has been tested. Those limits belong beside the result.[1][2]
A screenshot diff checks one input, one time, one capture path, and one part of the screen. It does not prove movement, collision, timing, sound, or every room. Each behavior needs its own input script and comparison rule.
Build the loop before ranking the driver.
- Reference. Name the exact version, legal access path, revision, assets, and known differences.
- Drive. Use one recorded input sequence against both systems. Pin timing and initial state.
- Compare. Choose the right oracle for the behavior. Use pixels for rendering, state traces for movement, and events for side effects.
- Replay. Save the inputs, outputs, thresholds, and failure image. Run them again after the next change.
The test track below writes a witness-loop plan. It does not run DOSBox, inspect game files, compare screenshots, or certify a port.