The bad state of N64 emulation

Unlike PS1 which is from the same era, N64 emulation is generally poor and can be viewed like a hack on top of a hack on top of a hack.
As I understand it, that PS1 had a better library of games so developers gravitated more towards perfecting PS1 emulation sooner and it is indeed a weaker system compared to the N64 so it was easier to emulate.
On the same train of thought, developers got ‘playable’ Mario 64 and Zelda games with a big pile of hacks so the rest of the library were much less important to perfect and remained very much buggy/glitchy.

Here comes Angrylion plugin that mends almost all the problems of the past and raises emulation compatibility to 99% but is very slow even on modern machines.
Very talented programmers ported Angrylion to run on the GPU and offload the main CPU but it requires Vulkan drivers that are buggy and unstable themselves.

In my eye a good emulator should provide a similar experience to the real console, that is, run a game and play it without any noticeable abnormalities/glitches/stuttering/slowdowns/crashes within hours of gameplay, just a “smooth sailing” experience like the hardware console.
Retroarch bridges this “smooth sailing” experience with with its fantastic gamepad controlled GUI and emulation ports (cores) on most systems, but the core itself should be solid.

Generally speaking the state of N64 emulation is getting better but I cannot say that it is as compatible and fast as PS1 emulation.
Maybe when Angrylion be ported to OpenGL instead of Vulkan we’ll see a grand step up in general performance and compatibility across many devices; but as of now N64 emulation feels like a hack job to me.

Any thoughts?

They didn’t port angrylion to the GPU, they made it multithreaded. It’s still CPU only. Performance doubles in general but it still will lag in some games without a very powerful CPU. It’s supposed to support all video backends but maybe theres still some bugs. Don’t expect performance improvements between vulkan/opengl for it though.

I think N64 emulation is quite good in general, most games run fine since my first computer back in 2006, Doom 64, Banjo & Kazooie, Super Mario 64, Mario Kart, Perfect Dark, Cruisin’ USA and the list goes on and on. Comparing N64 to any other system won’t bring the answer at all, we can say Saturn emulators i.e., SSF and now Mednafen Saturn core achieved accurate emulation state with really few issues. Uneeded to say that PS1 crushed Saturn in terms of worldwide success, even so Saturn emulators don’t need plugins or hacks to work accurately and the few developers involved managed to make a solid emulator for this system.

I’m not sure what system you’re using N64 emulation for, I tried it both in Windows and Android, the latter using MupenPlus, even on a Xperia SP, which has a 1.7 Ghz dual core and a 400 Mhz GPU I could play all games I wanted at full speed, in Windows I use Mupen64 core and I don’t see problems at all.

Can you point specific games/issues so I can check them here?

Something that has to be understood about the fifth generation is that the PS1 was the only system that developers could consider “easy” to develop for; the N64 and Saturn both had pretty complex architecture that made them walled gardens for developers. The main difference though is that the N64 was hard to program for reportedly because Hiroshi Yamauchi wanted to reduce the amount of shovelware on the system (a plan which failed for all intents and purposes if games like Superman 64 are any indication), while the Saturn was just bad design (as in, Sega just slapped a second CPU on the motherboard at a moment’s notice without any cross-talk).

In reference to the main point of this discussion, the N64’s difficult technical design is exactly why emulating the system is still pretty hard for everyone not named Nintendo. Emulator developers are still trying to figure out all the ins and outs of the N64, and it definitely shows. However, if the recent emergence of a finally competent Saturn emulator (one that RetroArch even supports no less!) is any indication, I’d say N64 emulation will improve over time. We just need to GIVE the developers of these emulators time.

The ParaLLEl vulkan RDP is basically a port of Angrylion to a Vulkan compute shader. Think of it as software rendering on the GPU instead of the CPU. It’s something that’s never been done before in emulation.

This can’t actually happen. The problem with emulating N64 on OpenGL is that the hardware inside an N64 simply doesn’t map to the API very well. That is, it was based on (severely dumbed-down) state-of-the-art graphics hardware from the time, but shortly after, graphics hardware went in an entirely different direction, and many of the things that the N64 hardware is good at and were abused by the programmers simply don’t exist in a modern graphics pipeline. The early Glide accelerators were actually pretty similar to the N64 hardware, which is why the Glide plugin was able to do so well so early.

As I mentioned earlier, ParaLLEl is only able to do what it does because it’s a software renderer that runs on the GPU. That is, it’s not a traditional hardware-accelerated plugin, where the original system functions are mapped/translated to a modern API.

There are some other complications with N64 emulation that make it a special case: I’m not sure when it was leaked, exactly, but there’s an archive of documents and code, including HDL for the actual RDP and RSP chips, and it’s known as the “Oman” archive. This information was covered by NDA and the guy who leaked it went to jail for a while over it, as I understand. Now, this archive is a goldmine, but its illegal nature meant that anything you learned from it was tainted (technically, even looking at it means you’re not supposed to work on open source N64 emus anymore), so devs would take bits here and there and pretend they had magically reverse-engineered it. All of this happened in secret, of course, so everyone on the outside just assumed these guys were inscrutable RE geniuses, and there’s no way to know which discoveries/information are clean and which are not.

