To operate this tool, you still need to disassemble the ROM up front and annotate it heavily before it can be recompiled. This tool is very nice, to be sure, but the hyperbole about anything close to one-click generation of standalone executables for an arbitrary ROM is getting out of hand.
To be fair, N64 is not the PS2 or Gameboy--there are only 388 games that were released for it. Going through all of the games that were released and shepherding them through this process is feasible.
I think "but using the tool takes time and effort" is a good but not perfect criticism of a tool that purports to reduce time and effort spent. As many asinine CEOs are making outsized claims about generic "productivity" improvements from various tools in this space and similar ones all the time, I get this instinct. However, it does not make sense when the use of the tool is anything other than "something you could already do, just faster"
This is really cool. Many of the foundational tools created for N64 decomp are finding their way into other system decomp packages. I recently came across https://decomp.me/ which allows collaborative decompilarion for a bunch of systems with presets for their relevant SDKs and hardware. I’d imagine this happening several more systems in the coming years.
I saw this when it came out, and as someone that doesn't follow the ROM hacking scene, I'm wondering - why did this approach take so long to come up with? Translating the assembly instructions to C and then recompiling them seems like an obvious method to try early on, but I'm wondering if there was some other breakthrough that made this possible in a way it wasn't before?
The N64 has a GPU, which is not the same as modern GPUs, and you need that GPU to render graphics.
Skimming the Github repo, looks like this uses rt64 under the hood for the raytracing support ( https://github.com/rt64/rt64 ), and that uses the ubershader technique to emulate the GPU. This excellent article talks about the what, why, and insanity that are ubershaders: https://dolphin-emu.org/blog/2017/07/30/ubershaders/
Other emulators want to solve the problem generically, and this solution doesn't quite.
Static recompilation from one machine language to one other language is somewhere between extremely difficult to not being generally possible in practice [1]. To make recompiling something like this properly, you need some help from the binaries that make recompilation easier [2] and on top of that you need to patch certain things to make this work [3].
Dynamic recompilation doesn't have this problem. It allows you to create software you can dump the original binaries+assets ("ROMs") in and it will generally emulate it.
There's a lot of confusion about how generic this solution it. It's extremely impressive in how much work it saves making recompilations/"ports" much easier, and it will be very valuable. But it is not able to replace the need for traditional emulators.
[2]: N64 game binaries may happen to avoid a bunch of things that make general static recompilation hard that help this approach, but I don't actually know.
Emulating the hardware usually requires cycle-accurate emulation of things running in parallel, so it's not quite so simple as just the program in the ROM.
>Jamulator did this for NES way back in 2013 but nobody really seemed to care...
At least Mr WiseGuy seems to care. From the N64Recom Github repo[0]:
"This is not the first project that uses static recompilation on game console binaries. A well known example is jamulator, which targets NES binaries."
Jamulator was unsuccessful because so much extra hardware was on the cartridges. Recompilation complicates things and doesn't provide many benefits in that situation.
The N64 is fixed hardware, so it's a little bit easier. Even so, this project still uses emulation for the RDP. I don't know how it handles generated RSP microcode, maybe it doesn't. A lot of games just used the official libraries.
Jamulator didn't take it farther than what NES emulators could do beyond the way it ran. If Jamulator had released with similar enhancements for Zelda it probably would have been a lot more popular. I.e. the interest is more from what is now available with it than about how it does it.
That's just Nerrel, a real person, narrating. It's crazy (in an interesting way, not necessarily a doom and gloom way) how we have AI voices these days so good we start to suspect people who don't speak like we expect are AI.
I wish all game executables would be OS agnostic, something similar to WebAssembly: GameAssembly. For example you can no longer play 32-bit games on new macOS version, neither 32-bit Windows games under Wine. It's almost impossible to find 64-bit .exe files so they can run under fine under Wine/Crossover.
The code running on the CPU is arguably the smaller problem when it comes to games: At least for consoles, they're often depending on very low-level GPU implementation details, especially for older titles and platform exclusives.
Older consoles had even more dedicated chips doing relevant stuff other than "simple" I/O, like e.g. the SNES's sound chip, which was a completely independent CPU running its own little programs in parallel with the CPU and GPU.
Of course you could "mandate" a high-level VM for all future game development, but given the static nature of console hardware specs, that wouldn't be competitive for titles wanting to make use of cutting-edge graphics.
It is not enough to provide portable machine code to make games portable, there are lot of different APIs that games need: graphics API, windows API, input API, sound API, disk API and so on. Sometimes they need kernel modules for anti-cheat and anti-piracy features.
What saddens me is that open-source OSes do not want to provide a common set of APIs so that the developer only has to write and test the code once and it works everywhere. There is flatpak, but as I understand, it doesn't provide a set of APIs, it simply packs a Linux distribution into a virtual machine without any specifications or documentation. So ugly, and no compatibility for smaller non-Linux OSes.
I was able to run 32-bit Windows games in Wine on Mac, even on Apple Silicon. GTA IV on my M1 mini. There's some kind of "32 on 64" emulation built into whatever version of the 32-bit Wine that PlayOnMac installs. Impossible to Google so idk how it really works.
It's funny how the Mac is more compatible with old Windows programs than old Mac programs.
The JVM does this pretty well for Minecraft. I doubt Minecraft would support Linux, the BSDs, etc without it. Bedrock edition (the not-JVM version which supports Windows and consoles/phones) doesn't even support MacOS even though it obviously could.
.NET would probably be as close as you can get given it allows you to have portable assemblies with pointers, structs and simd code which is very relevant to games.
It models statically-typed compiled languages in a much superior way to WASM, there are projects showcasing how well e.g. Rust maps to it[0], and C++/CLI existed for a long time (although it's not cross-platform, and is considered cursed).
C and C++ could be mapped in a perfect manner to IL and then AOT compiled in ways that GraalVM's Truffle can only dream of (given that .NET exposes a very wide set of intrinsics allowing a lot of code to be ported that way).
Wine (+ Steam's Proton) works incredibly well these days, a huge improvement from the old days when barely anything ran, and what did run required heavy tweaking or even custom compilation.
On Linux, my Steam library of about 300 games runs almost in its entirety without issues (except for Last Epoch).
I hope this eventually also works for Linux so that N64 games can be reliably played on very low end portable handhelds. N64 is notoriously tricky to emulate, but building them for the platform natively removes all performance problems.
Huh, I wouldn't have expected that. I don't know much about the specifics of N64 emulation, but I've had N64 emulators running perfectly since the early 2010s. I played mostly the big classics, so I'm unfamiliar with more niche title performance.
I watched the youtube video this article links to the other day and it mentioned that it supports Linux, specifically mentioning that it should be usable on Steam Deck.
That will likely require full decompilation. This is akin to wrapping the emulator up with the rom, with a few common functions (found via decompilation) being updated to support more modern rendering approaches. This isn't so much "native" as it is a patched container in an executable form.
EDIT -
But hey, you can always just add another layer of emulation via Proton to run it in Linux.
One thing this could be cool for is games like Goldeneye, which is hard to play on PC because it expects that weird joystick input. It would be awesome to have a native Goldeneye port with normal mouse behaviour like other FPSes.
WASD with mouse aim control doesn't really work with the game though.
The modal aspect of aiming combined with the travel time/return-to-center of the cursor is a really fun part of the game. If you could just free-aim while running a la PC FPS it would kind of ruin the campaign since everything is designed around this. Picking your spots and keeping cool while aiming are the appeal.
That said, if you keep the modal aspect and have the mouse just 1) rotate Bond like left/right on the stick does and 2) control the cursor only in "aim mode" (hit R)..then I think that could be fun.
Tbh, I wish shooters didn't go straight to Quake-style WASD+mouse free-aim across the board. The modal aspect makes gives Goldeneye a certain physicality I really like.
This is pretty neat; can someone tell me if this could lead to a proper working version of Conker on the MiSTer? E.g. could this be used to assist in a decompilation and then someone could make a fix?
What's the advantage over an emulator? This is after all, a form of an emulator - one where you translate ahead. This sort of thing has been done in the past with things like Bleem so it can be more performant but on a modern PC any good emulator is going to perform well.
The goals of this project and the goals of N64 emulation are fairly different.
The goal of N64 emulators (generally) is to accurately recreate the behavior of the original console.
Conversely, there is a large crowd of people who just want to play SM64, OOT and MM with a bevy of "graphical enhancements" like 60fps, widescreen, texture packs, randomizers, etc.
For these people, the fact that these games originally ran on the N64 is practically irrelevant. In fact, it's a hindrance; The N64's graphical pipeline is cumbersome to emulate and actively stands in the way of modern 'enhancements.'
This project is more aimed at giving the games themselves modern treatments, removing the N64-centric aspects of the games from the equation entirely.
A fair amount of 32-bit and later emulators do have JIT recompilation, but I'm not aware of any ahead-of-time translation unless that's how TeknoParrot works (you can run linux arcade games that use ELF binaries on windows with it for example), but I wouldn't call that emulation either way since the architecture is the same.
There are lots of emulation methods but interpretation is probably(?) the most common or at least very common.
Interpretation involves writing a VM that represents the state of various parts of the machine, and executes instructions that change the state of the VM, with varying levels of accuracy.
As an aside, the perfect dark decompile port is really nice to play on the steam deck. Not sure why, but the Linux version tends to freeze on the villa level. Switching to the windows version and using proton works great.
In theory it will work for anything, but there is a LOT of work that must be done to annotate the binaries on the source platform so that tooling such as this can pull it apart and reassemble all the pieces into something that works on the target platform.
A straight recompilation is one thing, but what this tool does is recompile with the target system’s apis for input and output in mind. A straight recompilation would offer less than an emulator, really.
This tool knows (or is told) where rendering routines are, for example, so that they can be replaced with destination platform versions. That’s how higher resolutions and different aspect ratios are supported in a recombination.
Super impressive walkthrough video in the article. It does a great job of explaining Majora's Mask. Although, it's probably glossing over a lot of the upfront technical challenges of using it to port games.
I'm wondering if a wireless Xbox controller would work. It's what I use with Apple TV without issue. Button layout is close enough (runs to living room to compare Xbox controller to Switch Pro...), in fact they're basically identical.
OTOH, I haven't tried the Switch Pro controller with anything else but a Switch, so maybe it can be made to work? (EDIT: just tried it: my Mac connects to the Switch Pro via BT, haven't actually tried it, 'cuz damned work is in the way.)
I use the N64 controller with my PC, it's available for purchase by anyone who subscribes to NSO. It connects via bluetooth (the USB connection is for charging only).
Nintendo doesn't typically go after emulation projects. Yuzu was the exception, and there are reasons for that related to how the Yuzu team ran their project and distributed it that painted a legal target on their back.
This project isn't distributing any of Nintendo's code, game assets, or other intellectual property.
skrrtww|1 year ago
slongfield|1 year ago
doublepg23|1 year ago
speps|1 year ago
darby_eight|1 year ago
Why? Surely it's more straightforward to do binary-to-binary translation. No human input needed!
ambyra|1 year ago
advael|1 year ago
toastercat|1 year ago
[deleted]
jonhohle|1 year ago
kkukshtel|1 year ago
slongfield|1 year ago
Skimming the Github repo, looks like this uses rt64 under the hood for the raytracing support ( https://github.com/rt64/rt64 ), and that uses the ubershader technique to emulate the GPU. This excellent article talks about the what, why, and insanity that are ubershaders: https://dolphin-emu.org/blog/2017/07/30/ubershaders/
DCKing|1 year ago
Static recompilation from one machine language to one other language is somewhere between extremely difficult to not being generally possible in practice [1]. To make recompiling something like this properly, you need some help from the binaries that make recompilation easier [2] and on top of that you need to patch certain things to make this work [3].
Dynamic recompilation doesn't have this problem. It allows you to create software you can dump the original binaries+assets ("ROMs") in and it will generally emulate it.
There's a lot of confusion about how generic this solution it. It's extremely impressive in how much work it saves making recompilations/"ports" much easier, and it will be very valuable. But it is not able to replace the need for traditional emulators.
[1]: https://cs.stackexchange.com/questions/155511/why-is-static-...
[2]: N64 game binaries may happen to avoid a bunch of things that make general static recompilation hard that help this approach, but I don't actually know.
[3]: The Majora's Mask recompilation repository contains a lot of handcrafted patches to make it work: https://github.com/Mr-Wiseguy/Zelda64Recomp
pjc50|1 year ago
bluedino|1 year ago
ranger_danger|1 year ago
https://andrewkelley.me/post/jamulator.html
There is also Winlator for running Windows programs on Android:
https://github.com/brunodev85/winlator
Also is the youtube video linked in the article using an AI voice?
claudex|1 year ago
At least Mr WiseGuy seems to care. From the N64Recom Github repo[0]: "This is not the first project that uses static recompilation on game console binaries. A well known example is jamulator, which targets NES binaries."
[0]: https://github.com/Mr-Wiseguy/N64Recomp
BearOso|1 year ago
The N64 is fixed hardware, so it's a little bit easier. Even so, this project still uses emulation for the RDP. I don't know how it handles generated RSP microcode, maybe it doesn't. A lot of games just used the official libraries.
zamadatix|1 year ago
That's just Nerrel, a real person, narrating. It's crazy (in an interesting way, not necessarily a doom and gloom way) how we have AI voices these days so good we start to suspect people who don't speak like we expect are AI.
refracture|1 year ago
lcnmrn|1 year ago
lxgr|1 year ago
Older consoles had even more dedicated chips doing relevant stuff other than "simple" I/O, like e.g. the SNES's sound chip, which was a completely independent CPU running its own little programs in parallel with the CPU and GPU.
Of course you could "mandate" a high-level VM for all future game development, but given the static nature of console hardware specs, that wouldn't be competitive for titles wanting to make use of cutting-edge graphics.
lambertsimnel|1 year ago
On Debian, I found I had to run
and then install the wine32 packagecodedokode|1 year ago
What saddens me is that open-source OSes do not want to provide a common set of APIs so that the developer only has to write and test the code once and it works everywhere. There is flatpak, but as I understand, it doesn't provide a set of APIs, it simply packs a Linux distribution into a virtual machine without any specifications or documentation. So ugly, and no compatibility for smaller non-Linux OSes.
hot_gril|1 year ago
It's funny how the Mac is more compatible with old Windows programs than old Mac programs.
lupusreal|1 year ago
neonsunset|1 year ago
It models statically-typed compiled languages in a much superior way to WASM, there are projects showcasing how well e.g. Rust maps to it[0], and C++/CLI existed for a long time (although it's not cross-platform, and is considered cursed).
C and C++ could be mapped in a perfect manner to IL and then AOT compiled in ways that GraalVM's Truffle can only dream of (given that .NET exposes a very wide set of intrinsics allowing a lot of code to be ported that way).
[0] https://github.com/FractalFir/rustc_codegen_clr
angra_mainyu|1 year ago
Wine (+ Steam's Proton) works incredibly well these days, a huge improvement from the old days when barely anything ran, and what did run required heavy tweaking or even custom compilation.
On Linux, my Steam library of about 300 games runs almost in its entirety without issues (except for Last Epoch).
treyd|1 year ago
PeakKS|1 year ago
Cloudef|1 year ago
helpfulContrib|1 year ago
[deleted]
izzydata|1 year ago
cpressland|1 year ago
An example of this can be found here: https://github.com/Mr-Wiseguy/Zelda64Recomp?tab=readme-ov-fi...
jjice|1 year ago
Huh, I wouldn't have expected that. I don't know much about the specifics of N64 emulation, but I've had N64 emulators running perfectly since the early 2010s. I played mostly the big classics, so I'm unfamiliar with more niche title performance.
Fartmancer|1 year ago
vaughnegut|1 year ago
privacyking|1 year ago
andrewclunn|1 year ago
EDIT - But hey, you can always just add another layer of emulation via Proton to run it in Linux.
vouaobrasil|1 year ago
whateveracct|1 year ago
The modal aspect of aiming combined with the travel time/return-to-center of the cursor is a really fun part of the game. If you could just free-aim while running a la PC FPS it would kind of ruin the campaign since everything is designed around this. Picking your spots and keeping cool while aiming are the appeal.
That said, if you keep the modal aspect and have the mouse just 1) rotate Bond like left/right on the stick does and 2) control the cursor only in "aim mode" (hit R)..then I think that could be fun.
Tbh, I wish shooters didn't go straight to Quake-style WASD+mouse free-aim across the board. The modal aspect makes gives Goldeneye a certain physicality I really like.
terramex|1 year ago
https://github.com/Graslu/1964GEPD/releases/tag/latest
unknown|1 year ago
[deleted]
wodenokoto|1 year ago
ThrowawayTestr|1 year ago
tombert|1 year ago
djmips|1 year ago
https://en.wikipedia.org/wiki/Bleem!
skrrtww|1 year ago
The goal of N64 emulators (generally) is to accurately recreate the behavior of the original console.
Conversely, there is a large crowd of people who just want to play SM64, OOT and MM with a bevy of "graphical enhancements" like 60fps, widescreen, texture packs, randomizers, etc.
For these people, the fact that these games originally ran on the N64 is practically irrelevant. In fact, it's a hindrance; The N64's graphical pipeline is cumbersome to emulate and actively stands in the way of modern 'enhancements.'
This project is more aimed at giving the games themselves modern treatments, removing the N64-centric aspects of the games from the equation entirely.
wmf|1 year ago
doublepg23|1 year ago
ThrowawayTestr|1 year ago
protoster|1 year ago
jerf|1 year ago
ranger_danger|1 year ago
chlorion|1 year ago
Interpretation involves writing a VM that represents the state of various parts of the machine, and executes instructions that change the state of the VM, with varying levels of accuracy.
rcarmo|1 year ago
helpfulContrib|1 year ago
[deleted]
Gala999|1 year ago
pipes|1 year ago
https://github.com/fgsfdsfgs/perfect_dark
xnx|1 year ago
naikrovek|1 year ago
A straight recompilation is one thing, but what this tool does is recompile with the target system’s apis for input and output in mind. A straight recompilation would offer less than an emulator, really.
This tool knows (or is told) where rendering routines are, for example, so that they can be replaced with destination platform versions. That’s how higher resolutions and different aspect ratios are supported in a recombination.
unknown|1 year ago
[deleted]
simple10|1 year ago
DrNosferatu|1 year ago
I would love to play a source-port of arcade “GTI Club”! <3
theyinwhy|1 year ago
mikestew|1 year ago
OTOH, I haven't tried the Switch Pro controller with anything else but a Switch, so maybe it can be made to work? (EDIT: just tried it: my Mac connects to the Switch Pro via BT, haven't actually tried it, 'cuz damned work is in the way.)
unknown|1 year ago
[deleted]
Rychard|1 year ago
https://www.nintendo.com/us/store/products/nintendo-64-contr...
haiku2077|1 year ago
anthk|1 year ago
deadbabe|1 year ago
DrNosferatu|1 year ago
unknown|1 year ago
[deleted]
elorant|1 year ago
nottorp|1 year ago
Why do people even bother when they know they'll get lawyers at their door in 3... 2... 1... ?
babypuncher|1 year ago
This project isn't distributing any of Nintendo's code, game assets, or other intellectual property.
kotaKat|1 year ago
https://www.nerd.nintendo.com/files/Secu%20Job%20Offer%20202...
yamazakiwi|1 year ago