The Recomp Wave Is Coming for the Xbox 360. Here's the Toolchain Making It Happen.

The idea that already shipped

To understand what XenonRecomp is attempting, you have to understand what N64Recomp already proved. The project, created by Mr-Wiseguy (known in the scene as Wiseguy), takes a compiled N64 MIPS binary — the same data that sits on your cartridge — and statically translates every instruction into equivalent C code. That C code gets compiled with a standard desktop compiler. The result is a native executable that runs on your PC at whatever resolution and frame rate you want, with no emulator executing instructions at runtime.

This is not the same as dynamic recompilation, which is what emulators like Mupen64Plus or Project64 do. Dynamic recomp translates instructions on the fly, in memory, while the game runs. Static recompilation does the translation once, ahead of time, and produces a normal binary. The performance ceiling is higher. The modification surface is wider. And the legal posture is different: the toolchain is open source; the ROM you feed it is yours.

The proof that the idea worked at scale arrived when Wiseguy's Zelda: Majora's Mask recomp shipped in early 2024. It supported widescreen, high resolution, modding hooks, and — critically — ran without any emulation layer in the final binary. The project landed like a detonation in the preservation community. As RetroLunch's comprehensive scene overview puts it, the recomp model "changes the conversation about what 'porting' even means when no one has the source code."

"Static recompilation changes the conversation about what 'porting' even means when no one has the source code."

The schematic: how N64Recomp actually works

The pipeline has three layers, and understanding them is essential to understanding why the Xbox 360 leap is both harder and more consequential than it looks.

Layer 1: The recompiler itself. N64Recomp reads the MIPS R4300i instruction set that every N64 game was compiled to. It walks the binary, identifies functions, and emits C code that performs the same operations — loads, stores, arithmetic, branches — using native types. The output isn't pretty C. It's machine-translated C that a compiler (GCC, Clang, MSVC) can optimize into x86_64 or ARM machine code. The recompiler doesn't need to understand what the game does. It only needs to understand what each instruction does.

Layer 2: The runtime environment. An N64 game expects to talk to specific hardware: the Reality Signal Processor for 3D, the Reality Display Processor for rasterization, the audio DAC, the controller interface. N64Recomp ships with RT64, a runtime renderer that intercepts the recompiled code's graphics calls and translates them to modern GPU APIs. Audio, input, and memory management get similar shims. This is where the widescreen support, resolution scaling, and frame rate unlocking happen — the runtime layer can do things the original hardware never could because it's running natively, not interpreting.

Layer 3: The mod surface. Because the recompiled output is C code compiled to a native binary, modders can hook into functions, replace assets, and inject new behavior using standard tools. This is categorically different from ROM hacking. You're modifying a PC application, not patching bytes in a binary blob.

Enter XenonRecomp: the 360 problem

The Xbox 360 ran on a custom IBM PowerPC tri-core processor called the Xenon. Its instruction set, its memory model, its GPU interface (a custom ATI Xenos), and its OS-level services are all different from the N64's. XenonRecomp, developed by the scene developer known as hedge-dev, applies the same static recompilation thesis to this far more complex target.

The scale difference is not trivial. An N64 ROM is typically 8–64 MB of MIPS instructions and assets. An Xbox 360 XEX (the executable format) can be hundreds of megabytes, compiled from C++ for a three-core, six-thread PowerPC chip with VMX128 vector extensions, a unified shader architecture GPU, and a full operating system with threading, networking, and achievement APIs. Every one of those surfaces has to be handled.

This is where ReXGlue comes in. If XenonRecomp is the translation engine — PowerPC instructions to C — then ReXGlue is the runtime shim that stands in for the Xbox 360's operating system and hardware services. ReadOnlyMemo's April 2026 project list describes it as the layer that "provides the kernel, graphics, and XAudio stubs the recompiled code expects to call." Without ReXGlue, the recompiled C code would compile but immediately crash — it would try to call Xbox kernel functions that don't exist on your PC.

