So, you’re pretty much spot on with how emulators work. I also like using claymation to demonstrate it, like this. Your computer bends over backwards to give the game the exact environment it expects.
What makes recompilation more than a simple script is the rebuilding aspect. I brought up claymation because it’s a great analogy for this, too. An n64 ROM is a complete set of characters, sets, and a script for a claymation movie. It’s I in one studio right now, and that studio is the N64, but you need this to be in your PC studio.
First, you have to decompile your sets and characters. You take reference photos and rip out every tree in a forest set and roll each tree back into it’s own ball of clay, with its own reference photo each time. Every little clay cobble on a road, characters outfits, hair, limbs, you meticulously separate every piece of clay that Nintendo shaped, ball them up, and pack them. You now have a million little clay balls and reference photos for every one of them. You take these back to your PC studio. Thankfully, with these reference photos, your clay 3D printer (compiler) can return these balls into something very close to their original shapes, except there’s a bunch of little mistakes. One character’s leg is slightly thinner and longer than it should be, which messes up their gait when you re-film this, so you manually tweak the leg to be accurate. The cobbles don’t quite fit the same, they’re a bit smaller, but you have extra clay because of that so you just make more cobblestones. The road doesn’t look exactly like the original, but that’s fine. The trees, again, don’t quite fit right, but you’ve made similar trees in your studio before and you know those will work so you actually just use those as references instead of the originals. You get filming but this one scene just isn’t lit right, and you can’t figure out why, but you eventually figure out the N64 studio opened the blinds on their window to get natural sun in this shot, but your studio doesn’t have a good view of the sun at that angle, so you have to get a good lamp.
You face a million little hurdles decompiling and recompiling. Its almost literally reinventing the wheel. Almost all the work goes into little details that almost seem unnecessary, but there’s so many that it’s absolutely necessary. I was watching a playthrough of a recompiled majoras mask earlier today, and the Dev of this project found his way there, too, and he said it took a few days to get majoras mask to decompile and recompile, and about a year to fix all those little details that in software become lag or new bugs. So the script guy isn’t really wrong when he said he could do it fast, but he definitely wouldn’t do it right.
MajorasMaskForever@lemmy.world 4 months ago
For graphics, the problem to be solved is that the N64 compiled code is expecting that if it puts value X at memory address Y it will draw a particular pixel in a particular way.
Emulators solve this problem by having a virtual CPU execute the game code (kinda difficult), and then emulator code reads the virtual memory space the game code is interacting with (easy), interprets those values (stupid crazy hard), and replicates the graphical effects using custom code/modern graphics API (kinda difficult).
This program is decompiling the N64 code (easy), searches for known function calls that interact with the N64 GPU (easy), swaps them with known valid modern graphics API calls (easy), then compiles for local machine (easy). Knowing what function signatures to look for and what to replace them with in the general case is basically downright impossible, but because a lot of N64 games used common code, if you go through the laborious process for one game, you get a bunch extra for free or way less effort.
As one of my favorite engineering phrases goes: the devil is in the details
ramirezmike@programming.dev 4 months ago
that makes sense, it’s like only really feasible now that we have enough decompiled, readable n64 games