Parallel N64 with Multithreaded Angrylion released!

We originally intended to release this together with the new RetroArch version right before the end of this month. However, we want to take a few more days to ensure that the release of RetroArch 1.6.8 is solid and that we don’t rush it out of the gates in a premature state. We ask for your patience, it won’t take too long, a couple of days at most. In the meantime, we have the Parallel N64 core with multithreaded Angrylion ready to go!

This is a heavily modified version of ata4‘s Angrylion RDP Plus plugin. It has the following distinctive characteristics so far:

1 – Made a bunch of changes so that performance in Linux/Mingw is not as bad as it was previously (still worse than Windows though).
2 – Does not require OpenGL context 3.2, or OpenGL at all. It is purely a software renderer that can use any output video driver you want in your libretro frontend. So you can use this in conjunction with OpenGL, Direct3D, Vulkan, etc.

Credit goes to mudlord, Brad Parker and AIO for being able to get this done in such short notice. I helped out along the way too.

Available for

  • Linux
  • Windows
  • Android

Where to get it

1. Start RetroArch.
2. Go to Online Updater -> Update Cores.
3. Download ‘Nintendo 64 (Parallel N64)’ from the list.

How to use it

1. Start up the Parallel N64 core with any game.

2. Go to Quick Menu -> Options. Make sure that you set ‘GFX Plugin’ to ‘angrylion’ and ‘RSP Plugin’ to çxd4′. Restart RetroArch.

3. It should now use multithreaded Angrylion as the graphics plugin.

Performance

This scene serves as our benchmark test. Fullspeed framerate has been enabled.
This scene serves as our benchmark test. Fullspeed framerate has been enabled.

For the purpose of this performance test, I am running the game Super Mario 64.

The system on which the tests are being performed is a Core i7 7700k processor with 16GB of RAM running Windows 10 and Linux respectively.

Windows

CPU Core Angrylion version OS Performance (with VI Overlay on) Performance (with VI Overlay off)
Cached interpreter Windows 10 Old Angrylion 52fps 63fps
Dynarec Windows 10 Old Angrylion 52fps 64fps
Dynarec Windows 10 New Angrylion Multithreaded 114fps 123fps
Cached interpreter Windows 10 New Angrylion Multithreaded 106fps 118fps

Linux

CPU Core Angrylion version OS Performance (with VI Overlay on) Performance (with VI Overlay off)
Cached interpreter Linux Old Angrylion 53fps 63fps
Dynarec Linux Old Angrylion 55fps 65fps
Dynarec Linux New Angrylion Multithreaded 72fps 84fps
Cached interpreter Linux New Angrylion Multithreaded 69fps 82fps

macOS

Too slow to be worth bothering with, singlethreaded Angrylion actually turned out faster here. That is why the Mac version will still be using the old Angrylion version.

Videos

Conker’s Bad Fur Day

Banjo Tooie

Biohazard 2/Resident Evil 2

Killer Instinct Gold

Super Mario 64

Sources

https://github.com/libretro/parallel-n64

https://github.com/ata4/angrylion-rdp-plus/commits/master

Performance tips

Some core options have the potential to dramatically improve performance.

Quick Menu -> Options -> Framerate – You can set this to either ‘Original’ or ‘Fullspeed’. Original will attempt to run the game at its original framerate, while Fullspeed bumps it up to 60 V/Is. Note – if you find a game is running below fullspeed on your system, consider setting this to ‘Original’. I know that in Conker’s Bad Fur Day and Pilotwings 64, there is a big performance impact if you set it to ‘Fullspeed’.

Quick Menu -> Options -> VI Overlay – Disabling this can give you a 10 to 20fps speedup at the expense of the VI overlay’s filtering being lost, leading to a more pixelated but less blurry image. Also note that some games may not work properly with VI Overlay off right now, such as Resident Evil 2.

How to improve the graphics

In case you find the N64’s native resolution and blurry VI filter to be unpalatable, we want to bring your attention to various things you can do to improve your graphics.

In this video we will be showing you how to apply a so-called ‘Super VI Mode’ filter in order to improve the N64’s graphics.

Note – how these shaders will perform depends entirely on the power of your GPU. The configuration you see later in the video (nnedi-4x) requires a lot more GPU power than the former one (2x). Be mindful of this.

This video will teach you:
* How to load shader presets
* How to stack additional shader chains on top of existing shader presets
* How to configure shader parameters to adjust the screen.

We hope this video will tickle your curiosity so that you will try to hit upon even more fancy shader configurations! The sky is the limit with RetroArch and our common shaders library.

Shader Changes

Abstract

GLSL shaders now preferred over Cg when possible
Update to latest RetroArch for compatibility with updated GLSL shaders

Cg shaders demoted, GLSL promoted to first-class

