Decomps & Recomps in 2026

There are a lot of misconceptions about decompilation and recompilation in the retro game scene. Some believe decompilations are inherently more accurate, easier to modify, or better for game preservation. Others dismiss recompilations as little more than emulators.

I've spent years reverse engineering games, and more recently I've been developing recompilation tools and helping others use them. I think much of this discussion misses the point.

Neither approach guarantees accuracy, modding potential, or preservation. What matters is how developers use these tools.

What are decompilation and recompilation?

A decompilation attempts to recover source code from a game's machine instructions. A static recompilation translates those instructions into code that can be compiled for another system.

Importantly, neither one is automatically a PC port. They're methods of working with a game's code. Turning that code into a playable PC game requires additional work.

Let's imagine we recovered a function that controls Mario's jump.

A basic decompilation, perhaps generated by an AI-assisted tool, might look like this:

void func_1234() {
    x = -y;
}

We can see what the code does, but the names tell us nothing about its purpose. Today, automated tools and AI can help produce this kind of first-pass result. Historically, developers had to do much more of this recovery work themselves through effectively brute forcing.

After studying the game, someone might give the function and its variables meaningful names:

void MarioJump() {
    marioVerticalSpeed = -jumpStrength;
}

Now we can immediately understand what this function controls. This is an annotated decompilation, where someone has identified and documented what the game's code does.

Both examples can compile into the exact same machine-code bytes. Variable and function names exist to help humans understand the code. Changing those names doesn't change the machine instructions produced by the compiler.

A static recompilation might instead produce something like this:

void translated_1234() {
    ram[0x20] = -ram[0x24];
}

These are simplified examples of the same basic operation. The recompilation doesn't need to understand what a jump is. It only needs to reproduce what the original instructions do.

A well-annotated decompilation is easier for a human to navigate. But both unannotated decompilations and recompilations lack that helpful documentation. We can also use knowledge from a decompilation to annotate a recompilation, combining the advantages of both.

Why I use "recompilation" as a catch-all term

There's a technical detail worth explaining. Many games on older systems like the NES, SNES, Genesis, and Game Boy were written in assembly language. Their code was assembled into machine instructions, rather than compiled from a language like C.

Strictly speaking, translating those games into C and compiling them for a modern computer isn't technically recompilation in the literal sense.

So what should we call it? Disassembly-based translation followed by native compilation? Assembled-then-compiled? Neither exactly rolls off the tongue.

I chose recompilation as a public-facing term because it communicates the idea without requiring people to understand the entire process. More precisely, my tools perform ahead-of-time static binary translation and provide outcomes similar to what people expect of recompilation ports today. The terminology is useful, but understanding what the tools accomplish matters far more.

A decompilation is not automatically more accurate

A matching decompilation can reproduce the original game's machine code exactly. That's an impressive achievement, but it doesn't guarantee that a PC port built from it will behave correctly.

Old games relied on very specific hardware. When developers move that code to modern computers, they still need to reproduce or replace things like graphics, sound, timing, and memory behavior.

A decompilation-based port can introduce bugs, break physics, or lose behaviors from the original game. A recompilation-based port can make those same mistakes.

A poorly implemented decompilation port can be less accurate than a well-implemented recompilation port. Neither approach automatically makes a good port.

Mega Man X's Magic Carpet

One example comes from my work with Mega Man X using snesrecomp.

The game contains a trick known as the Magic Carpet bug, used by speedrunners. I was able to reproduce this behavior in the recompiled game while running in its original 4:3 aspect ratio. The fact it was able to reproduce despite its port is a statement of faithfulness to the original game.

The game has seen extensive modifications since. Anything from X2 and X3 weapons, to Zero from X3 being backported, to Zero being given custom saber animations -- all the way up to widescreen.

Of all the things, it was widescreen that actually broke the magic carpet.

The trick works because the Heart Tank and the stage's first ten moving platforms share the same pool of sixteen object slots. When the Boomerang Cutter carries an item, it remembers which slot that item lives in. Collecting the heart frees its slot. If a platform gets created in that slot before the boomerang lets go of the reference, the platform inherits it and follows the boomerang. That's your carpet.

Widescreen needs objects to appear sooner, since you can see further. That moved when the platforms were created and removed, and it loaded the heart early, into a later slot, while the platforms already held the others. When the heart was collected, the platforms reused the first slot instead, so the stale reference couldn't capture one. It would have broken on real hardware too, if it could manage the wider screen.

But even still, given that I had a faithful foundation, I was able to restore it. In solo play, the platforms and the heart keep their original spawn timing. The extra widescreen margins draw those objects from ROM art without creating them in game memory. Now the magic carpet bug can be done in widescreen just the same, preserving a sense of authenticity to the original game while also offering modernizations.

