What Is a Game Decompilation? Decompilation vs. Recompilation vs. Emulation, Explained

Classic games keep getting "PC ports" that are nothing like the old fan remakes: it is the real game, running natively, with widescreen, high frame rates and mods. Behind many of them is one of two techniques with unfamiliar names: decompilation and static recompilation, and a third route, rewriting the engine, is catching up. This guide explains all three in plain language, how they differ from emulation, what they make possible, and how AI is starting to speed the work up, which has its own article.

The short version

• A decompilation rebuilds a game's source code from the finished program.
• A static recompilation translates the finished program into a new program that runs natively on another platform, usually a PC.
• An emulator imitates the old console and runs the original program unchanged.
• An engine rewrite writes a brand-new engine, often in Rust and sometimes on the Bevy engine, that loads the original game's data files.
• AI has made the most tedious part of decompilation, matching thousands of functions one by one, something that can run largely unattended (read more).

All of these routes need your own copy of the game. These projects publish code, not the game.

How a game becomes a program

Developers write source code in a language such as C. A compiler turns it into machine code, the raw instructions one specific processor understands, and that is what ships on the cartridge or disc. Compiling throws information away: variable names, comments and the structure of the original code are gone.

That is why you cannot just "open" an old game and read how it works. What you have is the finished program, and everything described below is a way of working backwards from it or around it.

What a decompilation is

A decompilation project recreates source code that a compiler turns back into the original program. In practice it is slow, collaborative detective work:

1. Disassemble. A tool such as Ghidra, which the NSA released as open source in 2019, turns machine code into readable assembly and a rough guess at C.
2. Get a first draft. Helper programs such as m2c generate candidate C code for each function.
3. Rewrite by hand. Contributors turn the draft into clean, named, readable C, function by function. Sites like decomp.me, a collaborative decompilation website, exist so many people can work on the same function together.
4. Compare to the original. The code is compiled and the result is compared to the original bytes. In a matching decompilation they must be identical, byte for byte. That is a strict, mechanical test: close does not count.

The Super Mario 64 decompilation is the classic example. According to its README, it builds matching ROMs for the Japanese, North American, European, Shindou and iQue releases, and you must supply a prior copy of the game, because the project does not include all of the game's assets.

Decompilation is not only for consoles. The LEGO Island decompilation targets a Windows game and aims to reproduce its original binaries byte for byte, and Pokémon Emerald rebuilds a byte-matching Game Boy Advance ROM from reconstructed source.

A diff tool reports how close a try is. A near miss, such as the compiler picking a different register, looks like this:

Progress is usually tracked as a percentage of functions done. Not every project is "matching": some settle for code that behaves the same without being byte-identical.

What a static recompilation is

A recompilation takes a different shortcut. It does not rebuild the source code. It translates the machine code itself, ahead of time, into code for the new platform.

The N64 tool N64Recomp shows the idea. Per its README, it splits a game's binary into functions and turns each one into C code, which an ordinary compiler can then build for Windows, Linux or macOS. The tool does not include everything needed to run the result: a separate runtime library supplies what the console's hardware used to, and a rendering engine called RT64 replaces the console's graphics chip. Zelda 64: Recompiled, a port of Majora's Mask, is built this way, as is Banjo: Recompiled. The same approach has been applied to the Xbox 360, for example in UnleashedRecomp, a port of Sonic Unleashed.

Because translation happens before the game runs, the result is an ordinary native program. According to an interview with the developer behind N64Recomp, this has two big consequences. The game does not have to be translated instruction by instruction while you play, which makes it much faster, and since all of the game's code is available to the compiler at once, it can be optimized more than a program translated on the fly. The code can also talk to the PC directly instead of going through an imitation of the old hardware, which is what makes things like gyro aiming and modern controllers possible.

A third route: rewriting the engine in Rust, with Bevy

Decompilation and recompilation both start from the game's own code. There is a third route that throws the old engine away: write a new engine from scratch that loads the original game's data, meaning its maps, models, textures and sounds. Nothing from the original program is translated, only its files are read. In our catalog these are listed as engine reimplementations.

Many newer projects of this kind are written in Rust, a programming language, and some use Bevy, a free, open-source game engine built in Rust. Bevy is data-driven: game objects are bundles of data, and separate pieces of code (systems) act on them, an approach known as an entity component system, or ECS. Graphics typically go through wgpu, a cross-platform layer over modern graphics hardware. In our catalog, Iron Doom is a Doom source port written in Rust on the Chocolate Doom codebase that uses Bevy's ECS, and shin is a Rust reimplementation of a visual-novel engine. It is still an uncommon route: only four projects in our catalog are built with Bevy, and you can see them on the Bevy hub.

The most visible example is IW4L, a standalone runtime for Call of Duty: Modern Warfare 2 (2009) written in Rust with Bevy and wgpu. According to its README, it reads the maps, models and textures from your own MW2 installation without modifying it and distributes no game assets. It includes its own readers for the game's data files and translates the game's Direct3D 9 shader code into the shader language wgpu uses, and it credits Ghidra and earlier community projects it learned from. Its own README is frank about the state of the work: players can explore maps, fight bots and record and replay demos, but gameplay is incomplete and you should expect missing behavior, bugs and desyncs. The repository was created on 13 September 2026 and had 773 stars on 6 October. It is in our catalog as Call of Duty: Modern Warfare 2 Engine Reimplementation.

Two things make IW4L a good illustration of where this route stands:

