Recomps Are Eating Decomps' Lunch—And That's the Whole Point

The schematic

A decompilation project begins with a finished binary and works backward, function by function, until every instruction has been reconstructed in human-readable source code. The ReadOnlyMemo tracker currently lists dozens of active N64 decomps, most of them multi-year commitments. The SM64 decomp took years of volunteer labor before it compiled. Ship of Harkinian—the community port of Ocarina of Time—required a complete Ocarina decomp as its foundation. Each project is bespoke. Each is a monument. And each is a dead end in terms of tooling: the work done on OoT cannot be reused on Majora's Mask without starting most of it over.

A recompilation project inverts the economics. Instead of reconstructing source for one game, it builds a translator for an entire platform's instruction set. N64Recomp takes any N64 MIPS binary and statically recompiles it into C code that can be compiled natively for modern hardware. XenonRecomp does the same for Xbox 360 PowerPC executables, outputting C++ with x86 intrinsics. The upfront cost is high—you're building a compiler pipeline, not annotating a disassembly—but once it exists, new games on that platform become candidates immediately.

Decomps are archeology. Recomps are infrastructure. One recovers the blueprint; the other paves the road.

That's the schematic reference, and it's the reason the scene is shifting weight. Scalability is the recomp's superpower. A decomp is a multi-year project per game. A recomp is a multi-month project per platform—then every game on that platform comes along for the ride.

The mechanism: how it actually works

N64Recomp operates at the static binary level. It reads a standard N64 ROM, identifies MIPS instructions, and emits equivalent C functions that compile with any modern C compiler. The output isn't pretty source code—it's machine-generated C that preserves the behavior of the original binary while targeting your host CPU natively. There's no dynamic recompilation at runtime; it's all done ahead of time, which means the resulting executable runs at native speed without the overhead of an interpreter or JIT. You supply your own legally-owned ROM. The tool does the rest.

XenonRecomp follows the same principle for the Xbox 360's PowerPC architecture. It converts 360 executables into C++ code that recompiles for x86 platforms. The current limitation: it only targets x86, because the translation layer uses x86 intrinsics for certain PowerPC-specific operations. ARM support isn't there yet. But for PC and Steam Deck users—which is most of the audience—x86 is the whole world.

Both tools still require per-game configuration work. Graphics APIs need wrapping. Game-specific quirks need patching. But the difference between "configure a port" and "reconstruct the source code from scratch" is the difference between weeks and years. That gap is where the movement lives.

What shipped this week

N64Recomp's latest release on May 4, 2026 includes a Mod Tool—an SDK-level addition that lets modders hook into any N64: Recompiled project that has enabled modding support. This is a significant escalation. It means the recomp pipeline isn't just producing static ports; it's producing moddable ports. The N64 never had a mod scene in the PC sense. Now it can.

Alongside the Mod Tool, the community has shipped N64RecompLauncher—a free launcher that tracks, downloads, and organizes N64 recomp ports in one place. If you're running a Steam Deck or a desktop Linux box and you want to manage a growing library of recompiled N64 titles, the launcher is the front door. It's not flashy. It is extremely useful.

On the Xbox 360 side, ReXGlue—the SDK layer that sits on top of XenonRecomp—now has its own dedicated section of playable ports. Contributors have been using it to spin up working 360-to-PC conversions, including Blue Dragon (the Mistwalker JRPG that never left the 360) and the Jak & Daxter trilogy, with Jak 3 recently added alongside the first two entries. These are games that were, until very recently, stranded on a single piece of hardware with no PC port and no remaster. Now they're playable on a laptop.

The side-by-side

Here's the mechanism mapping, because precision matters:

Decompilation takes one game's binary → reconstructs human-readable source → that source compiles for any target. The output is understanding: you know what every function does, you can modify it at the source level, you can port it anywhere with full control. The cost is years of expert labor per title. The SM64 decomp produced one of the most studied codebases in game history. Ship of Harkinian gave us a living, modifiable Ocarina of Time. These are genuine achievements in software archeology.

Recompilation takes one platform's instruction set → builds a static translator → that translator processes any binary from that platform into compilable C/C++. The output is playability: the game runs natively, at full speed, on modern hardware. You don't get source-level understanding. You get a working port. The cost is building the recompiler once—then amortizing it across every game on the platform.

Decomps preserve the knowledge. Recomps preserve the experience. Both are preservation. They just preserve different things.

A game stranded on dead hardware with no official remaster becomes a native PC port in weeks, not years. That's a fundamentally different preservation model—one that prioritizes access over archeology.

The people

Wiseguy (Mr-Wiseguy on GitHub) is the architect of N64Recomp. The project's repository is active, well-documented, and accepting contributions. The Zelda 64: Recompiled port of Majora's Mask was the proof-of-concept that put N64Recomp on the map—native performance, widescreen, modern controls, running from a standard ROM with no emulator in the loop. That project demonstrated that static recompilation wasn't a theoretical curiosity; it was a shipping product.

XenonRecomp's development has been driven by hedge-dev and the contributors around the Fable2Recomp organization on GitHub. The ambition is visible in the name: Fable 2 was the initial target, another game marooned on the 360 with no PC version. But the tool itself is platform-general for the 360's architecture, which is why ReXGlue could spin up so quickly on top of it.

These are small teams. In some cases, solo developers. The output-to-headcount ratio is staggering, and it's the clearest evidence that the recomp model works: you don't need a hundred volunteers working for a decade. You need one good systems programmer building the right abstraction.

What recomps don't do

Intellectual honesty requires naming the trade-off. A recompiled port does not give you source code. You cannot read it, study it, learn from it the way you can with a decomp. The SM64 decomp taught a generation of developers how a 1996 3D platformer actually worked at the instruction level. N64Recomp doesn't teach you anything about the game's internals—it just makes the game run.

Recomps also inherit the original binary's bugs and limitations. A decomp can fix a race condition in the original code because the decomp understands the code. A recomp patches around bugs at the wrapper level, which is less elegant and sometimes less complete.

And recomps are platform-locked on the input side. N64Recomp handles MIPS. XenonRecomp handles PowerPC. A new console architecture means a new recompiler—though once built, the same amortization logic applies.

None of this diminishes the recomp model. It contextualizes it. Decomps and recomps aren't competitors. They're complementary tools with different cost curves and different preservation outputs. The scene needs both. But right now, the recomp pipeline is the one that's scaling, and scaling is what the preservation crisis demands.

The math that matters

The N64 library alone has roughly 400 titles. The Xbox 360 library has over 2,000. The number of completed decompilation projects across both platforms is in the single digits. The number of games that will never receive an official remaster is in the high hundreds. Every year, the hardware those games depend on degrades further. Every year, the window closes a little more.

Recompilation doesn't solve the whole problem. But it changes the math from "we can save a handful of masterpieces if enough volunteers donate enough years" to "we can save libraries if the tooling is good enough." That's not a philosophical shift. It's an engineering one. And the tools just got meaningfully better.

Wiseguy built a road. hedge-dev built another one. The games are starting to cross.