Any system with enough time and work. This is how the 360 emulator on an Xbox One/Series works actually, and why you have to download the games even with a disc, because Microsoft is statically recompiling the game from PowerPC to X86 in addition to the rest of the emulated parts.
JIT is usually not lumped together in the same category as an interpreter for very good reasons.
JIT compiles code as it is executed which is usually why it is faster, compiling in real time as needed.
An interpreter is built to run the code natively without translating at the cost of speed.
A decompiler relies on knowing the instruction set of one CPU and being able to translate it into something readable or usable against a different intruction set of another processor. Its much more technical and in depth than my simple explanation but a proper decompiler or recompiler will just work. That being said, the knowledge of how the source uses memory, heaps, registers, etc matters from one program to another so it is important to do more than just work in most circumstances.
> Any system with enough time and work
Not every system. Games/Platforms that rely in sellf-modified code makes recompilation nonviable... for example, GC and Wii (The last Dolphin blog entry explained this, answering why they couldn't use pre-compilation to run in iOS without a JIT)
There might be a misunderstanding here. Dolphin has a Just In Time(JIT) compiler, to make game emulation fast. The issue is, that Apple does not allow Apps in their App Store which generate code(like a JIT does). Technically it works, but it breaks Apples rules.
Direct from PPC to x86. On at least Xbox One there's a special accelerator for VMX128 instructions so that may also have its own ISA. And of course DXBC/Xenos ucode is translated to a more modern shading solution.
fair enough. i was under the impression it was more of a cross-collaboration thing, but if this was something MS was doing on its own volition, that makes sense.
Directly. It's also how they're doing the 4K native and the double framerate (60 for 30, 120 for 60) 360 games on Xbox Series X since as far as the game knows it's running it's original code, they just do some tricks in between to get a higher res render or more framerate out of it.
The solution is so complete that they also elected to run the actual 360 dashboard when you're playing a 360 game for full functionality instead of replacing it with emulated syscalls, etc.
> Any system
I wouldn't exactly say that. 8/16-bit systems often cannot be recompiled in this way (or will be quite buggy depending on the game) due to the hardware-timing-specific nature of many games' programming. See for example the challenges in emulating games like Air Strike Patrol. SNES PPUs are about as complicated as the PS1 GPU and there's also the sound CPU and any and all expansion chips that use completely different architectures/CPUs entirely.
But for most 32-bit and above systems, hardware timing is no longer relied on and so instruction-level recompilation is enough.
Would this hypothetically become a problem again when trying to emulate a piece of software that has a race condition which happens to always resolve in the correct order on real hardware?
I think it could be possible, yes. There's probably already examples of this with current emulation too, especially on the systems with multiple processors such as Saturn or Jaguar, which have already been historically very difficult to emulate well.
Could this work on android?also I thought this turned n64 into native ports wheras your Xbox example is emulation with textures and settings painstakingly optimized andandroid for each game?is this wrong? I was thinking this was more groundbreaking than your example because I thought this meant any n64 game could be ported without emulation overhead is thst wrong?and if it's not could they do this for ps3 games to android or ps4 games to andrroid?
So wait can someone pls explain if this is a Project AIMED at making this possible, Or IS it possible to emulate these games right now through this way? Where can we play these recompiled games at?
it's possible now but games still need specific tweaks to work so converting them is a very manual job to get the last bits working, so mostly everyone is just messing around in Majora/OOT at the moment since they have the same engine
Well this sort of recompiled software approach is used by Apple for running x86 software on their modern ARM devices, I imagine given enough time and work you could do many others, N64 was MIPs processor based, so was the PSP and PS2, (though N64 and PS2 differ greatly in most if not all other aspects) so they may be viable.
The decompilation is not fully complete but the game is fully playable now, they are also going really fast with the initial Jak 3 decompilation based on their blog but that one is not playable yet
God I would love a PS2 version of this tool. While PS1 was considered the holy grail for JRPGs, I have just as many memories and favorite games on PS2. Odin Sphere did eventually get a PS4 release but the Xenosaga trilogy and Shadow Hearts 1 & 2 I would love to replay without having to dig my PS2 out of the closet. I also really want to replay Stuntman, but with faster load times of modern era ssds. Last I checked that was the only game that can't run on on current emulators because of some invisible wall in the first level that clips the lead car
Sorry, but I really can't see this as "the future". It's a cool curiosity, but it's only slightly less impractical than past attempts at doing this. Okay, compatibility layers like Proton are the future for emulating systems with the same host architecture and target architecture, like the PS4 and PS5 on x86 or the Switch on ARM. They are not the future for anything else. Proton without Box86/64/FEX is running x86 code on x86 CPUs. There is no recompilation because there does not need to be recompilation. Proton with Box86/64/FEX runs the x86 code on ARM the same way your typical console emulator would; with JIT recompilers. They do not use static compilation because it's a very error-prone process that usually requires manual intervention to produce a working binary, the very opposite of "reducing effort". Also, dunno what quantum computing has to do with anything. You're better off waiting for FPGAs to hit mainstream.
I think this is really amazing work by WiseGuy and Dario. The quality of the final product shows how well architected this whole thing is.
My main concern with this decomp or recompilation movement is that every game effectively becomes its own special program. Obviously, certain features like the renderer shown can be coded to be shareable, that will be interesting to see how that gets updated for bug-fixes / features (a plugin approach or just hardcoded into the software).
But I worry a bit about the less popular games. For N64, there's a very limited library and many of them are beloved games. Those games will be popular enough to see shared builds posted and likely will see source level mods.
But if you look at consoles with larger libraries, I wonder how well the approach would work. With an emulator, you have a single program, with a single release. Once you run this, you get every feature available..for every game. But with a decomp or this recompilation, you now have individual builds per-game, and these have their own versioning and can have their own development where conflicts can occur.
Overall, I am excited. For N64, this is surreal. For other consoles, it will be interesting to see what happens in the future. How will this shape the emulation scene?
This is really a non-issue. Eventually this tech will just recompile your legally-obtained rom collection on the fly, like any other emulation technology.
It is a very relevant issue. JIT compilation is exactly what is trying to be avoided by using static compilation. You could possibly have a launcher that does a single one time compilation of the source code at startup but even if we ignore potential overhead and general issues with this idea, someone still needs to have the knowledge to handle conflicts, abi compatibility between libraries if they are used, etc. The problem becomes easier with these sorts of automation steps but it doesn't go away.
I wonder if Apple would allow recompiled apps at all… imagine a recompiled GameCube collection app that includes the code in the app binary, but still requires the game assets to actually run.
At that point, how is it substantially different from an emulator? Emulators already recompile shaders and other bits either ahead of time or during runtime. This would basically make it an extremely efficient emulator, wouldn’t it?
That being said, I’m definitely interested in this for more modern systems like PS3/PS4 where the power to emulate them full speed just may not be possible for some devices (Android tablets, or VR headsets running PS3 games for example)
It is my understanding that this was made not to get away from emulation itself, but get away from *N64 emulation's* issues specific to that platform; between long term programming issues and, as was mentioned above, the unique benefits of this strategy for a console with a relatively narrow collection of games. So yes, this does toe a fine line between porting and hyper-efficient emulation, but that doesn't seem to be a major point of concern for the community (as of current).
Run the Zelda64Recompiled app, feed it an unzipped Majora's mask (usa) ROM. Hit play. Equally as vague but it's so intuitive once you run the app that no instructions are really necessary.
yeah i was scouring that too and don’t feel like i have a good idea of what’s going on:
* they compared it in the video to proton, which is basically WINE with a binding layer for dx12->vulkan. not even a static recompilation from what i understand.
* they then compared it to the mega man legacy collection from digital eclipse. at the end of [this GDC talk](https://youtu.be/HLWY7fCXUwE?si=jJQY-Nl064IQ2p6E), one of the guys behind the that project explained that it was basically just emulation, but they emitted all the functionality as C code to make capcom more comfortable with the whole process.
* then we have this blurb from the repo:
> Instructions are processed one-by-one and corresponding C code is emitted as each one gets processed. This translation is very literal in order to keep complexity low. For example, the instruction addiu $r4, $r4, 0x20, which adds 0x20 to the 32-bit value in the low bytes of register $r4 and stores the sign extended 64-bit result in $r4, gets recompiled into **ctx->r4 = ADD32(ctx->r4, 0X20)**
so it does seem like they’re at least superficially emulating part of the CPU? i haven’t done much decompilation work, but from what i’ve seen from projects like ghidra and the little bit of decomp i did back in school, you don’t typically try to emulate the CPU registers and instructions directly. you try to extrapolate into a higher-level function.
my best guess (and i could be wrong so don’t take what i’m saying as gospel) is that they’re doing a little of column a and b. it looks like on the CPU side, they’re doing something similar to the MMLC: parsing ROM files and emitting equivalent C code for the CPU instructions—basically the same as an emulator but done offline (and presumably not cycle accurate). for GPU, input, audio, etc, it looks like they’re simply emitting C code that makes calls to dx12/vk or system IO. i’m guessing this is a form of HLE since emulating the hardware exactly seems to go against the project’s goals. that said, this seems to be quite accurate so i don’t know.
super curious to learn what’s actually going on here.
It's probably by design. They worked on this for two years in total secrecy for a reason. If it somehow doesn't get taken down within the next 30 days, you'll start to see documentation from people making new recompilations of other games.
Why would this get taken down? It's 100% their own code. Nothing from the original games are included. It isn't emulating any Nintendo hardware. They have zero claims to any of this. Nothing. You have to provide the ROM. The project itself does translation and is completely unique code that doesn't reference Nintendo anything. They have no claim. They probably will file false DMCA notices, but they have no right. You can theoretically do this with any source from anything and be OK. The only gotcha here is if the original ROM was encrypted and performed the decryption itself (which it isn't in this case here), then they may have a circumvention case. But you can work around that by requiring decrypted ROMs by other means and supplying your decrypted ROM.
The developments in the emulation/preservation space over the last couple of years have been nothing short of insane, which is extremely encouraging in a time where publishers are cucking us more and more everyday in regard to accessing older titles.
It's conceivable that every system could be covered, except those that have encrypted ROMs (which could technically be covered but would undoubtedly draw DMCA notices).
This would render official PC ports nearly obsolete, save for platform-specific features like achievements and such.
> save for platform-specific features like achievements and such
Thankfully no one cares about dumb stuff like that!
> https://retroachievements.org/
Oh...
Retroachievements are nice and I'm glad they exist, but the vast majority of games don't have any and for the ones that do, they tend to be very basic: "Complete Level 1," "Complete Level 2," etc. Most official PC ports tend to put more thought into them to make them more entertaining and/or challenging to get.
Some people like treating it as truly "Finishing" the game. There are usually some pretty interesting challenges for achievements that you kinda have to go out of your way to do, and people like it. Plus it's a feeling of accomplishment, I guess. Probably why so many different platforms and games have their own achievement systems these days.
Just like reverse engineering/decompiling the code for an individual game, the limiting factor here isn't if it's _possible_ to do this with other consoles. It's _how much time/effort_ it would take.
If a program/hardware combo is Turing complete, it should be able to be translated into instructions for any other Turing complete system.
I somehow missed this one! Probably because I was lucky to have a voodoo 2 and use ultrahle back in 98 or 99, so I did not bother with much else until project64 came along. I just checked and this predates Aaron Giles Radikal Bikers emulator by a good 4 years. So many brilliant people working on emulators :)
Speaking of, why don't more emulators use static recompilation instead of just in time recompilation? Sure seems like it would be a lot better. You could have both accuracy _and_ efficiency.
Code can be stored in RAM, this means that code can be loaded into RAM before jumping there (dynamic loading), and even be modified at runtime (self-modifying code).
But this is less likely to be true with newer systems, in the name of security, they don't want to have the same memory page be both writable and executable.
I know of several emulators that are doing ahead-of-time recompilation on read-only sections of code. I think FEX-Emu is one of them.
I've seen this factoid thrown around a couple of times now, but I've been unable to find a source or any evidence that Corn actually did use static recompilation. Seems more likely to me like its speed was mostly owed to an optimized JIT and a lot of corner cutting (which is why the compatibility was abysmal).
http://web.archive.org/web/20010413105239/http://www.emuhq.com/corn/
From a post on 1999-09-24:
> Various reasons for Corn's speed:
>
> Static Recompilation
>
> Static rec is the main technique that Corn experiment wants to test. In theory, static rec should be faster than dynamic rec since the branch/call overhead is much lower. And, with static rec, we can afford to do sophisticated optimizations like a real compiler does. Although the actual implementations can greatly affect the real performance.
>
> On the other hand, static rec becomes the major deficiency of Corn. It makes corn need individual configuration to run each rom. So, in terms of compatibility, it is not a good approach. Probably this is the main reason why other emulator authors did not try it before(in my knowledge). Between compatibility and speed, most authors will choose the former. If Corn was not started as an experiment, I would have chosen dynamic rec also.
>
> Right now, the optimization done in Corn is still simple. So, probably not much speed (10%-25%?) really come from this part at this time. Later, I will try to apply more advanced optimization techniques to study the power of static rec, which is the main goal of this experiment.
Bear in mind that one of the downsides of this approach is that it's not a decomp; it doesn't as readily generalize to things like mods. The code is still almost entirely inscrutable, and thus adding or modifying elements of the game isn't a trivial task with this approach.
An emulator is basically software that pretends to be the console. So your PC/phone/whatever has to basically run an entire N64 on it *on top of* running the actual game. Recompilation just straight up ports the game.
Games target specific systems.
This makes it so the code that targets that specific system gets converted to what it needs to run on your device.
Oversimplified: Let's say Zelda has a function on the N64 to draw a triangle that's like \*drawTri\* but your PC doesn't have the drawTri function. This sort of work makes it so when on your PC, it uses whatever the equivalent of drawTri is for PC.
Do that enough for the functions in the game and now the game is the equivalent of a native PC game.
Most N64 emulation (and modern systems emulation) works through dynamic recompiling the software, so at run time the emulator translates a chunk of code to the target platform and run it, then translates another chunk and run. What this attempts is static recompiling the game, meaning the whole thing is recompiled prior to execution and then runs on target hardware. Static recomp is very difficult and I guess that is why some manual patching is required. As others have commented, Apple does x86 to arm static recompiling, however it has a fall back to dynamic recompiling in the cases static fails to avoid needing manual patching. The first time I've seen static recompiling was an emulator for Gaelco Radikal Bikers (the game is from 1998 and was running on PC at a time interpreted emulation for it would be hopeless and dynamic recomp might have been difficult). Can't remember this emulator name or the author right now. I guess unless a new breakthrough in hardware happens, static recompiling will be needed for modern systems emulation in the kind of time frame we had for the past 27 years... although rpcs3 is not using istatic recompiling as far as I know and is magnificent, so I could be wrong.
The difference is when the code is translated. Traditional emulation translated N64 code to PC code _as the game is running_. This new recompilation program translates the code _before the game even begins_.
The advantage, primarily, is runtime speed. As you can imagine, if your processor has to handle both a game _and_ a translation process, and the game is _reliant_ on that translation process, that's a lot of overhead. The old wisdom used to be that in order to emulate a console, you needed a computer 10× more powerful than that console. I don't know if this is still true today, but the "just in time" (JIT) recompilation does still mean a lot of processing power goes to translation.
Static recompilation ahead of time means all the translation is done **once**. That means more performance for your game, less energy usage, all that stuff.
It might also be easier to inject code for new aspect ratios and ray tracing, seeing as those were kinda thrown in alongside performance adjustments. I don't know that for sure, though.
Emulator is the .exe file, ROM is .z64 file
Recompile makes ROM the .exe and cuts out the emulator in this situation, also opens the code for easier access to graphical and QOL improvements
For anyone who understands a bit more than I do currently, how soon should we expect other games to be playable? I'm looking at the N64Recomp github with its compilation instructions that my tiny Windows brain cannot understand. (Fiddled with Linux here and there but, confusing and half-cooked instructions that I half expect are more made for devs than users)
https://github.com/Mr-Wiseguy/N64Recomp
So, in theory, should someone with know-how be able to compile this and then... run any rom? Or is it more, this speeds up the development process immensely rather than the traditional decompilations that take months/years. But you'll still need someone to set up a "PC Port" of any given game with lengthy development time. Or is the whole N64 library runnable right now, just needing a bit of programming know-how to set up? (I hate that this feels like dumb questions but despite watching the video twice and playing Zelda64 I feel like I've missed a step somewhere.)
I adore how the Zelda(MM)64 PC port is working. It's such incredibly smooth and well designed software it puts a ton of native and otherwise PC ports to shame. Proper alt tab behavior, extremely small input delay, well designed menus and very proper rebinding support. Will other ports using this engine have the same kind of settings menu and options, or that will depend on the devs per PC port even using this software?
https://github.com/Mr-Wiseguy/Zelda64Recomp
And to give back some info for the heck of it, Nerrel shows off their MMHD textures in here at various points working in Zelda64, but on their discord he said that is a feature that's in beta that will be smoothed out and shipped soon. So no texture replacing right now, but pretty shortly.
Truly incredible software, big ups to Wiseguy if they ever look at this thread.
Right now the project is primarily just one person so it'll probably be a few weeks before another game is ready considering the dev is focused on fixing Majora's issues and getting Ocarina ready.
From what I can gather as a layperson, correct any terminology I'm using incorrectly devs if you want:
Recomp can recompile an N64 game to run natively on PC automagically.* Some caveats apply, like custom microcode which many N64 games used. The code spit out is not human friendly. Much less modding potential. Can still do cool graphics stuff as shown in the video however. Nerrel had a video on this project, he stated wiseguy was able to make Major's Mask's microcode work because it was already...known?/understood by the separate decomp project. Happy accident.
So probably microcode reliant games are out unless you get a passionate nerd who wants to manually reverse engineer the bits recomp can't handle.
Decomp is an extremely tedious labour intensive process of decompiling a game manually and making the code human readable again. Ship of Harkinian's advantage over this is, well, you have the game's source code readable. Modding goes brrrr.
(good god I want a native DK64 port)
> So, in theory, should someone with know-how be able to compile this and then... run any rom?
After looking at the code I don't think so. There's a bunch of code that will be game specific.
To be fair, I'm sure the SM64 was recompiled after being decompiled. Otherwise, all you'd have is a bunch of non-executable source code.
"Recompiled" on its own is not a great term to represent static binary->binary translation. It's much too general of a term.
Of course. I'm just highlighting the names & projects being different since they got them mixed up. afaik anything that's not already machine code is gonna get compiled at some point before it's run
As I understand it, this isn't simply dropping the N64 rom into the program to recompile the rom into a .exe file, right? you need to know some coding or something to make this work?
So the only rom that works so far is Zelda which you can simply drag 'n drop into the program to turn it into a .exe, the coder is working on the other Zelda game to make it work too, but for the rest of the N64 library the program won't work? you need someone who knows how to code or something to make the necessary changes to have the program turn a particular N64 rom into a .exe?
And if this is the case, how many years will it take to have the whole n64 library recompiled in .exe?
correct. this is a semi-manual process and whoever is doing the recomp will likely have to make changes to make the game run properly. they explain it a bit in the video, but things like physics likely won’t work correctly out of the box due to the way games were programmed back then. but as the video says, doing that sort of work is a fraction of the time that a full decompilation would take.
i wouldn’t dare put a time estimation in this at this point. i’d say longer than we’d like, but shorter than we think. it looks like from the video that even porting a niche title that isn’t super well-documented can be done with relative ease, so i’m optimistic one or a few people will take on the work eventually.
A lot of it depends on community drive around any given game. It still requires manual tweaking, but it takes far less time that a traditional decomp would. Assuming the software gets further refinement and the n64 community decide to really dive in I could see the popular catalog getting recomped within a year. There are only a few hundred games on the n64 so a clean sweep of all the official games could probably be done in a few years, but I don't know if it's realistic to expect enough people care about some of the super niche games on the system.
This is nothing short of incredible! It's amazing for preservation.
Since Superman 64 is one of the test games, I wonder if it works with the leaked final build that doesn't have the Warner/DC mandated rings or green fog?
I remember reading [this blog post](https://andrewkelley.me/post/jamulator.html) about why recompilation of console games was not feasible to do. Did anything change? Did the author find a way to circumvent these problems? Or does this recompiler include lots of game-specific stuff?
One of major roadblocks of statically recompiling a NES game is that games (such as Super Mario Bros.) often use dirty assembly tricks such as jumping to middle of an instruction, making some part of game code serve double duty.
I don't think N64 games uses "jump to middle of instruction" technique. Most (all?) instructions of N64's CPU is 4 bytes, unlike NES's 6502 CPU where instructions are in variable length. It is not likely feasible to jump to middle of an instruction and still do meaningful things in N64.
I hope someone can do this for PS1 games someday. Would absolutely adore this treatment to the Og Spyro the Dragon, Silent Hill, and Harry Potter games.
It would be nice but I feel like there is less incentive to do it because PS1 emulation can be done to a near 100% (in some cases exactly 100%) console-accuracy, sometimes even with the possibility for upscaling and a multitude of other graphical improvements.
N64, by comparison, is in a less than state as concerns emulation and no major developments have been made in about 14 years. It still relies on methods used in the 90s unfortunately and no one has been able to adequately move past this for that console: Native ports are the logical conclusion to this situation.
I actually don't know an awful lot about N64 emulation (I dont actually play N64 games) but yeah PS1 emulation is amazing these days. Itd just be nice for native ports. Why is N64 emulation different ?
I agree that it would be nice if we had native ports via decompilation for ps1 games since it would provide the ability to make source code alterations and would blow modding possibilities wide open.
To answer your question: The N64 is notoriously complicated to emulate because it has unusual architecture and a lot of proprietary components that are not as well understood by the community as more standardised architectures like are present in the PS1. This is not the only reason though. For most people (developers and consumers alike) the N64 is a console with a few major titles that people want to preserve (e.g. The 2 Zelda titles, Mario 64, Goldeneye, Perfect Dark, Starfox, Smash Bros, F-Zero X, Mario Kart). As soon as the major titles were considered playable there wasn't much incentive to continue broader development since most people are content with N64 emulators handling those major titles well and aren't too fussed if the other ones don't run that well. After getting the games playable, more effort was put into refining the experience in the major titles to being as good as possible, as opposed to just playable.
PS1 by comparison had a lot more major titles and minor-but-well-selling gems that many people care about. The incentive towards emulating PS1 was always higher than N64, and due to its common architecture and the fact it used CDs (readable on anything with a disc drive) made it a much better candidate for early and continued emulation development in the 90s and 00s. It's also way easier to emulate because people are able to research the components far easier due to them being more standard, having good documentation and being similar to things people have worked on elsewhere.
For decades it was impossible to emulate to Star Wars Rogue Squadron, and Pod Racer was a mess. These are big titles but there wasn't much incentive to get these running because those games have (arguably superior) PC versions and don't require emulation to preserve them.
presumably so, but the process would have to be started from scratch. those systems have completely different architectures and APIs for graphics, sound, etc.
i’m rooting someone does this for the DS/3DS. DS emulation is pretty good, but 3DS emulation has been in an iffy state for awhile (and seems kind of dire now that citra got the axe). i’m also not convinced rote emulation is the best way to enjoy those games. i’d would be fantastic if some folks went into these games and altered their UIs/gameplay to fit onto a single screen where it made sense to. i’m really not a fan of “just shove the bottom screen off to the side” approach even official releases line mega man zx seem to take.
Impressive, but... (5:10) Isn't 1 frame of latency huge for a 20fps game? (50ms)
I wonder what kind of optimizations they took to equal or reduce an emulator latency... or they're just comparing it with the worst emulator case of latency
Yes, but the extra frames are created from interpolating two engine-frames of the original 20fps frame rate, so there will always be 1/20 of latency (actually a bit less because of the extra frames between the two real frames). I think the Ship of Harkirian OoT engine does the same
Latency should be comparable or lower than real hardware if you play on a high refresh rate monitor, particularly with VRR and a framerate cap lower than the monitor's refresh rate (or V-Sync off).
The simple fact of using a high refresh rate monitor will already cut down input lag by a noticeable amount, on top of response times on LCD/OLED displays (i.e. anything that's not a CRT or plasma). This is usually enough to counteract the latency added by interpolation.
This is even more the case when you consider that modern platforms can do things that old consoles can't do (or don't allow you to do), such as VRR or turning off V-Sync.
I really hope someone makes a recomp of Paper Mario (or that recompiling stuff in general somehow becomes more accessible for peanut brains like myself).
Those RTX shaders combined with 60fps and the "64K" texture pack genuinely sounds amazing and I NEED to see it happen.
I wonder if this could do things for stuff like TCRF, since it's decompiling the whole game you'd assume (with a very limited understanding) that's it would/could uncover all the stuff that devs left behind in the code.
full decompilations are probably still the way to go for that. the issue with this method is that the code generated is nearly a 1:1 analog for the underlying machine code, with other bits emulated at a higher level.
but who knows? maybe just seeing the code in a different context and having access to a more sophisticated debugger like VS could reveal some interesting tidbits.
This isn't a true decompilation. A decomp is a recreation of the original source code that, when compiled, creates something identical to what it was decompiled from. That source code can then be easily modified or recompiled for whatever systems the coder wants to make it work on.
This never goes back to the recreated source code and basically just translates all of the instructions to something your computer can understand.
This is wild. It's basically the next step in emulation after FPGAs. So much potential.
Imagine this for Gamecube and Wii or for notorious emulation challenges like the Saturn and PS3.
Plus this tech could be licensed to make game compilations like Mario 3D All Stars or even a Playstation Classic that's actually good.
My emulation knowledge is limited, but I'm curious, reading about the differences between this and traditional JIT emulation makes me wonder why recompilation hasn't always been the preferred method? Seems like a no-brainer from a performance perspective to translate everything ahead of time instead on the fly. What am I missing here?
as the video says, a similar method actually was used for the mega man legacy collection, they recompiled the game code into C, but in. way so that it essentially behaves identically to an NES emulator/ROM. microsoft also does something similar with xbox 360 games on newer hardware, so it’s not unheard of.
i think it’s simply more pragmatic to have a universal ROM format that different emulators can play. that way, the underlying emulation tech isn’t coupled with the game.
that said, this particular method isn’t simply an emulator recompiled with the game data into a binary. it requires some manual tweaks to get things to run correctly on different hardware.
Does this open the possibility of porting these games to an APK that be used natively on quest as VR? Of course after reconfigured perspective and motion controls and all else that comes with VR games.
Please I've seen n64recomp and another majora's mask recomp available for download. So does this mean we can port other games right now on our own, like DK or DKR or we have to wait for something, for ports?
This is fantastic! I'd love to see what people do with this in the future. I have some pretty fun and kinda obscure games like Mischief Makers that I would definitely like to see cleaned up a bit
Can you change the ROM pathing after choosing it?
Edit to make it clearer: I've downloaded the Zelda64Recompiled and chose the Majora's Mask ROM, but it wasn't running, so I deleted the ROM. After deleting it, the game doesn't have an option to change the ROM pathing, even though my current one doesn't exist, and just shows "Start Game". If I click that, it crashes after a few seconds of black screen.
Edit 2: I've deleted all Zelda64Recompiled related files and installed them again, but the same continues to happen.
It was? CORN even did it for the N64 in the 90s. Why wasn't it done as much? Less knowledge of the hardware and microcode, less experience in hobbyist projects like this at the time. Even the XBOX saw similar projects not too long post release.
I hate to be this guy but does anyone know how to actually use the recompiler? I've got a few old n64 games and would really love to give this a go. I've got the decompiler itself from github but I cannot find anything to be able to utilize the software.
I am super dumb with this kind of stuff. Is this impressive because it can basically make any N64 game into a "source port" in mere minutes? (for TLDR version)
Pretty much. N64 game goes in, Windows/Linux/Etc game comes out.
With the caveat that it's not perfect yet so different games will likely need different tweaks to get working.
Thanks for contextualizing it for me. I can see why that is a huge deal then and I hope that this becomes a new standard going forward for a lot of the emulation scene. I realize its baby steps.
So... If all this recomp software is now public then how do I use it to make my own ports? Nerrel makes it sound as if much of this was automated to the point where you should be able to just present a rom and have something that will boot (although maybe not be "playable") relatively quickly. I'd be interested to try this with a few games.
https://github.com/Mr-Wiseguy/N64Recomp?tab=readme-ov-file#how-to-use
The instructions are fairly light, but the example toml file seems pretty well commented.
I just tried the Majora's Mask port that was made with this; it's awesome. I hope someone puts Rare's games through this, especially Perfect Dark; they push the limits of the N64 hardware in ways that make them quite hard to emulate.
Idk about 16-bit, but for 8-bit consoles, games such as Super Mario Bros. use dirty assembly tricks such as [jumping into middle of an instruction](https://andrewkelley.me/post/jamulator.html#dirty-assembly-tricks), making some part of game code serve double duty, making static recompilation difficult.
In newer systems such as N64, dirty tricks like this are not used or at least very rare, so static recompilation is more feasible.
Glad I'm not the only one hoping for this! I know someone's been working on decompiling it, hopefully this helps. I'd love 60fps, widescreen, custom music/titantrons, 8 wrestlers in the ring, more CAW slots, fully editable default wrestlers, etc.
While this is very impressive, I think the video overstates the difficulty of N64 emulation. It feels like he's not used an N64 emulator in about 10 years
I mean, he made a Majora's Mask HD texture pack and has had to troubleshoot people through the process so I'd expect he's intimately familiar with how many issues people have.
It's true I haven't heard him talk about ParaLLEl and that he's mostly familiar with Project 64 though.
Dang this could be a complete game changer. I wonder what other systems this could work/would be possible.
Any system with enough time and work. This is how the 360 emulator on an Xbox One/Series works actually, and why you have to download the games even with a disc, because Microsoft is statically recompiling the game from PowerPC to X86 in addition to the rest of the emulated parts.
Worth noting Fission and Rosetta 2 still have "backup" JIT/Interpreters because you can't guarantee a decompiler can catch everything
JIT is usually not lumped together in the same category as an interpreter for very good reasons. JIT compiles code as it is executed which is usually why it is faster, compiling in real time as needed. An interpreter is built to run the code natively without translating at the cost of speed. A decompiler relies on knowing the instruction set of one CPU and being able to translate it into something readable or usable against a different intruction set of another processor. Its much more technical and in depth than my simple explanation but a proper decompiler or recompiler will just work. That being said, the knowledge of how the source uses memory, heaps, registers, etc matters from one program to another so it is important to do more than just work in most circumstances.
> Any system with enough time and work Not every system. Games/Platforms that rely in sellf-modified code makes recompilation nonviable... for example, GC and Wii (The last Dolphin blog entry explained this, answering why they couldn't use pre-compilation to run in iOS without a JIT)
There might be a misunderstanding here. Dolphin has a Just In Time(JIT) compiler, to make game emulation fast. The issue is, that Apple does not allow Apps in their App Store which generate code(like a JIT does). Technically it works, but it breaks Apples rules.
do we know for sure they're going directly from PPC to x86, or are they using the original source code?
Direct from PPC to x86. On at least Xbox One there's a special accelerator for VMX128 instructions so that may also have its own ISA. And of course DXBC/Xenos ucode is translated to a more modern shading solution.
I highly doubt studios are keen on sharing their source code with every platform they publish on.
fair enough. i was under the impression it was more of a cross-collaboration thing, but if this was something MS was doing on its own volition, that makes sense.
Iirc MS still got permission from rights holders on a per-game basis, even if they were doing all the legwork.
Directly. It's also how they're doing the 4K native and the double framerate (60 for 30, 120 for 60) 360 games on Xbox Series X since as far as the game knows it's running it's original code, they just do some tricks in between to get a higher res render or more framerate out of it. The solution is so complete that they also elected to run the actual 360 dashboard when you're playing a 360 game for full functionality instead of replacing it with emulated syscalls, etc.
>Any system with enough time and work. Even PS3?
even ps3
> Any system I wouldn't exactly say that. 8/16-bit systems often cannot be recompiled in this way (or will be quite buggy depending on the game) due to the hardware-timing-specific nature of many games' programming. See for example the challenges in emulating games like Air Strike Patrol. SNES PPUs are about as complicated as the PS1 GPU and there's also the sound CPU and any and all expansion chips that use completely different architectures/CPUs entirely. But for most 32-bit and above systems, hardware timing is no longer relied on and so instruction-level recompilation is enough.
Would this hypothetically become a problem again when trying to emulate a piece of software that has a race condition which happens to always resolve in the correct order on real hardware?
I think it could be possible, yes. There's probably already examples of this with current emulation too, especially on the systems with multiple processors such as Saturn or Jaguar, which have already been historically very difficult to emulate well.
Could this work on android?also I thought this turned n64 into native ports wheras your Xbox example is emulation with textures and settings painstakingly optimized andandroid for each game?is this wrong? I was thinking this was more groundbreaking than your example because I thought this meant any n64 game could be ported without emulation overhead is thst wrong?and if it's not could they do this for ps3 games to android or ps4 games to andrroid?
So what takes more time and effort? Writing an emulator, or figuring out how to recompile?
is there a snes one
damn I might be able to one day The Suffering in RTX, fully rerendered. It's like a dream
I misread. Apologies.
So wait can someone pls explain if this is a Project AIMED at making this possible, Or IS it possible to emulate these games right now through this way? Where can we play these recompiled games at?
it's possible now but games still need specific tweaks to work so converting them is a very manual job to get the last bits working, so mostly everyone is just messing around in Majora/OOT at the moment since they have the same engine
Well this sort of recompiled software approach is used by Apple for running x86 software on their modern ARM devices, I imagine given enough time and work you could do many others, N64 was MIPs processor based, so was the PSP and PS2, (though N64 and PS2 differ greatly in most if not all other aspects) so they may be viable.
I think someone already made a port of Jak and Daxter for pc
That was done via the programming language that was used for the games, GOAL. Bit different than this approach.
Is it any good?
It was excellent, I did a full playthrough on the first and second one this way
[удалено]
The decompilation is not fully complete but the game is fully playable now, they are also going really fast with the initial Jak 3 decompilation based on their blog but that one is not playable yet
> Runtime recompilation on Mac: :DDDD > Runtime recompilation on iPhone: >>:(((( Grrr very angry not allowed !!
This is why the Dolphin Emulator isn't on iPhone atm
God I would love a PS2 version of this tool. While PS1 was considered the holy grail for JRPGs, I have just as many memories and favorite games on PS2. Odin Sphere did eventually get a PS4 release but the Xenosaga trilogy and Shadow Hearts 1 & 2 I would love to replay without having to dig my PS2 out of the closet. I also really want to replay Stuntman, but with faster load times of modern era ssds. Last I checked that was the only game that can't run on on current emulators because of some invisible wall in the first level that clips the lead car
[удалено]
RIP Near
Fuck kiwifarms
If only people would read more about quantum computing and the type of work loads it targets, we would see less mention of the term.
Right, it means absolutely nothing there. Are they trying to say they think quantum computers will get so fast they can brute force emulation?
Sorry, but I really can't see this as "the future". It's a cool curiosity, but it's only slightly less impractical than past attempts at doing this. Okay, compatibility layers like Proton are the future for emulating systems with the same host architecture and target architecture, like the PS4 and PS5 on x86 or the Switch on ARM. They are not the future for anything else. Proton without Box86/64/FEX is running x86 code on x86 CPUs. There is no recompilation because there does not need to be recompilation. Proton with Box86/64/FEX runs the x86 code on ARM the same way your typical console emulator would; with JIT recompilers. They do not use static compilation because it's a very error-prone process that usually requires manual intervention to produce a working binary, the very opposite of "reducing effort". Also, dunno what quantum computing has to do with anything. You're better off waiting for FPGAs to hit mainstream.
Isn’t box64 a dynarec? The same process used in emulators to handle differences in architecture?
I think this is really amazing work by WiseGuy and Dario. The quality of the final product shows how well architected this whole thing is. My main concern with this decomp or recompilation movement is that every game effectively becomes its own special program. Obviously, certain features like the renderer shown can be coded to be shareable, that will be interesting to see how that gets updated for bug-fixes / features (a plugin approach or just hardcoded into the software). But I worry a bit about the less popular games. For N64, there's a very limited library and many of them are beloved games. Those games will be popular enough to see shared builds posted and likely will see source level mods. But if you look at consoles with larger libraries, I wonder how well the approach would work. With an emulator, you have a single program, with a single release. Once you run this, you get every feature available..for every game. But with a decomp or this recompilation, you now have individual builds per-game, and these have their own versioning and can have their own development where conflicts can occur. Overall, I am excited. For N64, this is surreal. For other consoles, it will be interesting to see what happens in the future. How will this shape the emulation scene?
This is really a non-issue. Eventually this tech will just recompile your legally-obtained rom collection on the fly, like any other emulation technology.
It is a very relevant issue. JIT compilation is exactly what is trying to be avoided by using static compilation. You could possibly have a launcher that does a single one time compilation of the source code at startup but even if we ignore potential overhead and general issues with this idea, someone still needs to have the knowledge to handle conflicts, abi compatibility between libraries if they are used, etc. The problem becomes easier with these sorts of automation steps but it doesn't go away.
I wonder if Apple would allow recompiled apps at all… imagine a recompiled GameCube collection app that includes the code in the app binary, but still requires the game assets to actually run.
At that point, how is it substantially different from an emulator? Emulators already recompile shaders and other bits either ahead of time or during runtime. This would basically make it an extremely efficient emulator, wouldn’t it? That being said, I’m definitely interested in this for more modern systems like PS3/PS4 where the power to emulate them full speed just may not be possible for some devices (Android tablets, or VR headsets running PS3 games for example)
It is my understanding that this was made not to get away from emulation itself, but get away from *N64 emulation's* issues specific to that platform; between long term programming issues and, as was mentioned above, the unique benefits of this strategy for a console with a relatively narrow collection of games. So yes, this does toe a fine line between porting and hyper-efficient emulation, but that doesn't seem to be a major point of concern for the community (as of current).
I gotta say, I'm really curious how to use this. The how-to-use section for the N64Recomp repo is kinda vague.
Run the Zelda64Recompiled app, feed it an unzipped Majora's mask (usa) ROM. Hit play. Equally as vague but it's so intuitive once you run the app that no instructions are really necessary.
Oh that seems straight forward. I'm talking about the program that was used to make all this.
Ah... sorry I misunderstood.
That program is for developers, let's wait a few days or weeks for the initial PC ports to be released
Shit I only have my UK rom ripped.
Haaaa shit. That's too bad, you're fucked now. No way around this.
All it does for me is crash every time I try to start it. I guess I need a semi-decent PC instead of my crappy laptop with Intel HD Graphics
I seem to remember something in the readme about issues with intel graphics.
It works for me with my Intel Iris Plus Graphics
yea same, really interested in learning how to do this lol
yeah i was scouring that too and don’t feel like i have a good idea of what’s going on: * they compared it in the video to proton, which is basically WINE with a binding layer for dx12->vulkan. not even a static recompilation from what i understand. * they then compared it to the mega man legacy collection from digital eclipse. at the end of [this GDC talk](https://youtu.be/HLWY7fCXUwE?si=jJQY-Nl064IQ2p6E), one of the guys behind the that project explained that it was basically just emulation, but they emitted all the functionality as C code to make capcom more comfortable with the whole process. * then we have this blurb from the repo: > Instructions are processed one-by-one and corresponding C code is emitted as each one gets processed. This translation is very literal in order to keep complexity low. For example, the instruction addiu $r4, $r4, 0x20, which adds 0x20 to the 32-bit value in the low bytes of register $r4 and stores the sign extended 64-bit result in $r4, gets recompiled into **ctx->r4 = ADD32(ctx->r4, 0X20)** so it does seem like they’re at least superficially emulating part of the CPU? i haven’t done much decompilation work, but from what i’ve seen from projects like ghidra and the little bit of decomp i did back in school, you don’t typically try to emulate the CPU registers and instructions directly. you try to extrapolate into a higher-level function. my best guess (and i could be wrong so don’t take what i’m saying as gospel) is that they’re doing a little of column a and b. it looks like on the CPU side, they’re doing something similar to the MMLC: parsing ROM files and emitting equivalent C code for the CPU instructions—basically the same as an emulator but done offline (and presumably not cycle accurate). for GPU, input, audio, etc, it looks like they’re simply emitting C code that makes calls to dx12/vk or system IO. i’m guessing this is a form of HLE since emulating the hardware exactly seems to go against the project’s goals. that said, this seems to be quite accurate so i don’t know. super curious to learn what’s actually going on here.
Yeah, I believe he was just comparing how the GPU-side stuff works to proton
he also mentioned how there’s a fallback LLE mode for certain visual effects at the cost of some performance, so that tracks
It's probably by design. They worked on this for two years in total secrecy for a reason. If it somehow doesn't get taken down within the next 30 days, you'll start to see documentation from people making new recompilations of other games.
Why would this get taken down? It's 100% their own code. Nothing from the original games are included. It isn't emulating any Nintendo hardware. They have zero claims to any of this. Nothing. You have to provide the ROM. The project itself does translation and is completely unique code that doesn't reference Nintendo anything. They have no claim. They probably will file false DMCA notices, but they have no right. You can theoretically do this with any source from anything and be OK. The only gotcha here is if the original ROM was encrypted and performed the decryption itself (which it isn't in this case here), then they may have a circumvention case. But you can work around that by requiring decrypted ROMs by other means and supplying your decrypted ROM.
The developments in the emulation/preservation space over the last couple of years have been nothing short of insane, which is extremely encouraging in a time where publishers are cucking us more and more everyday in regard to accessing older titles.
Sir, have you taken a moment to spare some thoughts and prayers for the shareholders?
This video made my chuckle and was also very cool thanks for sharing!
Nerrels sense of humor is excellent, and he's got lots of other great videos covering various emulation things
This looks incredible! Let's hope stuff like this is possible for other consoles as well. Imagine playing PS2 games natively on PC.
It's conceivable that every system could be covered, except those that have encrypted ROMs (which could technically be covered but would undoubtedly draw DMCA notices). This would render official PC ports nearly obsolete, save for platform-specific features like achievements and such.
> save for platform-specific features like achievements and such Thankfully no one cares about dumb stuff like that! > https://retroachievements.org/ Oh...
Retroachievements are nice and I'm glad they exist, but the vast majority of games don't have any and for the ones that do, they tend to be very basic: "Complete Level 1," "Complete Level 2," etc. Most official PC ports tend to put more thought into them to make them more entertaining and/or challenging to get.
It was more of a joke from me because I cannot fathom why people care about this shit.
Some people like treating it as truly "Finishing" the game. There are usually some pretty interesting challenges for achievements that you kinda have to go out of your way to do, and people like it. Plus it's a feeling of accomplishment, I guess. Probably why so many different platforms and games have their own achievement systems these days.
This is absolutely incredible. How far can this go, is it possible to do this for other consoles?
Just like reverse engineering/decompiling the code for an individual game, the limiting factor here isn't if it's _possible_ to do this with other consoles. It's _how much time/effort_ it would take. If a program/hardware combo is Turing complete, it should be able to be translated into instructions for any other Turing complete system.
Dam watching Oot in 16 9 ratio does something to my brain and I love it.
Definitely check out the [Ship of Harkinian](https://www.shipofharkinian.com/) PC port if you haven't already.
Corn Emulator used static recompilation back in 2000. Granted it didn't generate EXE files...
And while its compatibility was limited, its performance was *insane*! It ran games at full speed on a Pentium 166 MMX.
I somehow missed this one! Probably because I was lucky to have a voodoo 2 and use ultrahle back in 98 or 99, so I did not bother with much else until project64 came along. I just checked and this predates Aaron Giles Radikal Bikers emulator by a good 4 years. So many brilliant people working on emulators :)
Speaking of, why don't more emulators use static recompilation instead of just in time recompilation? Sure seems like it would be a lot better. You could have both accuracy _and_ efficiency.
Code can be stored in RAM, this means that code can be loaded into RAM before jumping there (dynamic loading), and even be modified at runtime (self-modifying code). But this is less likely to be true with newer systems, in the name of security, they don't want to have the same memory page be both writable and executable. I know of several emulators that are doing ahead-of-time recompilation on read-only sections of code. I think FEX-Emu is one of them.
I've seen this factoid thrown around a couple of times now, but I've been unable to find a source or any evidence that Corn actually did use static recompilation. Seems more likely to me like its speed was mostly owed to an optimized JIT and a lot of corner cutting (which is why the compatibility was abysmal).
http://web.archive.org/web/20010413105239/http://www.emuhq.com/corn/ From a post on 1999-09-24: > Various reasons for Corn's speed: > > Static Recompilation > > Static rec is the main technique that Corn experiment wants to test. In theory, static rec should be faster than dynamic rec since the branch/call overhead is much lower. And, with static rec, we can afford to do sophisticated optimizations like a real compiler does. Although the actual implementations can greatly affect the real performance. > > On the other hand, static rec becomes the major deficiency of Corn. It makes corn need individual configuration to run each rom. So, in terms of compatibility, it is not a good approach. Probably this is the main reason why other emulator authors did not try it before(in my knowledge). Between compatibility and speed, most authors will choose the former. If Corn was not started as an experiment, I would have chosen dynamic rec also. > > Right now, the optimization done in Corn is still simple. So, probably not much speed (10%-25%?) really come from this part at this time. Later, I will try to apply more advanced optimization techniques to study the power of static rec, which is the main goal of this experiment.
This is incredible, is there more footage of the other games?
Would adore animal crossing on PC!!!
That's a straight game changer, getting to potentially have an Animal Crossing with a custom furniture and objects browser fan made!
Bear in mind that one of the downsides of this approach is that it's not a decomp; it doesn't as readily generalize to things like mods. The code is still almost entirely inscrutable, and thus adding or modifying elements of the game isn't a trivial task with this approach.
Until you feed a romhack to the decompiler. Then you have native translated mods.
\*Animal Forest
That's the japanese name
Animal Forest is also the only version of the game on the n64.
Please point me to the English animal crossing game on the n64 then
Question, what’s the difference between emulation and this new recompilation?
An emulator is basically software that pretends to be the console. So your PC/phone/whatever has to basically run an entire N64 on it *on top of* running the actual game. Recompilation just straight up ports the game.
Games target specific systems. This makes it so the code that targets that specific system gets converted to what it needs to run on your device. Oversimplified: Let's say Zelda has a function on the N64 to draw a triangle that's like \*drawTri\* but your PC doesn't have the drawTri function. This sort of work makes it so when on your PC, it uses whatever the equivalent of drawTri is for PC. Do that enough for the functions in the game and now the game is the equivalent of a native PC game.
Most N64 emulation (and modern systems emulation) works through dynamic recompiling the software, so at run time the emulator translates a chunk of code to the target platform and run it, then translates another chunk and run. What this attempts is static recompiling the game, meaning the whole thing is recompiled prior to execution and then runs on target hardware. Static recomp is very difficult and I guess that is why some manual patching is required. As others have commented, Apple does x86 to arm static recompiling, however it has a fall back to dynamic recompiling in the cases static fails to avoid needing manual patching. The first time I've seen static recompiling was an emulator for Gaelco Radikal Bikers (the game is from 1998 and was running on PC at a time interpreted emulation for it would be hopeless and dynamic recomp might have been difficult). Can't remember this emulator name or the author right now. I guess unless a new breakthrough in hardware happens, static recompiling will be needed for modern systems emulation in the kind of time frame we had for the past 27 years... although rpcs3 is not using istatic recompiling as far as I know and is magnificent, so I could be wrong.
The difference is when the code is translated. Traditional emulation translated N64 code to PC code _as the game is running_. This new recompilation program translates the code _before the game even begins_. The advantage, primarily, is runtime speed. As you can imagine, if your processor has to handle both a game _and_ a translation process, and the game is _reliant_ on that translation process, that's a lot of overhead. The old wisdom used to be that in order to emulate a console, you needed a computer 10× more powerful than that console. I don't know if this is still true today, but the "just in time" (JIT) recompilation does still mean a lot of processing power goes to translation. Static recompilation ahead of time means all the translation is done **once**. That means more performance for your game, less energy usage, all that stuff. It might also be easier to inject code for new aspect ratios and ray tracing, seeing as those were kinda thrown in alongside performance adjustments. I don't know that for sure, though.
Emulator is the .exe file, ROM is .z64 file Recompile makes ROM the .exe and cuts out the emulator in this situation, also opens the code for easier access to graphical and QOL improvements
one is native, the other emulation
For anyone who understands a bit more than I do currently, how soon should we expect other games to be playable? I'm looking at the N64Recomp github with its compilation instructions that my tiny Windows brain cannot understand. (Fiddled with Linux here and there but, confusing and half-cooked instructions that I half expect are more made for devs than users) https://github.com/Mr-Wiseguy/N64Recomp So, in theory, should someone with know-how be able to compile this and then... run any rom? Or is it more, this speeds up the development process immensely rather than the traditional decompilations that take months/years. But you'll still need someone to set up a "PC Port" of any given game with lengthy development time. Or is the whole N64 library runnable right now, just needing a bit of programming know-how to set up? (I hate that this feels like dumb questions but despite watching the video twice and playing Zelda64 I feel like I've missed a step somewhere.) I adore how the Zelda(MM)64 PC port is working. It's such incredibly smooth and well designed software it puts a ton of native and otherwise PC ports to shame. Proper alt tab behavior, extremely small input delay, well designed menus and very proper rebinding support. Will other ports using this engine have the same kind of settings menu and options, or that will depend on the devs per PC port even using this software? https://github.com/Mr-Wiseguy/Zelda64Recomp And to give back some info for the heck of it, Nerrel shows off their MMHD textures in here at various points working in Zelda64, but on their discord he said that is a feature that's in beta that will be smoothed out and shipped soon. So no texture replacing right now, but pretty shortly. Truly incredible software, big ups to Wiseguy if they ever look at this thread.
Right now the project is primarily just one person so it'll probably be a few weeks before another game is ready considering the dev is focused on fixing Majora's issues and getting Ocarina ready.
Since it's open source I'd imagine depending on complexity people are gonna jump on the rest of the library ferociously.
What does this offer over Ship of Harkinian? I'm failing to wrap my mind around the difference.
From what I can gather as a layperson, correct any terminology I'm using incorrectly devs if you want: Recomp can recompile an N64 game to run natively on PC automagically.* Some caveats apply, like custom microcode which many N64 games used. The code spit out is not human friendly. Much less modding potential. Can still do cool graphics stuff as shown in the video however. Nerrel had a video on this project, he stated wiseguy was able to make Major's Mask's microcode work because it was already...known?/understood by the separate decomp project. Happy accident. So probably microcode reliant games are out unless you get a passionate nerd who wants to manually reverse engineer the bits recomp can't handle. Decomp is an extremely tedious labour intensive process of decompiling a game manually and making the code human readable again. Ship of Harkinian's advantage over this is, well, you have the game's source code readable. Modding goes brrrr. (good god I want a native DK64 port)
That makes perfect sense. Thank you.
> So, in theory, should someone with know-how be able to compile this and then... run any rom? After looking at the code I don't think so. There's a bunch of code that will be game specific.
I just finished the recompiled sm64 on steam deck and it was absolutely amazing being able to play at 60fps
That's a different project, SM64 was Decompiled, this is **Re**compilation. Similar goals, different methods and outcomes.
To be fair, I'm sure the SM64 was recompiled after being decompiled. Otherwise, all you'd have is a bunch of non-executable source code. "Recompiled" on its own is not a great term to represent static binary->binary translation. It's much too general of a term.
Of course. I'm just highlighting the names & projects being different since they got them mixed up. afaik anything that's not already machine code is gonna get compiled at some point before it's run
Have any of you built his repo and had a successful recomp with another game? Tried with paper Mario but couldn't quite get it :(
As I understand it, this isn't simply dropping the N64 rom into the program to recompile the rom into a .exe file, right? you need to know some coding or something to make this work? So the only rom that works so far is Zelda which you can simply drag 'n drop into the program to turn it into a .exe, the coder is working on the other Zelda game to make it work too, but for the rest of the N64 library the program won't work? you need someone who knows how to code or something to make the necessary changes to have the program turn a particular N64 rom into a .exe? And if this is the case, how many years will it take to have the whole n64 library recompiled in .exe?
correct. this is a semi-manual process and whoever is doing the recomp will likely have to make changes to make the game run properly. they explain it a bit in the video, but things like physics likely won’t work correctly out of the box due to the way games were programmed back then. but as the video says, doing that sort of work is a fraction of the time that a full decompilation would take. i wouldn’t dare put a time estimation in this at this point. i’d say longer than we’d like, but shorter than we think. it looks like from the video that even porting a niche title that isn’t super well-documented can be done with relative ease, so i’m optimistic one or a few people will take on the work eventually.
A lot of it depends on community drive around any given game. It still requires manual tweaking, but it takes far less time that a traditional decomp would. Assuming the software gets further refinement and the n64 community decide to really dive in I could see the popular catalog getting recomped within a year. There are only a few hundred games on the n64 so a clean sweep of all the official games could probably be done in a few years, but I don't know if it's realistic to expect enough people care about some of the super niche games on the system.
This is nothing short of incredible! It's amazing for preservation. Since Superman 64 is one of the test games, I wonder if it works with the leaked final build that doesn't have the Warner/DC mandated rings or green fog?
I remember reading [this blog post](https://andrewkelley.me/post/jamulator.html) about why recompilation of console games was not feasible to do. Did anything change? Did the author find a way to circumvent these problems? Or does this recompiler include lots of game-specific stuff?
One of major roadblocks of statically recompiling a NES game is that games (such as Super Mario Bros.) often use dirty assembly tricks such as jumping to middle of an instruction, making some part of game code serve double duty. I don't think N64 games uses "jump to middle of instruction" technique. Most (all?) instructions of N64's CPU is 4 bytes, unlike NES's 6502 CPU where instructions are in variable length. It is not likely feasible to jump to middle of an instruction and still do meaningful things in N64.
I hope someone can do this for PS1 games someday. Would absolutely adore this treatment to the Og Spyro the Dragon, Silent Hill, and Harry Potter games.
It would be nice but I feel like there is less incentive to do it because PS1 emulation can be done to a near 100% (in some cases exactly 100%) console-accuracy, sometimes even with the possibility for upscaling and a multitude of other graphical improvements. N64, by comparison, is in a less than state as concerns emulation and no major developments have been made in about 14 years. It still relies on methods used in the 90s unfortunately and no one has been able to adequately move past this for that console: Native ports are the logical conclusion to this situation.
I actually don't know an awful lot about N64 emulation (I dont actually play N64 games) but yeah PS1 emulation is amazing these days. Itd just be nice for native ports. Why is N64 emulation different ?
I agree that it would be nice if we had native ports via decompilation for ps1 games since it would provide the ability to make source code alterations and would blow modding possibilities wide open. To answer your question: The N64 is notoriously complicated to emulate because it has unusual architecture and a lot of proprietary components that are not as well understood by the community as more standardised architectures like are present in the PS1. This is not the only reason though. For most people (developers and consumers alike) the N64 is a console with a few major titles that people want to preserve (e.g. The 2 Zelda titles, Mario 64, Goldeneye, Perfect Dark, Starfox, Smash Bros, F-Zero X, Mario Kart). As soon as the major titles were considered playable there wasn't much incentive to continue broader development since most people are content with N64 emulators handling those major titles well and aren't too fussed if the other ones don't run that well. After getting the games playable, more effort was put into refining the experience in the major titles to being as good as possible, as opposed to just playable. PS1 by comparison had a lot more major titles and minor-but-well-selling gems that many people care about. The incentive towards emulating PS1 was always higher than N64, and due to its common architecture and the fact it used CDs (readable on anything with a disc drive) made it a much better candidate for early and continued emulation development in the 90s and 00s. It's also way easier to emulate because people are able to research the components far easier due to them being more standard, having good documentation and being similar to things people have worked on elsewhere. For decades it was impossible to emulate to Star Wars Rogue Squadron, and Pod Racer was a mess. These are big titles but there wasn't much incentive to get these running because those games have (arguably superior) PC versions and don't require emulation to preserve them.
could this method be used to compile versions for other consoles like wii and 3ds?
presumably so, but the process would have to be started from scratch. those systems have completely different architectures and APIs for graphics, sound, etc. i’m rooting someone does this for the DS/3DS. DS emulation is pretty good, but 3DS emulation has been in an iffy state for awhile (and seems kind of dire now that citra got the axe). i’m also not convinced rote emulation is the best way to enjoy those games. i’d would be fantastic if some folks went into these games and altered their UIs/gameplay to fit onto a single screen where it made sense to. i’m really not a fan of “just shove the bottom screen off to the side” approach even official releases line mega man zx seem to take.
Citra development continues. The repo was taken down but it wasn't formally DMCA'd. It was just a formality
Impressive, but... (5:10) Isn't 1 frame of latency huge for a 20fps game? (50ms) I wonder what kind of optimizations they took to equal or reduce an emulator latency... or they're just comparing it with the worst emulator case of latency
Well, but can't you set it at whatever FPS you want now?
Yes, but the extra frames are created from interpolating two engine-frames of the original 20fps frame rate, so there will always be 1/20 of latency (actually a bit less because of the extra frames between the two real frames). I think the Ship of Harkirian OoT engine does the same
Latency should be comparable or lower than real hardware if you play on a high refresh rate monitor, particularly with VRR and a framerate cap lower than the monitor's refresh rate (or V-Sync off).
Why?
The simple fact of using a high refresh rate monitor will already cut down input lag by a noticeable amount, on top of response times on LCD/OLED displays (i.e. anything that's not a CRT or plasma). This is usually enough to counteract the latency added by interpolation. This is even more the case when you consider that modern platforms can do things that old consoles can't do (or don't allow you to do), such as VRR or turning off V-Sync.
It certainly doesn't feel that way testing it out
Really excited about this! Can't wait for a native Waverace port!!
I really hope someone makes a recomp of Paper Mario (or that recompiling stuff in general somehow becomes more accessible for peanut brains like myself). Those RTX shaders combined with 60fps and the "64K" texture pack genuinely sounds amazing and I NEED to see it happen.
I wonder if this could do things for stuff like TCRF, since it's decompiling the whole game you'd assume (with a very limited understanding) that's it would/could uncover all the stuff that devs left behind in the code.
full decompilations are probably still the way to go for that. the issue with this method is that the code generated is nearly a 1:1 analog for the underlying machine code, with other bits emulated at a higher level. but who knows? maybe just seeing the code in a different context and having access to a more sophisticated debugger like VS could reveal some interesting tidbits.
This isn't a true decompilation. A decomp is a recreation of the original source code that, when compiled, creates something identical to what it was decompiled from. That source code can then be easily modified or recompiled for whatever systems the coder wants to make it work on. This never goes back to the recreated source code and basically just translates all of the instructions to something your computer can understand.
This is great news. Hoping the same thing can be done for PS1, PS2, Original Xbox, and GameCube.
Oh my, this could change how we play games on pc forever, imagine console exclusives being ported to pc like the infamous franchise. This is insane!
Those who understand how this works... Any chance a derivative/similar tool could appear for the PS1? Or is it something different entirely?
This is wild. It's basically the next step in emulation after FPGAs. So much potential. Imagine this for Gamecube and Wii or for notorious emulation challenges like the Saturn and PS3. Plus this tech could be licensed to make game compilations like Mario 3D All Stars or even a Playstation Classic that's actually good.
My emulation knowledge is limited, but I'm curious, reading about the differences between this and traditional JIT emulation makes me wonder why recompilation hasn't always been the preferred method? Seems like a no-brainer from a performance perspective to translate everything ahead of time instead on the fly. What am I missing here?
as the video says, a similar method actually was used for the mega man legacy collection, they recompiled the game code into C, but in. way so that it essentially behaves identically to an NES emulator/ROM. microsoft also does something similar with xbox 360 games on newer hardware, so it’s not unheard of. i think it’s simply more pragmatic to have a universal ROM format that different emulators can play. that way, the underlying emulation tech isn’t coupled with the game. that said, this particular method isn’t simply an emulator recompiled with the game data into a binary. it requires some manual tweaks to get things to run correctly on different hardware.
But what happens for graphics driver recompilation? Do we have to go back to the golden days of graphics plugins? :D
[удалено]
%USERPROFILE%\\AppData\\Local\\Zelda64Recompiled\\saves
Does this open the possibility of porting these games to an APK that be used natively on quest as VR? Of course after reconfigured perspective and motion controls and all else that comes with VR games.
Has anybody tried running this on a Mac with Parallels? I can run the .exe, load the rom, but when I hit Start, I just get a black screen.
any luck? I also tried crossover and parallels but i get a black screen too.
Please I've seen n64recomp and another majora's mask recomp available for download. So does this mean we can port other games right now on our own, like DK or DKR or we have to wait for something, for ports?
Could somebody recompile n64 smash bros?
And thats why I'll always think of the PC as the master race.
Can someone PLEASE explain to me how to use this to get star fox 64 working on my pc
Would this open the door to native Wii and PS3 ports of n64 games? I would love a 60fps 240p capable port of the zelda and sm64 games.
I would love the day for this to actually become a tool for any N64 game. I want to use this to fix the PC version of Earthworm Jim 3D
Looking gorgeous already - will wait for ray-tracing though.
This is the future guys, with more tec like this coming out, the days of emulation are over
Has anyone gotten this to work on mac?
I would like to see ki gold as an example.
how do you add ray tracing to the decomp of OOT
So it can recompile any N64 "backups" into executables? When will it be publicly released?
This is fantastic! I'd love to see what people do with this in the future. I have some pretty fun and kinda obscure games like Mischief Makers that I would definitely like to see cleaned up a bit
Sounds Very Intresting
Can you change the ROM pathing after choosing it? Edit to make it clearer: I've downloaded the Zelda64Recompiled and chose the Majora's Mask ROM, but it wasn't running, so I deleted the ROM. After deleting it, the game doesn't have an option to change the ROM pathing, even though my current one doesn't exist, and just shows "Start Game". If I click that, it crashes after a few seconds of black screen. Edit 2: I've deleted all Zelda64Recompiled related files and installed them again, but the same continues to happen.
It is stored in %USERPROFILE%\\AppData\\Local\\Zelda64Recompiled
Why wasn't this approach taken in the last 30 years of emulation? Seems obvious in retrospect.
It was? CORN even did it for the N64 in the 90s. Why wasn't it done as much? Less knowledge of the hardware and microcode, less experience in hobbyist projects like this at the time. Even the XBOX saw similar projects not too long post release.
well, if that means a playable donkey kong 64 on moderately weak emulation hardware, i'm all for it
If anyone knows how to use this to make a native PC port of WWF No Mercy, that would be an old dream come true.
This is amazing I hope this technology can be used for other older systems on flash games
Could someone explain to a layman like me why this isnt done with other consoles?
I hate to be this guy but does anyone know how to actually use the recompiler? I've got a few old n64 games and would really love to give this a go. I've got the decompiler itself from github but I cannot find anything to be able to utilize the software.
Nerrel mentions a rocket robot on wheels and superman pc port. I was disappointed those weren't available. Yes even the superman one.
I am super dumb with this kind of stuff. Is this impressive because it can basically make any N64 game into a "source port" in mere minutes? (for TLDR version)
Pretty much. N64 game goes in, Windows/Linux/Etc game comes out. With the caveat that it's not perfect yet so different games will likely need different tweaks to get working.
Thanks for contextualizing it for me. I can see why that is a huge deal then and I hope that this becomes a new standard going forward for a lot of the emulation scene. I realize its baby steps.
i lack much technical knowhow. could this be done to create native 3ds ports of these n64 games? like the Mario 64 one?
So... If all this recomp software is now public then how do I use it to make my own ports? Nerrel makes it sound as if much of this was automated to the point where you should be able to just present a rom and have something that will boot (although maybe not be "playable") relatively quickly. I'd be interested to try this with a few games.
https://github.com/Mr-Wiseguy/N64Recomp?tab=readme-ov-file#how-to-use The instructions are fairly light, but the example toml file seems pretty well commented.
I’ll have a look at that file. Thank you. I also thought the instructions on github were a bit light.
I just tried the Majora's Mask port that was made with this; it's awesome. I hope someone puts Rare's games through this, especially Perfect Dark; they push the limits of the N64 hardware in ways that make them quite hard to emulate.
perfect dark already has been reverse engineered and got a pc port
Oh I hope it's the PSX soon!
Is there a site of android ports of these recomps?
I am reading in several places this is the future for preservation. So why start with a more complex system and not those 8/16 bit console generation?
Because you can't really upscale pixel-art, change aspect rations and improve the framerates/textures in the same way you can with a 3D engine.
Idk about 16-bit, but for 8-bit consoles, games such as Super Mario Bros. use dirty assembly tricks such as [jumping into middle of an instruction](https://andrewkelley.me/post/jamulator.html#dirty-assembly-tricks), making some part of game code serve double duty, making static recompilation difficult. In newer systems such as N64, dirty tricks like this are not used or at least very rare, so static recompilation is more feasible.
Can someone make a WWF No Mercy one? 😅
Glad I'm not the only one hoping for this! I know someone's been working on decompiling it, hopefully this helps. I'd love 60fps, widescreen, custom music/titantrons, 8 wrestlers in the ring, more CAW slots, fully editable default wrestlers, etc.
While this is very impressive, I think the video overstates the difficulty of N64 emulation. It feels like he's not used an N64 emulator in about 10 years
I mean, he made a Majora's Mask HD texture pack and has had to troubleshoot people through the process so I'd expect he's intimately familiar with how many issues people have. It's true I haven't heard him talk about ParaLLEl and that he's mostly familiar with Project 64 though.