Me before the comma: Good luck to them, more options can’t be a bad thing.
Me after the comma: I intend to wipe the existence of your useless company from my memory entirely, so I’m just going to point and laugh at your failure in advance and immediately move on with my life.
Through this lens it became clear: stablecoins will become a financial backbone for the $500B global gaming economy.
The people interested in alternatives to SteamOS for Linux gaming probably aren’t going to be the sort of people who are interested in cryptocurrency or more micro transactions. I don’t think they have much of a clue what their target audience likes.
Even giving them the benefit of the doubt, is there any game dev or gamer currently dissatisfied with existing payment systems? Are people in certain countries struggling with the mechanics of paymernt? Like, there are tons of ways to shoehorn in random charges or in-game ownership systems, and I don’t see what crypto brings other than moving the purse-holder.
Again, devil’s avocate: one could argue current platform fees (30%) are very high, but this is more of a monopolization issue than a fundamental payment system one,
At first I was like “Why would anyone want to change OoT’s art and mess with perfection?”, but I do have to admit that I have really been craving a modern Zelda game in the vein of the N64 releases, which is a formula they haven’t touched since Skyward Sword in 2011. And Oblivion just recently showed me that sometimes a new coat of paint really is all you need.
Wind Waker at least is a game that (visually) aged very gracefully and I think can still stand against newer games even now, but I’ve played it to death and just wish we had something new.
Also not to discredit BotW/TotK or anything, I think they are still great games and I also really enjoyed them, but they’re just built different. Zelda is now a franchise of 3 distinct styles, but only two of them (2D and open world) are still getting new releases.
This is the video I didn’t know I was looking for in life.
I’ve been very into Zelda rando stuff lately, but the mod support shown here just seems above and beyond what I’ve seen so far from my limited experience with Ship/2Ship.
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).
gamingonlinux.com
Aktywne