Parallel N64: low quality when using cool new speed options

Hey folks! After the awesome news about Parallel N64 a week or so ago, I figured I’d give the new core a shot. Without having any previous experience with it, I noticed that the graphics quality dips sharply when I set the cool new speed features described here:

This is what GoldenEye looks like when the core is launched out of the box, with its default config:

When I set ‘GFX Plugin’ to ‘angrylion’, and ‘RSP Plugin’ to ‘parallel’, it looks like this:

What am I doing wrong?

1 Like

Nothing wrong. Angrylion is an LLE, native res plugin, so it looks like an actual N64 and is very demanding. It also runs almost any game without special hacks or workarounds.

If you don’t want that, you can still use the HLE plugin(s) and you can still use the LLE ParaLLEl-RSP with them if you want.

1 Like

Also keep in mind that any other plugin in ParaLLel besides Angrylion is very old and pretty much obsolete. If you want to use an HLE plugin for higher-res graphics you are much better off with mupen64plus-next and it’s version of GlideN64.

To tell you the truth, i have no idea why all these very old plugins are in Parallel to begin with. I don’t think Rice has been a thing for at least 15 years now. It should have been only Angrylion and GlideN64 (not to be confused with Glide64). These two are the only ones that matter for N64 emulation right now.


I find it looks and Runs better when GFX and RSP Plug-Ins are set to Auto

Thanks guys! That clarifies a little. I find there’s a lot of terminology here that I’ve yet to understand. I’ll re-read the Mupen64Plus Libretro doc and do some more reading on N64 emulation in general.

1 Like

Yeah, N64 emulation is a bit tricky considering all the different plugins and options. But to simplify things you can’t go wrong with this:

If you want N64 with better graphics but high enough accuracy and the best compatibility rate use Mupen64plus-next (it uses the latest GlideN64 code by default, that’s the best and only HLE plugin that matters).

If you want the most authentic N64 experience (with it’s low-res filtered graphics) and highest accuracy use ParaLLel with Angrylion, assuming your machine can handle it. Just avoid the other plugins and also avoid using “auto” because that just uses the other plugins.


Oops, I tried editing my post to add this link but I can’t. Sorry for double post!

Here are the specs for the 3128 if you’re wondering:

Hi GemaH!

Thank-you for the information, it is helpful for this noob here (me). I have this handheld gaming device with a RK3128 inside.

I’m wondering if the RK3128 would be strong enough with it’s specs to run the ParaLLel with Angrylion?

(I’m a complete noob right now and these components are currently gibrish to me, I’m new to all of these components however I am capable of coding and understanding the system.)

I will do my due diligence to google, any help would be appreciated though.

Thanks :slight_smile:

Even high-end handheld devices can’t handle Angrylion, not even the new, fastest version with dynarec. It’s only for good gaming desktop PCs atm.

Hi, I’m sorry if this is not directly related to the topic but it seems close enough and I can’t create a new topic.

I’m using RetroArch 1.9.0 (through Steam) with the Mupen64Plus-Next core to enjoy some N64. For the life of me I cannot work out the following:

What is the difference between the following two configurations:

  1. CPU Core set to Dynarec, RDP Plugin set to ParaLLEl-RDP, RSP Plugin set to ParaLLEl
  2. CPU Core set to Dynarec, RDP Plugin set to Angrylion, RSP Plugin set to ParaLLEl
  3. CPU Core set to Dynarec, RDP Plugin set to Angrylion, RSP Plugin set to CXD4

(Please assume, for the sake of this question, that when RDP Plugin is set to Angrylion multithreading is set to “all threads”)

I cannot work out the difference in practice between the 4 above options. Particularly, what’s the difference between the first two; I always thought that ParaLLEl was simply a multithreaded version of Angrylion, but it seems that Angrylion can now be set to multithread, so what’s the difference?

Many thanks for your help!

ParaLLEl-RDP is not actually related to Angrylion at all. The author compared ParaLLEl-RDP’s output against Angrylion’s, pixel by pixel, to ensure correctness, but that’s the only real connection.

ParaLLEl-RDP is a software-rendering plugin that uses Vulkan compute shaders to do the software calculations massively in parallel (hence the name). Sort of like using CUDA or OpenCL, if you’re familiar with those technologies, but all inside of shaders instead of using those specific languages and frameworks. The big drawback is that it requires some advanced Vulkan extensions, which some GPU vendors neglect to support in their drivers (when you run into this, it’ll usually print a big ERR in block letters on the screen).

ParaLLEl-RSP is a highly accurate, LLE dynarec for the RSP. It is comparable to cxd4, but since it’s a dynarec, it runs much faster, similar to the CPU dynarec vs interpreter.

Threaded angrylion runs entirely on the CPU, which makes it work on more hardware, but it’s slower/more demanding, even with the threading (the single-threaded version is unusably slow even on modern CPUs). It also doesn’t support any fancy stuff, like increased internal resolution.

So, with those things in mind, ParaLLEl-RDP plus ParaLLEl-RSP is going to give you the fastest LLE/accurate setup with the added ability to upscale. The drawback is you need advanced Vulkan support and good drivers to run it.

1 Like

@hunterk, what an amazing and thorough answer, thank you so much.

So the author of Parallel was indeed satisfied that their output corresponded 1:1 to Angrylion?

I’m running a 980Ti and I’ve had no obvious rendering issues using Parallel RDP and RSP. In my use case, is there any reason at all I’d run Angrylion?

Thanks again bud!

Yes, it should be 1:1. If your computer runs ParaLLEl-RDP and -RSP, there’s no reason I know of not to use them.