Sonic Unleashed, Majora's Mask, Gran Turismo 4 and Demon's Souls now run on PC as ordinary programs, without an emulator, and none of their publishers had a hand in it. Behind all of them is one idea: take the game's machine code from your own disc or cartridge, translate it into C or C++ once, and build a normal executable from it. This is called static recompilation. Below we explain how it works step by step, using the documentation of the tools themselves: N64Recomp, XenonRecomp, ReXGlue, PS2Recomp, ps3recomp and others. You will also see why every console needs its own recompiler, where the graphics come from, and what a recomp can and cannot do.
Emulator, recompiler, decompilation: three ways to run an old game
An emulator pretends to be the whole console. While you play, it reads the game's instructions for a foreign processor and translates them on the fly, either one by one or in blocks with a JIT compiler, and at the same time it imitates the graphics chip, the sound chip and the system software. That is why one emulator can run hundreds of games, and why it needs a much stronger PC than the console it copies.
A static recompiler does the translation once, before you play. The N64Recomp documentation puts it simply: the tool splits the binary into functions, with each one "individually recompiled into a C function". A C or C++ compiler then builds an ordinary program from that code. There is nothing left to translate while the game runs, so the PC spends its power on the game itself.
Decompilation is the third route. People rebuild readable source code of the game by hand, function by function, until it compiles back into exactly the original binary. That took years for Super Mario 64 or Ocarina of Time, but the result can be changed freely. A recomp is much faster to make, which is why the Zelda64Recomp README stresses that it is "not based on the source code provided by a decompilation". In practice the two help each other: Majora's Mask uses headers and some functions from the decompilation project to add its improvements.
Six steps from disc to .exe
1. The executable. Everything starts with the program file from your copy of the game: a .z64 ROM on N64, default.xex on Xbox 360, an ELF file on PS2, default.xbe on the original Xbox, EBOOT on PS3. On PS3 that file is encrypted, so it has to be decrypted first, usually with RPCS3. No real recomp ships this file: it comes only from your own copy, and many projects check its hash.
2. Finding the functions. To a machine, the code is one long stream of bytes, and the recompiler has to find where each function begins and ends. N64Recomp currently needs an ELF file with symbols, and the easiest way to get one is from a disassembly or decompilation. On Xbox 360, XenonRecomp's analyser reads the .pdata section of the executable, where the boundaries of most functions are recorded, and finds the rest by searching for calls. On PS2, the PS2Recomp authors recommend opening the game in Ghidra and exporting the function list with their script.
3. Translating instructions. This part is deliberately literal. In N64Recomp the MIPS instruction addiu $r4, $r4, 0x20 becomes the C line ctx->r4 = ADD32(ctx->r4, 0X20);, and PS2Recomp uses the same example for the PS2's R5900. The console's registers live in a "context" structure that is passed to every function, a call instruction becomes an ordinary function call, and the console's memory becomes a block of the PC's RAM. The XenonRecomp authors write that the output is "not very human-readable", and that is fine: a compiler reads it, not a person.
4. The hard parts. Some things cannot be translated line by line. A switch statement in the original game often compiles into a jump table, where the address is computed while the game runs; recompilers recognise such patterns and turn them back into real switch statements. Calls through pointers, virtual functions in C++ games, become lookups in a table of already translated functions. The Xbox 360 and PS3 are big-endian, unlike the PC, so every memory read and write swaps the byte order. MIPS processors have branch delay slots, where the instruction after a jump still runs, and N64Recomp handles them by duplicating instructions. Some things are still unsupported: XenonRecomp, for example, does not handle exceptions.
5. The runtime. The translated code still expects a console around it: system calls, threads, a file system, a controller, a sound chip, a graphics chip. All of that is provided by a runtime library. XenonRecomp's README warns that it "does not provide a runtime implementation" and that making the game work is up to the porter. For the PS3, ps3recomp ships its own implementation of the LV2 kernel with more than 300 system calls and over 100 system libraries, from cellAudio to cellSaveData.
6. The build. Clang, GCC or MSVC compile the generated code together with the runtime into a normal program for Windows, Linux or macOS. Because the output is C or C++, the same code can be built for ARM too, which is why some recomps also run on Android phones or Apple Silicon Macs. Many projects let you do this step yourself: the installer downloads the build tools and compiles the game from your copy, so the download itself contains no game code.
Graphics: where most of the work goes
Translating the CPU code is only half a port. Console games talk to their graphics chip directly, and the PC has nothing like it, so each recomp needs a renderer. There are two approaches.
The first is to translate the console's graphics commands for a modern API while staying faithful to the original. Majora's Mask uses RT64 for that, and its README says the effects are drawn "exactly as they did originally", while RT64 also adds any frame rate, widescreen and ultrawide. The game logic still runs at the original rate: "Changing framerate has no effect on gameplay." PS2 recomps for Gran Turismo 4, Killzone and Urban Reign borrow the graphics part of the PCSX2 emulator, so emulation there has not disappeared, it has just moved to the GPU side.
The second is to write a new renderer for one particular game. In Sonic Unleashed, the XenonRecomp authors also built XenosRecomp, which converts the Xbox 360 shaders into HLSL, and wrote a renderer "from scratch" that sends the game's draw calls to Direct3D 12 or Vulkan. Because the GPU doesn't have to be emulated, they skipped the hardware quirks a PC port doesn't need, and built shader compilation into asset loading, so new objects appear without the stutter familiar from emulators. Their README calls this an improvement "that'd never be possible with an emulator".
Every console is its own puzzle
A recompiler is tied to a processor and to a console's hardware, so each platform got its own tool, and the difficulty differs a lot.
| Console | Processor | Main tool | What is hardest |
|---|---|---|---|
| PS1 | MIPS R3000A | RecompOne | the hardware environment; the code is translated into C# |
| Nintendo 64 | MIPS R4300 | N64Recomp, N64ModernRuntime, RT64 | overlays loaded at different addresses, the RSP microcode |
| PS2 | MIPS R5900 plus VU0, VU1 and the IOP | PS2Recomp | vector unit microprograms, the GS graphics chip, the second IOP processor |
| Original Xbox | x86, Pentium III | xboxrecomp | the Direct3D 8 layer and the NV2A graphics chip |
| GameCube, Wii | PowerPC Gekko and Broadway | NWiiRecomp | the GX graphics pipeline, solved here with its own rasteriser |
| Xbox 360 | PowerPC Xenon, three cores | XenonRecomp, ReXGlue | big-endian data, VMX vectors, Xenos shaders, jump tables |
| PS3 | Cell: one PPU and six SPUs | ps3recomp | SPU programs with 256 KB of local memory and DMA, the LV2 kernel, encrypted EBOOT |
The PS3 is the hardest case. Besides the main PowerPC core, the Cell has six SPU coprocessors, each with its own instruction set, its own 256 KB of memory and data moved by DMA. ps3recomp translates SPU programs separately: each SPU's local memory becomes an array, DMA transfers become memory copies, and the communication channels become message queues between threads. The original Xbox is the opposite: its processor is the same x86 family as a PC, and the xboxrecomp authors call their toolkit the first public static recompiler for that console.
The PS4 stands apart. Its x86-64 code can run on a PC processor almost as is, so PS4 ports such as Bloodborne or God of War III don't translate code at all: they replace the system libraries and send graphics to Vulkan through the shadPS4 video core. More on that in our list of PS4 ports.
Why so many ports appeared in 2026
We counted GitHub repositories with "recomp" in the name by the month they were created. In October 2025 there were 37 new ones, in March 2026 already 111, in August 596, and in October 2026 as many as 1644, more than in all of 2024 and 2025 combined (681). Not every one is a game port: the count also includes tools, forks and tests. But the curve shows when the wave started: in the summer of 2026.
There are three reasons. First, ready-made templates: for the N64 most ports are built on the Zelda64Recomp template, for the Xbox 360 on ReXGlue, which according to its README is "heavily rooted" in the Xenia emulator, and a new porter starts from a working skeleton instead of a blank page. Second, the tools learned from each other: XenonRecomp was "heavily inspired" by N64Recomp, and ps3recomp names N64Recomp, Unleashed Recompiled, PS2Recomp and ReXGlue as its relatives. Third, AI assistants. Many authors state in their README that they wrote the port with Claude, Codex or other models, and the work of finding thousands of functions, missing instructions and system calls went from months to weeks.
The last point has a downside. Projects appear in a day and can be abandoned just as fast, some READMEs promise more than the build delivers, and fake repositories with someone else's name pop up next to real ones. We check every project by its README and release list before adding it to our recomp list.
What a recomp gives you, and what it can't do
- Speed. There is no translation while you play, so a recomp needs far less CPU than an emulator. In Unleashed Recompiled, extra optimisations shrank the executable by about 20 MB and cut frame times by several milliseconds.
- PC features. Resolution, frame rate, widescreen, mouse, DLSS or FSR are added in the runtime and renderer, not hacked on top of an emulator.
- Mods. Any translated function can be replaced with your own: XenonRecomp makes functions easy to hook, and N64Recomp lets you link patched versions of functions over the originals.
- One game, one version. A recomp is not an emulator. Majora's Mask accepts only the US N64 ROM, and the README answers the question about other ROMs with "You don't."
- Bugs of a young project. Anything the authors didn't foresee breaks: an untranslated instruction, a missing system call, an effect the renderer doesn't know. That is why most recomps of 2026 are still marked alpha or beta.
Finally, legality. A proper recomp contains no textures, sounds or levels: it reads them from your copy. With the code itself it depends on how the project is shipped. If the installer builds the game on your PC, the download contains only the tools. If the release is a ready .exe, the translated game code is inside it, and several authors say so openly in their README. We only ever link to the repositories, never to game files, and every list on our site includes what you need to own to play.
Sources
README files of N64Recomp, Zelda64Recomp, XenonRecomp, Unleashed Recompiled, ReXGlue, PS2Recomp, ps3recomp, xboxrecomp, NWiiRecomp and RecompOne, read on November 2, 2026. Repository counts: GitHub search API, query "recomp in:name" with a creation date per month, November 2, 2026. Diagrams and chart by FramesGames. Images: Microsoft Store.
