Decomp, recomp, reimplementation: one game as a case study
Legend of Legaia has been ported twice over the same months, by two separate efforts taking different routes: a static recompilation and this from-scratch engine. That makes it a rare side-by-side. This page sets out what each route gets up front, what it has to earn, and why building a new engine is a far more practical option than it used to be.
Three established routes
There are three established ways to carry a console game's logic onto new machines, and each makes something different. Matthew Stanley, whose PSXRecomp is the recompiler in this case study, writes of decompilation and recompilation that "They produce different things — infrastructure and understanding". Reimplementation produces a third thing: an engine of its own, running the original's data.
DecompilationSource code that rebuilds the game, and an understanding of what it does.The Super Mario 64 and Ocarina of Time decompilations
Static recompilationThe original game running natively, over a model of its hardware.N64Recomp, XenonRecomp, PSXRecomp
ReimplementationA new engine that loads the original's data and behaves like the original.OpenMW, OpenLoco, OpenRCT2, ScummVM
Reimplementation has a long record. OpenMW is "an entirely different game engine that does not use the original executable file in any way". OpenLoco finished reimplementing its game in C++ in December 2025. On PlayStation, Severed Chains is The Legend of Dragoon "disassembled and rewritten in Java". Legaia now lets the route be compared directly with a recompilation of the same game.
Terms on this page
A port is a result, not a method. A PC port can be built on a decompilation, a recompilation or a new engine. "Reimplementation" here means the whole game's engine; a recomp's runtime also reimplements libraries and hardware, which is a narrower thing. Engine recreations are often divided into top-down and bottom-up: built from specifications and then tuned, or rebuilt from the disassembly. This project is bottom-up in what it reads and new in what it writes.
What actually runs
The names blur, but the question that separates them is concrete: when you press Start, whose code is executing?
Amber is the original's code in the running program. Decompilation and recompilation keep it in different forms. A reimplementation has none, which is its whole bargain: everything that amber box would have given for free has to be found and rebuilt.
Legaia suits the third column unusually well. Field scripts, effects and moves are bytecode on the disc, so porting a VM carries every script written for it. The same fact is why the disc has so much for a new engine to read.
One game, two ports, the same months
PSXRecomp and this project both started in spring 2026, within weeks of each other, and the Legaia recomp builds on PSXRecomp. All three are still going. Three threads run through them: getting the game playable from start to finish, matching the original, and letting people change it. Dates come from each project's commit log.
Hover or tap a point for details, and click it to open its commit or pull request. Dates come from each project's commit history and are approximate. All three are still active. PSXRecomp's prototype dates from March, the Legaia recomp's line starts at its first published commits, and this repository opens with a first release, so its work starts somewhat before May.
Playing the game
PSXRecomp · May 17Tomba! reaches gameplay on the framework.
Legaia recomp · Jul 17 Legaia runs field, battles and summons, with public playtest builds from Jul 18.
Legaia engine · May 23 A walkable overworld, with collision and encounters.
Legaia engine · Oct 17 A run on pad input alone reaches the credits.
Fidelity
PSXRecomp · May 9-13 Hardware accuracy: SPU envelopes, vblank pacing on guest cycles.
Legaia recomp · Jul 17 Legaia's CD and XA sequencing in battle.
Legaia engine · May 19-25 Audio oracles: PCM parity and bit-exact XA.
Legaia engine · Sep 29 The full-game ladder, retail corpus and soak harness.
Modding
PSXRecomp · Jun 12 Widescreen and an OpenGL renderer, framework-wide.
Legaia recomp · Oct 2 A modding SDK, in development on a public branch.
Legaia engine · May 31 The disc patcher and randomizer, for the retail game.
Legaia engine · Jul 15 Language packs on the same patcher.
Legaia engine · Oct 30 Expansion packs, game modes and netplay.
The recomp and the engine come at the same goals in different orders. A recomp starts with the original's own code, so retail behaviour is there from the first frame and the work goes into making the hardware model right. That is the quickest way to play a game as it was, and the framework behind it already carries Tomba! and Mega Man X6 as well. The engine started with nothing running, and built up both the playthrough and its fidelity one mechanism at a time against retail captures.
Modding has been a thread of its own on both sides, and the kinds of mod differ. Disc patches like the randomizer change the retail game's own bytes, so they arrived early, before the engine could play the story. Language packs followed on the same tooling. Expansion packs came later because they need the engine: they name monsters, maps and quests rather than addresses.
The two have also helped each other throughout. The recomp's README credits this project's docs, saying they "materially shortened the investigation and guided the runtime's overlay-cache fixes", and the recomp is one of this project's best references for what retail actually does.
What each route gives you, and what takes extra work
Each route gives you some things simply by taking it. Most of the rest can be had with extra work, and a few things go against how the route works.
● Built in part of taking the route
◐ Extra work reachable, at a cost
○ Poor fit works against the route
You want
Decompilation
Static recompilation
Reimplementation
The whole game running
◐ Extra workAll the code, plus a platform layer.
● Built inOnce the runtime exists and the code is found.
◐ Extra workOnce every routine is ported or handed to a library.
Retail quirks and timing
● Built inIn the logic; timing depends on the platform layer.
● Built inIf the hardware model is right.
◐ Extra workFound and measured one at a time. Full visual parity comes last.
Assurance the code is right
● Built inWhen matching: a byte match per function.
● Built inTranslation is mechanical. The runtime carries the risk.
○ Poor fitMeasured over samples, never proved.
Rules a person can read
◐ Extra workNaming and typing, after the match.
○ Poor fitGenerated C. Machine state stays visible.
● Built inWritten as ordinary named code (this project tags each routine with its retail address).
New rendering
◐ Extra workReplace the draw path in source.
◐ Extra workWell served at the draw-call level: PSXRecomp has widescreen and new backends.
● Built inThe renderer is the engine's own (this project uses wgpu).
Running on new systems
◐ Extra workSomeone writes a platform layer for each new system.
◐ Extra workThe generated C compiles almost anywhere, but the PlayStation runtime has to be brought to each new system.
● Built inNo console code to carry, so a new system is ordinary engine work (this project runs natively and in a browser).
Modding by game concept
◐ Extra workSource edits, easier as names land.
◐ Extra workHooks that change or replace the game's functions. Finding what to hook generally requires a decompilation or disassembly.
● Built inMods can name monsters, maps and quests rather than addresses (this project uses TOML expansion packs).
Targeting another game on the same console
◐ Extra workThe tools carry. The work does not.
● Built inThe framework carries. A game adds config and fixes.
No court has settled any of this. The nearest test, Take-Two's case over the GTA re3 and reVC projects, ended in dismissal with no ruling on the merits. A reimplementation written by people who read the disassembly is not "clean-room", and this project does not use the term; the boundary it does enforce is narrower. Whether AI assistance changes that picture is unresolved too.
The same problems, paid for differently
These come from the two Legaia ports. Each cost something on both sides, in a different place.
Battle items and CD audio
Recomp
Legaia's CD callback can wait for a vblank from inside an exception handler, an unusual pattern that showed up on battle items. Handling it in the hardware model fixed items, Spirit actions, Hyper Arts and summons together.
Reimplementation
No libcd runs here, so that pattern never arises. The timing that comes with it was missing too: retail battle frames run long during a CD-XA clip, five to seven vsyncs. The engine played them at the normal rate until that was measured and modelled.
A fix in a recomp's hardware model reaches the whole game at once. A reimplementation's fixes are local and found one at a time.
Code that is not in the executable
Recomp
The translator sees the boot executable. Overlays load at runtime into a reused window, so they are captured as they load and then compiled, or interpreted until they are. Jump tables need help too: the renderer's computed jr does not resolve statically.
Reimplementation
Overlays are extracted from the disc and read once, with no need to reach them in play. The price is bookkeeping: overlays share addresses, so an address alone names nothing, and these docs have been wrong about that.
The recomp's problem is finding the code. The reimplementation's is knowing whose code it is reading.
A bug no local test could see
Reimplementation
The GTE model passed its own sweep, because the sweep agreed with the model. The screen-coordinate FIFO saturates at signed 11 bits, and nothing here knew that.
Recomp
Running retail's code, it produced real input and output pairs from the GTE, which exposed the difference at once. Its value here was as a second, independent execution.
Each route makes the others better. Here, each has been the other's best instrument.
How a mistake shows up
The biggest practical difference between the routes may be when you find out that somebody misread the original.
DecompilationAt build timeA matching build reports that the function differs. Non-matching work gives this up.
Static recompilationUsually while playingA crash, a freeze or a visible glitch, though timing problems can be subtle.
ReimplementationOnly by comparingThe game runs and is slightly different, so the mistake appears only when measured against the original.
That third row is the real historic objection to reimplementation. Without something to compare against, you can only say it feels right. It is also why this project spends so much on measurement: the retail-oracle method exists to turn that difference into a number. Even so, a score only speaks for what it sampled. A matching decompilation's proof is stronger, and nothing here replaces it.
Why reimplementation is more viable now
Reimplementation has had two standing problems: years of labour before the first reward, and differences from the original that go unnoticed. Both have become more tractable, for connected reasons.
The labour is the kind coding agents do well. Reading a routine, writing the equivalent function, wiring it up, and repeating that across a whole game was the cost. By hand, that work is measured in years: OpenLoco finished reimplementing its game in C++ only in December 2025.
The instruments have got cheap to build. Scriptable emulators, readable save states and headless Ghidra existed already. What a small project could not afford was the software on top: state readers, scoring channels, ratchets and replay. An agent can write those too.
Those two fit together. An agent is a fast and confident writer, and unnoticed differences are what a fast, confident writer produces. A reimplementation with measurement gives that writer something external to answer to.
The agent is inside the loop. The ground truth is not. This project's version is the retail-oracle method.
What got cheaper
Reading a routine and writing its equivalent.
Wiring, and the sweeps nobody wants to do by hand.
Single-purpose tools, written for one question.
Docs that stay current because they are written with the change.
What did not
Retail captures, many of which need someone on the pad.
Deciding what counts as right, and which scores to trust.
Noticing that a green test measures nothing.
Standing in a community that may not want this.
This is not an argument that AI favours reimplementation alone. This project is written with Claude Code. So was the prototype of PSXRecomp, by an author with no compiler background, who adds that "the process still requires significant human oversight". Matching decompilation may have the best signal of the three, since a byte match is an unambiguous score: Chris Lewis matched one N64 game in 84 days against 596 for its sequel, with a different compiler and prior experience in the mix, and estimates it would have stalled around 89-90% without human experts. His 2025 view was that "We're a long way from 'vibe coding' being viable for matching decompilation."
The narrower claim is the one this case supports: all three routes got cheaper, and reimplementation had the most to gain, because labour was the thing that ruled it out for small teams. It need no longer be a commitment of many years. It is still a lot of careful work. Human judgment remains in the loop, and a project that skipped the measurement half would be producing exactly what its critics expect. The register of disproved readings is a public record of how plausibly wrong a reading can be.
The community cost is real
decomp.dev is sunsetting its main index, writing that AI "can expedite the decompilation process in a significant way" with the right guidance and that "the community aspect of decompilation has been broken". DarioSamo, who led Banjo: Recompiled, declined "a race to the bottom" with AI-generated ports. Severed Chains states "AI was not used to create this project", which is a useful reminder that a reimplementation has never needed it. Work built on other people's research owes those people credit, and this one tries to pay it in its acknowledgments.
Choosing a route
You want the game on modern machines, as it wasStatic recompilation, if a framework for the console exists. Nothing here competes with it on speed.
You want to know exactly what the code saysMatching decompilation, if the compiler can be pinned down.
You want the game to become more than it wasReimplementation, especially if much of the game is data, the target cannot carry its code, and you can measure against the original.
You want to play it tonightAn emulator, or an official release if there is one.
The routes also combine. This project uses a recomp as an oracle, Ghidra's output as a pointer and an emulator as the judge, and a matching decompilation of Legaia would be a better reference than any of them.
What this case cannot show
It is one game, and a heavily data-driven one, which flatters this route.
The two efforts are shaped differently. PSXRecomp is a general framework serving several games, and this repository is about one. Neither side has logged hours, so no labour comparison is possible.
There is no third column. As far as this project knows there is no public decompilation of Legaia, so that route is argued from other games.
"Reaches the credits" is not "identical to retail". Parity is measured over what the corpus has sampled, and it is still being worked on.
Both projects are moving. This is a snapshot, and the modding comparison in particular will change as the recomp's work ships.
The author has a side. This page is written by the project it argues for. The links are there so that you can check.