To verify it, the same 1,800 controller inputs grab the platform on the same input, number 992, in Snes9x and in the recompiler at 4:3, 16:9 and 32:9. Before the fix, 16:9 never grabbed it.

This is why I prioritize accuracy in my recompilers. Once the original game works correctly, we can begin changing it while testing what those changes affect.

Recompilations aren't inherently less modifiable

A well-annotated decompilation is generally easier for a human to navigate. But that's largely because someone has already identified and explained the code.

That distinction is becoming increasingly important with AI.

Consider how someone discovers cheats using a tool like Cheat Engine. They might search for a health value in memory, take damage, search again, and repeat until they've identified the correct value. This process can involve hundreds or thousands of comparisons and multiple iterations from a human.

An AI agent with the right tools can automate that investigation, performing repetitive searches potentially thousands of times faster than someone doing them manually.

Now apply that same idea to understanding a game's code. Instead of searching for a health value, imagine trying to find the function responsible for jumping, enemy behavior, or the camera.

For a human, searching through thousands of unnamed functions and following how they interact can take days or even weeks. An AI agent can rapidly search code, trace instructions, compare values, run tests, and investigate possible matches. It isn't limited to memory searches, either.

It still needs verification, but the difficulty of navigating undocumented code is no longer the same obstacle it once was.

But plausible code isn't the same as correct code. A human in the loop can sanity-check a claim from the AI quickly, and that fast back-and-forth is where most of the time is saved. Automated verification backs it up: recorded inputs replayed through a reference emulator and the recompilation, traces compared, and tests re-run after every change.

What we're seeing today in recomps

Rather than pre-emptively dismissing what a recompilation can do, look at what's already being done.

These experiments include character swaps, new rendering techniques, and even connections between different games. They're all powered by recompilation.

The multiplayer experiments go further. I've demonstrated six-player Sonic 2, where every player has their own camera, and four-player cooperative Mario. My Mega Man X boss rush experiment features X and Zero playing together with independent cameras, widescreen, and online netplay.

Another experiment brings Mario into Tomba! 2, a completely different PlayStation game.

These projects demonstrate changes far beyond what the original consoles supported. A decompilation could also support ambitious modifications like these, and that's exactly the point.

The approach doesn't set hard limits on what's possible. It does shape the workflow, the effort, and the cost of maintaining it.

A well-annotated decompilation offers more than renamed functions. It can reconstruct meaningful structures and the relationships between gameplay systems, and changes can be made directly in source. In my recompilations, mods never modify the ROM or the recompiled output. They hook the game's functions and memory through the runtime. Similar changes are possible either way, but they take different tools and techniques.

Going beyond the ROM

Recompilation also lets us step outside the original hardware's constraints, not just its screen size. Translation is a good example.

Gundam Wing: Endless Duel was only released in Japan. Fan translations exist in English (Aeon Genesis) and Spanish (Max1323), but a ROM patch is limited to what fits in the cartridge, including its font. There's no room for accented characters, let alone Korean, Chinese, or Thai.

Endless Duel Recompiled ships eleven languages, counting the original Japanese. The runtime patches the assets the game itself reads: ROM bytes, tile art as it's uploaded to video memory, and text in RAM. Each patch is guarded so it only applies when the bytes match exactly. The game's own engine then draws them, so fades, slides and typewriter effects all just work. Your ROM file is never modified.

French, Italian and Portuguese get accented letters added to the dialogue font. Korean and Chinese are delivered as pages of 16×16 glyphs written into unused video memory for each line of dialogue. Thai goes further: because its marks stack above and below the letters, each line is rendered as an image and sliced into tiles. Thai is still partial; the title menu and the opening text crawl remain in English.

It's the same idea as bringing Zero into Mega Man X from your own copy of X3, or adding a Boss Rush to the title menu. The runtime has direct, guarded access to the game's memory, so new content can go exactly where the game already looks for it.

Are these just "prepackaged emulators"?

Sometimes recompilation projects are dismissed as "prepackaged emulators," as though it's some sort of criticism implying these are incapable of extensibility. It's a strange semantic that doesn't at all represent what is being implied.

Words have both a denotation, their literal meaning, and a connotation, what people associate with them.

To emulate something is to imitate or reproduce its behavior. In computing, an emulator recreates the behavior of another system. By that broad meaning, even a native port built from a decompilation are emulating the game's behavior. That's the entire point, isn't it?

But when people hear "emulator" in gaming, they usually imagine a program that loads an old ROM and runs it by pretending to be the original console.