• It was built with AI throughout. The README states that the whole project is written by an LLM, and the repository includes an agent instructions file. Because there is no original source to match byte for byte, the exact referee described in our AI article is weaker here: you cannot compare bytes, you can only check that maps load, bots play and replays agree. That is our reading, and the README's own warning about desyncs fits it.
• Open code let others build on it. A fork mashes Modern Warfare 2, Skate 3 and Minecraft up in a single game: Modern Warfare 2, Skate 3 and Minecraft Merge (the repository is called 2010-rust-rewrite-mashup) adds Skate 3 skating and a playable Minecraft world to IW4L's MW2. According to its README, you need your own copy of Modern Warfare 2 (and optionally the Xbox 360 version of Skate 3), and the Minecraft assets are downloaded from Mojang's servers on first launch rather than shipped in the repository. One article describes the legal position of this kind of project as a grey area rather than a settled one.

A rewrite does not need the original compiler or a byte-for-byte match, which makes it a possible route for larger, newer games. The price is that the result is never an exact copy of the original program: it is a new engine imitating the old one, so details can differ.

Decompilation, recompilation and emulation compared

What it makes possible

• Native speed, even on modest hardware. The same developer reports that the recompiled Majora's Mask runs at a smooth 60 fps on a Steam Deck and has been tested on decade-old PCs.
• Modern features. Widescreen, higher resolutions and frame rates, controller remapping and gyro aiming are all listed for Zelda 64: Recompiled.
• Mods. A native program can be patched. Zelda 64: Recompiled lists mod support, and Banjo: Recompiled is built on the same foundation.
• New platforms. Banjo: Recompiled is a native port for Windows, Linux and macOS of a game that originally shipped on the N64.
• Whole series on PC. OpenGOAL is catalogued as a native PC port of the Jak and Daxter trilogy, decompiled from the original GOAL code; it requires your own PS2 discs.
• Research and preservation. Some projects describe their goal simply as understanding how a game was made, like the experimental Breath of the Wild decompilation.

When the port launched in May 2024, Digital Foundry's Alexander Battaglia called it an amazing fan effort and predicted it would be the herald of many new N64 ports for PC.

You can browse everything in our catalog on the decompilations hub, or jump to a platform: N64, PlayStation or Xbox 360.

Where AI comes in

Decompilation used to be limited by people-hours. That is now changing, because AI turns out to be well suited to the slowest step, matching functions one by one:

• A perfect referee. A compiler builds the AI's code and a diff tool compares it with the original bytes, so a wrong answer cannot pass and nobody has to trust the model.
• Unattended work. Developers now run AI function by function with no human in the loop, and report progress in weeks that used to take months.
• Limits. People still choose the compiler, set up the project, review the code and watch for shortcuts, and the figures so far come from the projects themselves.

A short history

The dates below are those of public repositories and releases, not of the first private experiments.

• 2013 and 2015. The pret community's Pokémon Red/Blue disassembly repository is created in 2013, and its Pokémon Emerald decompilation in 2015.
• 2019. The NSA releases Ghidra as open source, putting a capable decompiler in everyone's hands. In June, the Super Mario 64 decompilation repository is created.
• 2020. The Ocarina of Time decompilation repository is created in March.
• 2021. decomp.me is created as a collaborative decompilation website.
• 2022 to 2024. The N64Recomp repository appears in 2022. In May 2024, Zelda 64: Recompiled has its first release.
• 2024 and 2025. The XenonRecomp tool for Xbox 360 games appears in September 2024, and UnleashedRecomp has its first release in March 2025.
• 2025 and 2026. Developers begin publishing results with AI doing the matching: chat-driven in early 2025, unattended loops by December 2025, and tool-equipped agents in 2026, as covered in our AI article. In September 2026 the IW4L repository is created, a Rust and Bevy engine for Modern Warfare 2 that its README says was written entirely by an LLM.

Is it legal?

This is not legal advice, and the answer depends on the country, the purpose and what is shared.

• What projects publish. Generally, the contributors' own code, not the game. You supply your own copy for the game's assets.
• Who owns what. The code contributors write is licensed by them. The original game's code and assets remain the property of their rights holders, which is why each project page in our catalog has a "Licensing by party" card with what the repository itself states.
• The legal background. One overview points to US cases such as Sega v. Accolade, where disassembly for interoperability was treated as fair use, and to the EU Software Directive's provision allowing decompilation for interoperability within limits. It stresses that distributing a reconstructed game is a different matter and that using AI adds no general exception. Engine rewrites such as IW4L sit in similar territory: they ship no game assets and need your own copy, but their legal position is described as unsettled.

How to try one yourself

1. Pick a project on the decompilations hub, filtered by the platform of the original game.
2. Read "What you need to run it" on its page. Almost every project needs your own copy of the game.
3. Follow its install steps. Many recompilation projects ship a ready-to-run build that asks for your game file the first time; decompilations are usually built from source.
4. Check the licensing card if you plan to redistribute anything.

Sources and method

Project facts come from each project's own README, as summarized on its page in our catalog. Dates are those of the public GitHub repositories and releases. The recompilation details come from the N64Recomp README and the developer interview linked above. The AI figures and their sources are listed in our AI article. The Rust and Bevy section draws on the IW4L README, wiki and agent notes, the README of the mashup fork and the Held Games article linked there. All of their figures are reported by the authors themselves. Our general approach is described on the methodology page.