Portability and compatibility are major goals for RetroArch and libretro, so we invested heavily in Nvidia’s Cg shader language, which worked natively anywhere their Cg Toolkit framework was available (that is, Windows, Linux and Mac OS X), as well as on PS3 and Vita, and could be machine-compiled to messy-but-usable GLSL (lacking a few features, such as runtime parameters) for platforms that lacked the framework (primarily ARM / mobile platforms). Cg was also so close to Microsoft’s HLSL shader language that many Cg shaders will compile successfully with HLSL compilers, such as those available with Windows’ D3D driver and on Xbox 360.

This was great for us because we could write shaders once and have them work pretty much everywhere.
Sadly, Nvidia deprecated the Cg language in 2012, which left us in a bad spot. Since then, we’ve been limping along with the same strategy as before, but with the uneasy understanding that Nvidia could stop supplying their Cg Toolkit framework at any time. Rather than sit idly by, waiting for that other shoe to drop, we took it upon ourselves to hand-convert the vast majority of our Cg shaders to native GLSL with all of the bells and whistles. TroggleMonkey’s monstrous masterpiece, CRT-Royale, still has a couple of bugs but is mostly working, along with its popular BVM-styled variant from user Kurozumi. Additionally, before this conversion, many of our Cg shaders were flaky or completely unusable on libretro-gl cores, such as Beetle-PSX-HW’s OpenGL renderer, but these native GLSL conversions should work reliably and consistently with any core/context except for those that require Vulkan (namely, ParaLLEl-N64’s and Beetle-PSX-HW’s Vulkan renderers).

With the GLSL shaders brought up to speed, we can finally join Nvidia in deprecating Cg, though it will still remain as an option–that is, we’re not *removing* support for Cg shaders or contexts at this point–and we will continue to use it where there is no other choice; namely, Windows’ D3D driver and the Xbox 360, PS3 and Vita ports. Moving forward, our focus for shaders will be on native GLSL and our slang/Vulkan formats, though we will likely still port some to Cg from time to time.

RetroArch now correctly handles #version directives in GLSL shaders; GLSL shader repo updated to match

There have been a number of updates to the GLSL shader language/spec over its long life, and shader authors can use #version directives (that is, a line at the top of the shader that says #version 130 or whatever) to tell compilers which flavor/version of GLSL is required for that shader. However, RetroArch has long had a strange behavior whereby it injected a couple of lines at the beginning of all GLSL shader files at compile time, and this broke any shader that attempted to use a #version directive, since those directives must be on the first line of the shader. This meant that our shaders couldn’t use #version directives at all, and all of our shaders lacked #version directives until very recently for this reason. These #version-less GLSL shaders are still perfectly compliant GLSL because GLSL v1.10 didn’t support directives, either, but the necessity of leaving off the #version started to cause some problems as we whipped our GLSL shader library into shape.

The error caused by adding a #version directive under the old behavior.

On AMD and Nvidia GPUs, the compilers would just toss up a warning about the missing directive and still expose whatever GLSL features were available to the GPU, which worked out great. On Intel IGPs, however, the compiler tosses the error and then reverts to only exposing the features available in ancient GLSL v1.10 (released way back in 2004). As a stopgap, we gave many shaders fallback codepaths that would still work in these circumstances, but a number of other shaders were either impossible to make compatible or even the compatible result was imperfect.

So, as of this commit (courtesy of aliaspider), RetroArch will no longer reject shaders with explicit #version directives, and we have added those directives to any shaders that require them at the lowest version that still compiles/functions properly. That is, if the shader doesn’t use any features that require greater than #version 110, they will still have no #version specified, and any shader that requires #version 120 but not #version 130 will not have its requirements increased to the higher version for no reason. This should keep our GLSL shaders as compatible as possible with older hardware, and including the #versions explicitly when needed will also make it easier for other programs/developers to utilize our shaders without any unnecessary guesswork due to behind-the-scenes magic.

This change does require a clean break, insofar as older versions of RetroArch will choke on the new #version directives (that is, they’ll fail to compile with the “#version must occur before any other program statement” error pictured above), so users with Nvidia or AMD GPUs must update their RetroArch installation if they want to use the updated shaders. Users with Intel IGPs will be no worse off if they don’t update, since those shaders were already broken for them, but they’ll probably *want* to update to gain access to the many fancy shaders that now work properly on their machines.

Mobile GPUs using GLES had many of the same issues that Intel IGPs had, with many shaders refusing to work without #version directives, but GLES compatibility added in a further complication: GLES requires its own separate #version directives, either #version 100 es or #version 300 es, which are different from and incompatible with desktop GL’s #versions. To get around this, we added a trick in RetroArch to change any #version of 120 or below to #version 100, which is roughly comparable in features to 120, and any #version 130 or above to #version 300 es whenever a GLES context is used. This should get everything working as effectively and consistently as possible on mobile GPUs, but if anything slipped through the cracks, be sure to file an issue report at the GLSL shader repo.