The % is estimated based on the number of functions that still need to be recompiled. It is already possible to play and even create mods! As other recomp projects, you need to provide your own ROM.
I'm not aware of legal trouble involving the the Zelda 64 recomp project, which would have a much higher chance of attracting the attention of big N (especially now that a new version of OoT is coming out).
At least in the way that I see it, a recomp is like building your own turntable to play your vinyl records, after stydying their grooves and infering how they would sound (so I guess that it would be less gray than an emulator).
No one can say anything, no game rom is ever bundled in the official releases of these recomps. We always have to provide the roms. Where from, it's another story.
It's basically the same as emulation as long as the recompiled code doesn't get distributed (which this project doesn't do AFAIK). Functionally the only difference between a "recomp" and traditional console emulation is that the assembly code that the CPU runs is translated to C then compiled to native code, rather than being interpreted or JIT compiled at runtime. Traditionally recompilation was mainly used when porting games to platforms where the emulation overhead would have been too much, like if you were making a GBA port of a Sega Genesis game. With these enhanced ports, I guess the idea is that if you're making a game specific "emulator" anyway, you might as well recompile the code and get rid of the overhead of interpretation.
Note that this isn't the same as a "decomp" where the goal is to make readable source code that resembles something that the original developers would have worked with. A "recomp" simply translates the assembly instructions to C. You end up with "assembly code but in C" rather than idiomatic C code.
More infringing than emulators. De/recompilation projects are pretty clearly 'derivative works' of the original copyrighted program code, even if they require the original ROM in order to extract other assets necessary to compile a fully playable artifact.
The closer analogy would be fan-translation patches, which are also pretty clearly copyright-infringing derivative works though generally tolerated by rights holders.
Companies often encourage (or at least turn a blind eye to) creative derivative works from fan communities, especially if they're non-commercial and aren't cutting into the market share of their own official products enough for them to take notice.
The % is estimated based on the number of functions that still need to be recompiled. It is already possible to play and even create mods! As other recomp projects, you need to provide your own ROM.
A bit of trivia, since the start of the project I ordered the AI agents to produce a handoff for the next agent, so we have the whole timeline for the project as handoff docs: https://github.com/lfarroco/ogre-battle-64-recomp/tree/main/...
Nice I have not thought about this game in years.
What is the legal status of recompilation projects like these? Greyer or less grey than emulators?
I'm not aware of legal trouble involving the the Zelda 64 recomp project, which would have a much higher chance of attracting the attention of big N (especially now that a new version of OoT is coming out).
At least in the way that I see it, a recomp is like building your own turntable to play your vinyl records, after stydying their grooves and infering how they would sound (so I guess that it would be less gray than an emulator).
No one can say anything, no game rom is ever bundled in the official releases of these recomps. We always have to provide the roms. Where from, it's another story.
It's basically the same as emulation as long as the recompiled code doesn't get distributed (which this project doesn't do AFAIK). Functionally the only difference between a "recomp" and traditional console emulation is that the assembly code that the CPU runs is translated to C then compiled to native code, rather than being interpreted or JIT compiled at runtime. Traditionally recompilation was mainly used when porting games to platforms where the emulation overhead would have been too much, like if you were making a GBA port of a Sega Genesis game. With these enhanced ports, I guess the idea is that if you're making a game specific "emulator" anyway, you might as well recompile the code and get rid of the overhead of interpretation.
Note that this isn't the same as a "decomp" where the goal is to make readable source code that resembles something that the original developers would have worked with. A "recomp" simply translates the assembly instructions to C. You end up with "assembly code but in C" rather than idiomatic C code.
More infringing than emulators. De/recompilation projects are pretty clearly 'derivative works' of the original copyrighted program code, even if they require the original ROM in order to extract other assets necessary to compile a fully playable artifact.
The closer analogy would be fan-translation patches, which are also pretty clearly copyright-infringing derivative works though generally tolerated by rights holders.
Companies often encourage (or at least turn a blind eye to) creative derivative works from fan communities, especially if they're non-commercial and aren't cutting into the market share of their own official products enough for them to take notice.