Emulation and direct translation: what’s the difference?
An older game can reach a new device through an emulator or a recompilation project. The distinction starts with how each handles the original program.
By zing · Published · Sources checked
The difference is how the original program is handled
An older game was written for the processor and hardware behavior of its original machine. A new computer or phone often cannot use those instructions and hardware interactions directly.
An emulator provides the behavior the original machine needs while the game runs. Static recompilation converts the original program ahead of time, then compiles the result into a program for the new platform.
This article uses “direct translation” to mean static recompilation, as found in some game porting projects. Other projects may use the phrase differently.
Emulation: handle the original machine’s rules at runtime
A running game continually performs calculations, draws graphics, plays sound and reads input. An emulator makes these operations work on new hardware according to the original machine’s rules. When a game accesses its original graphics hardware, for example, the emulator must reproduce the relevant behavior using the new device.
An emulator may interpret the original program or translate blocks of instructions into code the new processor can execute. This work happens at runtime, alongside the coordination of graphics, sound and other components.
An emulator therefore typically serves multiple games from a platform. Dolphin targets GameCube and Wii games. Individual games use hardware differently, so compatibility and device requirements can vary.
Sources: Dolphin’s official FAQ · Dolphin’s JIT implementation
Static recompilation: convert ahead of time, then build a new program
Static recompilation moves part of the work to before the game runs. A tool analyzes the original program, converts its instructions into another form of code, and uses a compiler to produce a program for the new platform.
N64Recomp, for example, converts N64 code into C code for subsequent compilation. Players may receive a release that has already gone through these steps, without having to operate the conversion tool themselves.
Converting instructions ahead of time solves part of the problem. Graphics, sound and controls still need a suitable runtime, and individual games need adaptation. A recompilation project may therefore support only a particular revision of one game. Giving it another game will not automatically produce a finished port.
Program conversion also does not supply maps, music or textures. Zelda64Recomp, for example, explicitly states that its prebuilt binaries contain no game assets.
Why “emulation is slow, translation is fast” is too simple
Emulators can use translation too. Just-in-time compilation translates instructions while a program runs; Dolphin includes such an implementation. Emulation and translation can therefore belong to the same setup.
Static recompilation performs some conversion in advance, potentially reducing that work at runtime. Graphics processing, adaptation quality and hardware still affect performance. Either approach can encounter visual errors or crashes, so its name alone cannot guarantee the experience.
The more useful distinction is that an emulator organizes execution around the original platform’s behavior, while static recompilation transforms the original program’s code ahead of time. The timing and approach differ, and a particular project may combine related techniques.
Sources: Dolphin’s JIT implementation · N64Recomp’s explanation