Game Preservation: Four Engineering Paths That Put an Old Game on a Modern PC

By Indie Kings | October 19, 2026

Updated October 19, 2026: The same old game can reach a modern PC by four different engineering routes, and each route produces a different artifact: an emulator that simulates the console, a static recompiler that translates the console's instructions into native code ahead of time, a decompilation that rebuilds readable source, or an official remaster that writes new code around the original assets. The sentence "I am playing SoulSilver on PC" can describe the first three without telling you which one is actually running.

N64Recomp GitHub repository preview card

Image: N64Recomp repository preview card generated by GitHub. Credit: N64Recomp project/GitHub.

Four paths behind one sentence

A player who says "SoulSilver on PC" may mean a DS emulator loading a ROM, a static recompilation that turns the game's ARM9 code into C++ and runs it natively, or a source port built from a decompilation. Those are not three labels for one thing. They are three different artifacts with different inputs, different build steps and different things the user has to supply.

The fourth path is commercial: an official remaster, where the rights holder builds new code around the original assets. No community README documents that route because it starts with a license, not a toolchain. But it belongs in the same taxonomy, because it answers the same player request with yet another kind of artifact.

The distinction matters because the paths fail in different ways. An emulator can be accurate and slow, or fast and approximate. A recompilation can be fast and still depend on a simulated console for everything the recompiler did not translate. A decompilation can be edited, which is either the point or a liability depending on who is asking. A remaster can change the game and still be official. None of those outcomes is interchangeable with the others.

Emulation: simulate the machine

Per the official Dolphin README, Dolphin is an emulator for running GameCube and Wii games on Windows, Linux, macOS and recent Android devices, licensed under the GNU General Public License, version 2 or later. That definition is the engineering contract: the game is not converted, rebuilt or shipped with the emulator. The emulator provides a simulated console, and the unmodified game image runs inside it.

The README also shows that emulation has its own fidelity dial. For audio, Dolphin offers HLE and LLE engines: HLE is faster but less accurate, LLE is slower but close to perfect. That trade-off is the daily work of the path, because every subsystem has to be modeled well enough for software written against exact hardware behavior.

The requirements Dolphin lists are hardware requirements, not conversion steps: a CPU with SSE2 support, a modern dual-core running around 3 GHz, and a graphics card supporting Direct3D 11.1 or OpenGL 3.3. Nothing in that list turns a disc into a native executable. The disc image stays an input for as long as the emulator runs.

This is what "fakes the machine" means in practice. The original instructions execute, but they execute on a model of the console rather than on the console's own silicon. Accuracy is a property of the model, and performance is the cost of building that model in software.

Static recompilation: translate the instructions

Per the official N64Recomp README, the tool statically recompiles N64 binaries into C code that can be compiled for any platform, for ports and tools, or for simulating behavior significantly faster than interpreters or dynamic recompilation can. The key word is statically: the translation happens ahead of time, before the game runs, not instruction by instruction during play.

The README describes a deliberately literal translation. Instructions are processed one at a time and matching C is emitted for each one. The MIPS instruction addiu $r4, $r4, 0x20 becomes ctx->r4 = ADD32(ctx->r4, 0X20);. A jal jump-and-link becomes a function call. Branch delay slots are handled by duplicating instructions where necessary, and a jr instruction becomes a switch-case statement when the recompiler can tell it is being used with a jump table.

That output is not readable game source. It preserves the shape of the machine code, with each output function emitted into its own file and named according to metadata supplied to the tool. The metadata currently has to arrive as an ELF file, which the README says is easiest to obtain by setting up a disassembly or decompilation of the target binary.

The generated C still needs a runtime. Per the README, the output expects a runtime that provides the necessary functionality and macro implementations, and the project supplies one in N64ModernRuntime. The output has been compiled with msvc, gcc and clang, so the compiler is not the hard part. The hard part is everything around the translated CPU code.

ssrecomp shows the same pattern on the Nintendo DS. Per its README, the game's ARM9 code is statically recompiled to C++ from the build output of the pret/pokeheartgold decompilation, while a patched melonDS core supplies the DS hardware: graphics, sound, cartridge, save memory and the ARM7. The recompiled game logic runs natively. The handheld around it is still simulated.

Decompilation and source ports: rebuild the game

Decompilation starts from the opposite direction. Instead of translating machine instructions into generated C, a matching decompilation reconstructs source code that builds back into the original ROM. Per the ssrecomp README, the decompilation route rebuilds the game from its source, and the result has to be byte-for-byte identical to the retail cartridge, which the builder can check against a dump of their own copy using the published SHA-1.

That byte-for-byte target is the discipline that separates a decompilation from a loose remake. The source has to compile back to the same ROM before it is trusted as a representation of the game. Once it does, the project has something the recompiler does not produce: human-structured code with named functions, types and comments that can be read and changed.

The README states the practical difference directly: if you want to change the game itself, build from the decompilation instead. The direct-ROM route exists for running the game: it uses a layout file that holds addresses and checksums, and the README says the generated code is identical to the decompilation build's. The source route exists for editing it.

A source port takes that editable source one step further. The game's own code is rebuilt against a new platform layer, replacing console-specific graphics, input, audio and save handling with native equivalents. The result is not a translated binary and not a simulated console. It is the game's source, compiled for a machine the original developers never targeted.

Official remasters: new code, old assets

In this taxonomy, the fourth path does not begin with a repository. It begins with the rights holder deciding to sell the game again. The original assets are licensed or reused, a new engine and new platform code are written around them, and the result ships as a commercial product rather than as a build guide.

Nothing in this path requires the original executable to run. The continuity is the assets, the design and the name, not the machine code. That is why a remaster can raise the frame rate, change the resolution, redraw the interface, add accessibility options or alter controls without becoming a different category of product.