Now, I’m not trying to denigrate anyone’s work; it’s still difficult to do that stuff, working from a bunch of docs and code that go into excruciating detail on things you don’t care about but then leave big holes in things you do care about. But what it did was acted like steroids in an athletic competition. That is, the doping got us farther than we should have been in a lot of ways, but with a lack of fundamental understandings and with no foundation of RE to build on, so we eventually just hit a brick wall when the tainted archive could only take us so far. This is what got us to the “hacks upon hacks” situation we find ourselves in today.

Angrylion RDP plugin works great and solves a lot of the issues that have plagued N64 emulation since the beginning, but it’s very hard to work on/with and some of the design suggests that it is essentially a cleaned-up machine HDL-to-C conversion of that same Oman code. Now, that’s pure speculation and may have no basis in reality, but the very suspicion is emblematic of the long shadow cast by the Oman leak.

So, TL;DR, N64 is a unique situation for both technical and human reasons, and the scene’s “original sin” has far-reaching and unexpected side-effects.

3 Likes

Don’t mean to derail the conversation, but I use the Angrylion renderer on Parallel since it’s the most accurate plugin faithful to the original N64. My question is should I be using Vulkan as my default Video renderer for Retroarch, or does it matter? I’m currently using OpenGL as my default.

It doesn’t really matter. If you regularly use any cores with libretro-gl renderers (Citra, PPSSPP, etc.) you’ll probably want to stick with GL. If you only use software-rendered cores and/or ones with Vulkan renderers available (e.g., Beetle-PSX), you can go with Vulkan.

The slang shaders are more predictable than the GLSL versions, so if you’re big into shaders, that might be a good reason to go with Vulkan over GL.

1 Like

Awesome, I’ll try it. Thanks.

1 Like

I don’t think the Oman incident still resonates in the minds of n64 emulator programmers, knowing the patent term was due 2 years ago in 2015.
Take SNES on FPGA for example, there is a chance that the reverse engineering matches very closely the original design but there was no stolen documents as reference, nor Nintendo makes a lot of noise about clone console flooding the market in the recent years since the patents for the SNES expired.
So Nintendo is in no position to sue anyone related to the N64 emulation/clones since 2015.
Hopefully N64 will continue to improve and GPU ported Angrylion will become the speedy default of the N64 emulation across all platforms.

As for Angrylion on Vulkan;
@hunterk, do you mean Vulkan can can run CPU instruction on the GPU?
I am not very familiar with how GPUs work.

It’s not a matter of patent expiration, it’s about what constitutes legal or illegal reverse engineering. Just because the patent expired doesn’t mean I can take stolen HDL and spin out a legal FPGA RCP.

No, it’s the same calculations but not the same instructions. GPUs traditionally do work on graphics information but “compute shaders” can leverage the massively parallel architecture of GPUs to do general calculations (similar to OpenCL/CUDA but with some various pros/cons). The task has to be appropriate for the hardware and the code must be written specifically for it, but in the right situations, it can provide big performance jumps over CPU-based computation.

I get better performance in Project64 using Zimilar’s RSP LLE mode than CXD4, and Angrylion Plus ran well on most games with FX-8350 4.0 ghz. So far, the LLE is the only bottleneck. Only side effects of using Angrylion Plus in Multithreaded is the noise is not accurate, as seen in locked characters in SSB character selection and Pichu scene in intro of Pokemon Stadium 2, as well as minor shadow map glitch in Conkers.

I think N64 emulation has come quite a long way since the early days of Project 64. No, it’s by no means as mature as Playstation emulation. I remember that there was a day that I wouldn’t even touch N64 emulation because it was so ridiculously buggy and glitchy. The Mupen64Plus core does a pretty amazing job as many games don’t seem heavily plagued with ridiculous bugs. I think what also held back the development of N64 emulation accuracy was the wow factor of looking at N64 graphics in a resolution that they should have been. That seemed to be the only thing people cared about for the longest time because the N64’s native resolution was definitely its major flaw. People would have rather played a glitchy mess as long it was in a high resolution. I think now people are finally wanting accuracy over eye candy.

2 Likes

It may be out of patent, but the copyright will still be valid for another century or so. In the case of leaked code, copyright law is the issue.

2 Likes

Yes, very much.
I greatly prefer hardware accurate 320x240 w/dithering emulation, than 8K resolution with hi-res texture packs and extra AA filtering, xBRZ crap.

As I usually say, true to hardware audio/video and smooth (stutter, lag, micro-freeze free) experience is what makes good emulation good.
Software based Angrylion or Higan, are there in audio/video but not in smoothness, so I don’t consider them ‘good emulation’ by my book.

Count me among those that prefer accuracy over eye candy. Angrylion runs pretty well for most games that output in 320x240 resolution, but some games still stutter and slow down tremendously (Conker’s Bad Fur Day, Banjo Tooie, Quake II). And forget about games that run in high resolution 640x480; I can’t seem to get any of those games running smoothly with Angrylion.

1 Like

What about retropie/raspberry pi? That’s definitely the best SBC on the market, right? I’ve read about all the cool things you can do on it, so why aren’t people developing decent 64 emulators? I would absolutely love a good Zelda or Mario Kart emulator, as those were the games I played the most back in the day.

Those things are incredibly underpowered.