Calling something a "prepackaged emulator" creates the impression that someone simply bundled a ROM with an emulator core and called it a PC port.

If that were true, none of the showcases above would be realistically possible.

To be fair, emulators have mods, netplay and widescreen too, but they work within the game's confines. Netplay keeps everyone on one shared screen; it can't give each player an independent view like the six-player Sonic 2 above. Widescreen hacks often extend the background, but enemies still spawn as if the screen were 4:3. Emulator mods tend to be visual replacements or hooks, and ROM hacks are bound by the cartridge's space and hardware.

What actually separates a static recompilation is how the game's code executes. An emulator fetches and decodes each guest instruction while the game runs. A static recompilation translates those instructions ahead of time into native code that a normal compiler builds once. What remains at runtime is a hardware layer for graphics, audio, timing and memory, plus a fallback interpreter for any code that couldn't be found ahead of time.

How my approach works

My recompilers do have traditional components of emulation inside of them. They're a sort of a hybrid. The primary starting differentiator is the ahead of time nativization of the code.

Since my recompilers aim to be a foundation for all games for the system, it will include a set of correctness beyond what an individual game may need. But it's all permitted to be extensible. Add to it, remove from it. Adjust it to your game's needs.

This provides opportunities for optimization and makes it practical to modify or replace individual systems. We can change the renderer, remove hardware restrictions, and adapt components for individual games.

For example, when I originally stood up Tomba, I did not have simulated cycle accounting in psxrecomp. Everything would resolve as fast as possible, and it often led to softlocks. I had to implement that to ensure that Tomba would behave. Ape Escape, on the other hand, was able to handle some changes in timing. In fact, removing some of the simulated accounting actually allowed it to speed up in areas that it would slow down on in original hardware. This is a great applied example of where it was important to one game while a hindrance to another. My recompilers are a safe baseline, but not necessarily a one-shot end result for every game.

In Tomba's case however, once I had that accurate baseline, I was able to then optimize it. In the end, I ended up actually pre-loading assets onto disk and replacing the load screen altogether to replace load screens outright, giving an experience that is effectively, if not faster than, cartridge load times for an original PSX game.

This approach also makes reusable tools possible. Projects like recomp-net provide networking support that multiple recompilation ecosystems can use. Developers who use these platforms get infrastructure and integrations like netplay effectively for free and don't have to recreate netplay logic themselves from the ground up.

Trying to draw semantics around whether something is a [traditional] emulator or not is a misnomer. It doesn't help define anything's limitations or intents.

Preservation isn't a competition

I also disagree with the idea that recompilation or AI-assisted development somehow takes away from traditional game preservation.

There are several valuable things we can preserve:

1. Original game binary: The ROM, disc image, or executable that preserves the released game data.
2. Game recompilation: A translated version that provides another way to run, study, and modify the game.
3. Game decompilation: Recovered source code that helps us study the game's original implementation.
4. Annotated decompilation: Recovered code enriched with meaningful names, explanations, and documentation.

These aren't necessarily steps that replace one another. They're different resources that can coexist.

In traditional archaeology, studying a physical site can sometimes damage or disturb it. Digital reverse engineering is different. Studying a copy of a ROM or disc image doesn't consume or damage the original data. We can investigate the same game through multiple approaches without taking anything away from another project.

Creating a recompilation doesn't destroy a decompilation. Using AI doesn't prevent someone else from conducting traditional research.

Of course, proper documentation and preservation still matter. But more ways to understand and experience a game are a benefit to preservation, not a threat to it.

The goal should be more games, not fewer tools

Traditional decompilation has produced incredible work, and it will continue to be valuable. So will emulation, recompilation, and AI-assisted reverse engineering. These approaches can complement one another.

What excites me most is that we're beginning to see games receive attention that might never have been decompiled or recompiled in our lifetimes.

Historically, reverse engineering a single game could require a team years of dedicated work. That made it difficult for smaller games, less popular games, or entire libraries to receive the same attention as major titles.

Modern tooling, including AI, is changing what's practical. Projects that once seemed unrealistic are becoming possible for smaller teams, sometimes even individual developers.

Through RetroPortingToolkit, my goal is to lower the barrier to entry for this work, make our tools reusable, and encourage more developers to participate and contribute.

We should celebrate the fact that more games are being explored, preserved, and brought to modern hardware. These are opportunities we might otherwise never have had.

Neither approach imposes hard limits on what developers can accomplish. They do shape the workflow, the complexity, and the long-term maintenance.

We shouldn't judge a project by whether it started with decompilation or recompilation. We should judge it by what it accomplishes, how well it works, and what it contributes to the future of these games.