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).
To you who have played Monster Train and are in the loop about Monster Train 2: should I play monster train 1, or does Monster Train 2 seem to be just a better version of it and I can wait for it?
Monster Train 2 is pretty similar, I’d recommend playing the first game since it gets really cheap on sale.
Play the first game without the DLC first (it can be toggled in the settings if you bought it). It changes the balance a lot and makes the game more difficult, so it’s more intended for people that are already familiar with the game.
For people unfamiliar with their games: Their first one “Gravity Bone” is free on steam. It is super short and almost 20 years old, but it shows off their style and humor very well. Loved their games ever since.
gamingonlinux.com
Aktywne