Zelda 64: Recompiled is a project to play The Legend of Zelda: Majora's Mask on modern platforms with many new features, enhancements and now modding support too.
Not really. The Ship of Harkinian ports are based on decompilations, which is where you reverse engineer some equivalent source code using the final binary as a reference point. Then, you can port that source code to anything else you can build for, like a PC, phone, Wii U or Dreamcast.
Recompilation, which is what this project is, is closer to (and some have gone as far as to say that it is) emulation. It’s taking the final binary and then, without actually working backward to get source code, translating the raw instructions directly into code that compiles for a different platform.
It’s kind of difficult to get across the difference without being familiar with what both are doing behind the scenes, because the result is obviously similar. Both require human intervention, but decompilation is the more labor-intensive approach, while recompilation is somewhat more automated.
The advantage of former is that you end up with a relatively human-readable codebase to work with, while the latter doesn’t bring you any closer to understanding how the game works internally. Both ultimately allow for porting the game to new platforms. Decompilation will almost certainly result in a more optimized final game, because it avoids the overhead of “emulating” the original architecture. However, for the same reason, recompilation can be generalized to other games that originally ran on the same hardware.
Thank you for the detailed explanation! I had thought Ship was decompiling and recompiling it into its own package, but what you describe makes more sense.
Ship of Harkinian does indeed get recompiled but the steps before recompilation are more accurately described as decompiling.
The Majoras Mask recomp might be better described as “automated recompilation”, implying there was no/limited human involvement in the _de_compilation step first.
So similar to how WINE works then? This is taking the MM binary and building a wrapper around it that translates it’s system calls into something generic?
That’s closer but rather than being a wrapper, it takes the original architecture’s instructions (MIPS in the case of N64) and generates a C/C++ function which implements that instruction. Then you call those functions in the same sequence as the original compiled machine code ran instructions.
That’s a relatively inefficient way to make a port, because you’re basically reimplementing the original CPU in software, hence why some have described it as emulation. At the same time though, most recompiled games are like 15-20 years old, so a bit of overhead on a modern PC isn’t going to hurt you too much.
But anyway, unlike WINE, the original binary is not used any more after recompilation. Instead, you have a native binary for the target platform, the translation having occurred at the time of recompilation (when you built the port binary).
Is this similar to the Ship of Harkinian recompiles, just as a different project?
Not really. The Ship of Harkinian ports are based on decompilations, which is where you reverse engineer some equivalent source code using the final binary as a reference point. Then, you can port that source code to anything else you can build for, like a PC, phone, Wii U or Dreamcast.
Recompilation, which is what this project is, is closer to (and some have gone as far as to say that it is) emulation. It’s taking the final binary and then, without actually working backward to get source code, translating the raw instructions directly into code that compiles for a different platform.
It’s kind of difficult to get across the difference without being familiar with what both are doing behind the scenes, because the result is obviously similar. Both require human intervention, but decompilation is the more labor-intensive approach, while recompilation is somewhat more automated.
The advantage of former is that you end up with a relatively human-readable codebase to work with, while the latter doesn’t bring you any closer to understanding how the game works internally. Both ultimately allow for porting the game to new platforms. Decompilation will almost certainly result in a more optimized final game, because it avoids the overhead of “emulating” the original architecture. However, for the same reason, recompilation can be generalized to other games that originally ran on the same hardware.
Thank you for the detailed explanation! I had thought Ship was decompiling and recompiling it into its own package, but what you describe makes more sense.
Ship of Harkinian does indeed get recompiled but the steps before recompilation are more accurately described as decompiling.
The Majoras Mask recomp might be better described as “automated recompilation”, implying there was no/limited human involvement in the _de_compilation step first.
So similar to how WINE works then? This is taking the MM binary and building a wrapper around it that translates it’s system calls into something generic?
That’s closer but rather than being a wrapper, it takes the original architecture’s instructions (MIPS in the case of N64) and generates a C/C++ function which implements that instruction. Then you call those functions in the same sequence as the original compiled machine code ran instructions.
That’s a relatively inefficient way to make a port, because you’re basically reimplementing the original CPU in software, hence why some have described it as emulation. At the same time though, most recompiled games are like 15-20 years old, so a bit of overhead on a modern PC isn’t going to hurt you too much.
But anyway, unlike WINE, the original binary is not used any more after recompilation. Instead, you have a native binary for the target platform, the translation having occurred at the time of recompilation (when you built the port binary).
OK, now I understand! And I get why they say the code isn’t human readable, haha. Thanks for taking time to explain!