Side-by-side: the mechanism mapping

Here's where the two toolchains line up — and where they diverge:

Input format. N64Recomp reads .z64/.n64 ROM dumps (MIPS R4300i, big-endian). XenonRecomp reads .xex executables (PowerPC with VMX128 extensions, big-endian). Both require you to supply your own legally obtained binary.

Translation target. Both emit C code. Both compile to x86_64 (and potentially ARM64). The C output is not human-readable game logic — it's a mechanical translation of every instruction, branch, and memory access.

Runtime layer. N64Recomp uses RT64 for graphics, plus custom shims for audio and input. XenonRecomp uses ReXGlue, which must reimplement a much larger API surface: the Xbox 360 kernel (threading, memory, file I/O), XAudio2, the Xenos GPU command buffer, and XInput. ReXGlue is the hard part. It's also the part that will determine whether any given game actually boots.

Mod surface. Both produce native binaries that are moddable with standard PC tooling. The 360 recomp has a potentially richer mod surface because the original games were written in C++ with richer data structures — but exploiting that surface requires more reverse-engineering work per title.

Maturity. N64Recomp has shipped playable ports. XenonRecomp has a Fable II proof-of-concept on GitHub that demonstrates the translation pipeline but is not yet a playable end-to-end port. The gap between "the recompiler emits C" and "the game boots and runs" is where most of the remaining labor lives — inside ReXGlue.

Why this matters for preservation

The Xbox 360 is twenty-one years old. Its digital storefront is closed. Its disc drives are failing. Its successor offers backward compatibility for a curated subset of the library, not the full catalog. Hundreds of games — including titles that were never ported, never remastered, never re-released — exist only on hardware that is degrading.

Emulation for the 360 exists (Xenia is the primary project), but it is incomplete and computationally expensive. Static recompilation offers a different path: instead of simulating the entire console in software, translate the game itself into something that runs natively. The result is faster, more portable, and more moddable. It also creates an artifact — a compiled PC binary derived from your own disc — that doesn't depend on the continued development of any emulator.

Static recompilation doesn't simulate the console. It translates the game. The result doesn't depend on any emulator's continued development.

The legal framework matters here. N64Recomp and XenonRecomp are clean-room tools. They don't distribute any copyrighted code. They don't contain any game data. They translate a binary you supply into a different binary that runs on different hardware. The toolchain is open source under permissive licenses. The copyright status of the output binary is, as with any format-shifting question, a matter for lawyers — but the toolchain itself is unambiguously legal to distribute, use, and modify.

Who built this

Credit where it lives. Mr-Wiseguy (Wiseguy) created N64Recomp and proved the model. hedge-dev created XenonRecomp and is building the 360 translation pipeline. Both projects are open source. Both are the work of individual developers with small contributor communities, not studios, not corporations, not funded labs. The scene runs on people who do the work and publish the results.

RetroLunch's March 2026 overview is the best single document on the recomp scene's current state — scope, limitations, legal posture, project list. ReadOnlyMemo's April update adds the XenonRecomp and ReXGlue specifics. Both are worth reading in full. Both did the reporting that makes a piece like this possible.

What happens next

The N64 recomp pipeline is proven. The 360 pipeline is public but early. The gap between them is not a gap in the idea — the idea is the same. The gap is in the runtime layer. The Xbox 360's Xenos GPU, its threading model, its audio stack, its kernel services — all of that has to be reimplemented in ReXGlue before any given title can boot. Each game will stress different parts of that shim. Some will be straightforward. Some will expose edge cases that take months.

But the trajectory is clear. Static recompilation is not a curiosity anymore. It is a preservation methodology with a shipped proof-of-concept on one platform and an active toolchain targeting another. The wave is not coming. The wave is here. The question is which titles it reaches first — and how much of the seventh generation's library gets translated before the last working disc drive fails.

The tools are open. The repos are public. The work is ongoing. Names on the door: Wiseguy. hedge-dev. Go read their code.