It is also why a remaster can be less faithful than an emulator. Fidelity is a product decision in this path, not a constraint imposed by the original binary. The engineering question shifts from "how do we preserve this behavior" to "which behaviors do we choose to keep, and which do we replace."

The four paths side by side

Path	What is translated	Typical input	What the user supplies	Result
Emulation	Nothing ahead of time; console hardware behavior is simulated while the original code runs	A game image plus an emulator build for the target platform	The game image the emulator reads; the README does not describe obtaining it	An emulator binary and the unchanged game image
Static recompilation	Each machine instruction, translated ahead of time into C or C++ and compiled natively	A game binary plus symbol and metadata input, typically an ELF from a disassembly or decompilation	Their own dumped copy where the project requires it, plus a compiler and build tools	A native executable generated from the binary, running on a runtime that supplies the rest of the console
Decompilation plus source port	The game's machine code, reconstructed as readable source that builds back to a matching ROM, then rebuilt against a new platform layer	A matching decompilation project and the original ROM for verification	Their own copy to check the rebuild, plus a compiler and the project's build requirements	An editable source tree, and from it a native port
Official remaster	Nothing directly; new code is written around the original or reworked assets	Licensed assets, design materials and whatever code the rights holder chooses to reuse	The purchase, with no build step and no dump required	A new commercial release for the platforms the publisher chooses

The first two rows run code that originates in the original binary. The third replaces the binary with source. The fourth replaces the code while keeping the assets. That is the cleanest way to hear the difference when someone uses the word "port" for all four.

Why real projects mix the paths

ssrecomp is the clearest example of why the categories are not sealed boxes. Per its README, it is a native build of Pokémon SoulSilver with ARM9 code recompiled to C++, sitting on a melonDS core that still emulates the DS hardware, including the ARM7. The project is a recompilation and an emulation stack at the same time, split by CPU and by subsystem.

N64Recomp shows the same layering from the other side. The recompiler translates CPU instructions, but its output expects a runtime for the platform work the translation does not cover. A static recompilation removes the instruction interpreter, not the need to provide the machine around the code.

Dolphin makes the point inside emulation itself. The README's HLE and LLE audio engines are two answers to the same fidelity question, and neither one changes the fact that the game image is being run rather than rebuilt. The categories describe what is translated and what is simulated, not what a project is called.

What the READMEs do not settle

The ssrecomp README is explicit that the repository contains no game code or data, and its quick start says the user needs their own copy of Pokémon SoulSilver (US) as a .nds file dumped from their cartridge. It also says the generated game folder must not be committed, along with ROMs, saves and save states. Those are project rules stated in the project's own documentation.

N64Recomp's README describes a compiler input, a binary with symbols and metadata, and does not say where that binary comes from. That omission is not an answer either way. It means the README documents the translation step and leaves the provenance of the input outside its scope.

Whether any of these paths is lawful where a reader lives is a separate question, and it is not resolved by these documents. A README is a build guide, not a license. Where a project states a requirement, the requirement is a user's own dumped copy, and no project cited here ships game data. Beyond that, the legal question stays open rather than being settled by technical description.

Our take: the useful question is not whether a project counts as an emulator, but what it translated and what it still simulates. By that test, ssrecomp is a recompiled game on an emulated handheld, N64Recomp is a translator that hands the rest of the console to a runtime, and a remaster is a new product wearing old assets. The labels are less interesting than the boundary lines.

FAQ

Is static recompilation just emulation with extra steps?
No. Emulation simulates the console while the original code runs. Static recompilation translates the console's instructions into C or C++ ahead of time and compiles them for the target machine, which is why N64Recomp's README can describe it as faster than interpreters or dynamic recompilation. In practice a recompiled game can still sit on simulated hardware, as ssrecomp does with its melonDS core.

Why does a recompiled game still need a runtime?
Because the translation covers CPU instructions, not the whole console. Per the N64Recomp README, the generated C expects a runtime that provides the necessary functionality and macro implementations, and the project supplies one in N64ModernRuntime. Graphics, audio, input and timing still have to be provided by something.

What does decompilation give me that recompilation does not?
Readable, structured source that can be edited and rebuilt. The ssrecomp README says that if you want to change the game itself, you should build from the decompilation instead of the direct-ROM route. Recompiler output mirrors the machine code, with generated functions emitted into their own files, which is efficient for a compiler and awkward for a person.

Can I use a ROM I already have?
That depends on the project. The ssrecomp README requires your own copy of Pokémon SoulSilver (US) as a .nds file dumped from your cartridge. N64Recomp instead takes an N64 binary plus ELF metadata, and its README does not describe a ROM download step at all. Whether using a particular dump is permitted is a separate legal question.

Is a source port the same thing as a remaster?
No. A source port rebuilds the game's decompiled source against a new platform layer. A remaster is new code written around the original assets by the rights holder. Both can ship as native code, but the provenance of that code is different, and only the remaster is distributed by the rights holder.

Is any of this legal?
That question is separate from the engineering and it is unresolved here. The cited READMEs describe build processes, not licenses, and the ssrecomp README states that its repository contains no game code or data. Where a project states a requirement, it asks for a dump of your own copy, but a README cannot settle the law in your jurisdiction.

Bottom Line

Four preservation paths, four artifacts. Emulation simulates the console and runs the original image. Static recompilation translates the console's instructions into native code ahead of time, then leans on a runtime for the rest of the machine. Decompilation rebuilds readable source that compiles back to a matching ROM, which is what makes a source port possible. An official remaster writes new code around original assets and sells the result. The technologies can mix, as ssrecomp's recompiled ARM9 running on a melonDS core shows, but the inputs and the outputs stay distinct. The legal question is separate and unresolved, and where a project states a requirement, it is a user's own dumped copy.