At this point it feels like we'll be able to play native ports of the huge N64 games before we get hardware-accurate n64 emulation (it's a hard console to emulate).
At this point it feels like we'll be able to play native ports of the huge N64 games before we get hardware-accurate n64 emulation (it's a hard console to emulate).
Are we really that far from perfect N64 emulation? I remember emulated N64 games in the 00s and it working ok (with a glitched texture here and there). I saw some progress since then and thought a...
Are we really that far from perfect N64 emulation? I remember emulated N64 games in the 00s and it working ok (with a glitched texture here and there). I saw some progress since then and thought a lot of games now run pixel-perfect?
AFAIK the biggest difference is how modern graphics card render textures, which is different from how the N64 did it. I saw an interesting blog post about this once but can't find it. Something about how it stretched textures in a way that's more blurry but less pixel-y, resulting in the typical "soft" look of N64 surface rendering.
(I'm assembling my folk knowledge so some of the below is definitely slightly wrong.) Historically, N64 CPU emulation has been pretty good. There aren't many cases where tiny CPU details matter...
(I'm assembling my folk knowledge so some of the below is definitely slightly wrong.)
Historically, N64 CPU emulation has been pretty good. There aren't many cases where tiny CPU details matter for correct emulation.
Graphics and sound are a bit different because the N64 has a co-processor, named the RCP, which deals with graphical and audio output. It has a custom instruction set, and for games the details of instruction timing matter a lot.
In the past the instruction set was not emulated directly. There are only a few microcode libraries that actually show up in ROMs, because Nintendo's development kit included those libraries. (Studios would modify them a bit, however.) You can actually get reasonable results — certainly playable — just by rendering triangles that show up in the right place in memory.
I think there are efforts to properly emulate the RCP, but I don't know how far they are or how common they are in system emulators. At this level the CPU races the RCP a lot, so cycle-level details matter.
They didn’t rebuild the code from scratch. They decompiled the original binary and then set about making it more human-readable while still matching the original in function. No human would write...
What’s so impressive about these efforts is that nothing was stolen or leaked or pirated. These fans have simply rebuilt the entire game’s code—albeit “using modern coding languages”—from scratch, to the point where it functionally performs identically to the original.
They didn’t rebuild the code from scratch. They decompiled the original binary and then set about making it more human-readable while still matching the original in function. No human would write a function signature like this:
This is completely meaningless to a human and obviously machine-decompiled from the original binary.
This doesn’t mean the project is necessarily in breach of copyright law, but it differs from the practice called clean room reimplementation, where you simply observe the behavior of a piece of software and write new software that replicates that behavior, without any reference to the original machine or source code. That’s what I’d call rebuilding the game from scratch.
These projects are so cool! I find this interesting: As a thought experiment - Does this mean that I can replace all of the game's visual and audio assets and have a perfectly legal game? Or do I...
These projects are so cool!
I find this interesting:
What’s so impressive about these efforts is that nothing was stolen or leaked or pirated. These fans have simply rebuilt the entire game’s code—albeit “using modern coding languages”—from scratch, to the point where it functionally performs identically to the original. This means there’s an expectation that technically they’ve done nothing illegal. How legally certain that is remains to be seen, but for reference, the reverse engineered Super Mario 64 code is still available at its source, despite Nintendo going after some projects that were built off that code.
That legal shit kicks in when you start talking about assets and characters, so while the code itself is hoped to be safe from Nintendo’s lawyers, the second you start adding anything on top of that code to make it look and sound like Ocarina of Time in a playable sense, you’re in trouble.
As a thought experiment - Does this mean that I can replace all of the game's visual and audio assets and have a perfectly legal game? Or do I need to change the game's scripting to be in the clear?
Mind, I definitely don't have the time to pull that off, haha. Just wondering about the legal-eagle shenanigans.
That's what some of these projects are doing, I'm thinking of OpenTTD, for example. They don't have Nintendo-hard lawyers going after them, though, so I don't know if it would hold up in a...
Does this mean that I can replace all of the game's visual and audio assets and have a perfectly legal game?
I expect the level design or text or other parts might also be issues, so I'd say the game would need to be mostly unrecognizable as an OOT "clone" to be 100% safe from Nintendo. So, probably...
Does this mean that I can replace all of the game's visual and audio assets and have a perfectly legal game?
I expect the level design or text or other parts might also be issues, so I'd say the game would need to be mostly unrecognizable as an OOT "clone" to be 100% safe from Nintendo.
So, probably turning it into something like Freedoom, though Freedoom has an advantage of the underlying engine being officially open instead of an unofficial decompilation, so it has less "gray areas" to work around.
I'm not sure I believe that decompiling isn't copying the ROM in some sense. The goal of the project is to produce C source that, when compiled with the original toolchain, produces byte-identical...
I'm not sure I believe that decompiling isn't copying the ROM in some sense.
The goal of the project is to produce C source that, when compiled with the original toolchain, produces byte-identical binaries to those in the ROM. If you copy the game assets, compile the reverse-engineered source, and link them together, you should get a 100%-identical ROM.
But this is very valuable!
Before this project, in order to modify game functionality, you had to
write new code
make the ROM bigger so you can paste the code at the end
modify an instruction in ROM to jump out to your new code
modify your new code to jump back to the old code.
This is tricky to do except when writing directly in assembly, which is very tedious.
After this project, you can simply write new code, and when linked everything will shuffle around safely.
Another top-level for some details: It's based on the Gamecube version of Master Quest, which was shipped on a disc as a ROM+emulator setup. This version was chosen because it also had some debug...
Another top-level for some details: It's based on the Gamecube version of Master Quest, which was shipped on a disc as a ROM+emulator setup. This version was chosen because it also had some debug hooks that came in useful for the project.
At this point it feels like we'll be able to play native ports of the huge N64 games before we get hardware-accurate n64 emulation (it's a hard console to emulate).
There is CEN64 but it's pretty slow.
Oh, that looks pretty cool. I didn't even know there was a project on that level yet.
Are we really that far from perfect N64 emulation? I remember emulated N64 games in the 00s and it working ok (with a glitched texture here and there). I saw some progress since then and thought a lot of games now run pixel-perfect?
AFAIK the biggest difference is how modern graphics card render textures, which is different from how the N64 did it. I saw an interesting blog post about this once but can't find it. Something about how it stretched textures in a way that's more blurry but less pixel-y, resulting in the typical "soft" look of N64 surface rendering.
(I'm assembling my folk knowledge so some of the below is definitely slightly wrong.)
Historically, N64 CPU emulation has been pretty good. There aren't many cases where tiny CPU details matter for correct emulation.
Graphics and sound are a bit different because the N64 has a co-processor, named the RCP, which deals with graphical and audio output. It has a custom instruction set, and for games the details of instruction timing matter a lot.
In the past the instruction set was not emulated directly. There are only a few microcode libraries that actually show up in ROMs, because Nintendo's development kit included those libraries. (Studios would modify them a bit, however.) You can actually get reasonable results — certainly playable — just by rendering triangles that show up in the right place in memory.
I think there are efforts to properly emulate the RCP, but I don't know how far they are or how common they are in system emulators. At this level the CPU races the RCP a lot, so cycle-level details matter.
They didn’t rebuild the code from scratch. They decompiled the original binary and then set about making it more human-readable while still matching the original in function. No human would write a function signature like this:
This is completely meaningless to a human and obviously machine-decompiled from the original binary.
This doesn’t mean the project is necessarily in breach of copyright law, but it differs from the practice called clean room reimplementation, where you simply observe the behavior of a piece of software and write new software that replicates that behavior, without any reference to the original machine or source code. That’s what I’d call rebuilding the game from scratch.
These projects are so cool!
I find this interesting:
As a thought experiment - Does this mean that I can replace all of the game's visual and audio assets and have a perfectly legal game? Or do I need to change the game's scripting to be in the clear?
Mind, I definitely don't have the time to pull that off, haha. Just wondering about the legal-eagle shenanigans.
That's what some of these projects are doing, I'm thinking of OpenTTD, for example. They don't have Nintendo-hard lawyers going after them, though, so I don't know if it would hold up in a drawn-out case (though it might be related to this case, which estabilished the general legality of video game emulation).
I expect the level design or text or other parts might also be issues, so I'd say the game would need to be mostly unrecognizable as an OOT "clone" to be 100% safe from Nintendo.
So, probably turning it into something like Freedoom, though Freedoom has an advantage of the underlying engine being officially open instead of an unofficial decompilation, so it has less "gray areas" to work around.
I'm not sure I believe that decompiling isn't copying the ROM in some sense.
The goal of the project is to produce C source that, when compiled with the original toolchain, produces byte-identical binaries to those in the ROM. If you copy the game assets, compile the reverse-engineered source, and link them together, you should get a 100%-identical ROM.
But this is very valuable!
Before this project, in order to modify game functionality, you had to
This is tricky to do except when writing directly in assembly, which is very tedious.
After this project, you can simply write new code, and when linked everything will shuffle around safely.
Another top-level for some details: It's based on the Gamecube version of Master Quest, which was shipped on a disc as a ROM+emulator setup. This version was chosen because it also had some debug hooks that came in useful for the project.
I've been watching this project for a while. Definitely excited to see this ported to PC now!