So, it’s been a long time since we (prematurely) announced our intent to launch RetroArch on Steam. We’re nearing the finish line now however, so now is as good as any a time to start discussing how things are going to roll out.
Will launch on Windows first (Linux later)
We will be releasing on Windows first, with a release on Linux scheduled later (no ETA).
We are trying to limit our support burden at launch here since we are (understandably) concerned about the large amount of support requests and feedback we are bound to be receiving. Adding Linux right from the bat would further exacerbate that.
10 Cores Available On Launch Day
We are deciding to launch with 10 cores at launch. These cores have already been approved and uploaded on Steam. They are as follows:
There will be no ‘Core Downloader’ in RetroArch, or anything that is not hosted on Steam in fact. To obtain cores, you need to install cores separately that we provide as ‘DLC’. These are all free just like RetroArch itself.
NOTE: We need to stress – on its own, without installing any of the cores, the most you will be able to do with RetroArch is watch some movie files and playback music files through its builtin ffmpeg core. To make it do anything else, you will have to install cores.
Differences between regular RetroArch and Steam version
Apart from these aforementioned changes, there will be no substantial differences for now in the Steam version. We understand that even though we have consistently improved the User Experience and tried to make things more easily accessible that we will still be in for a lot of criticisms over the initial learning curve, so we’ve pretty much resigned to the fact that this will happen and will just brace for impact and try to do as much as what we can with the criticism that will inevitably be piling on. We will try to do our best to be as receptive to the feedback as possible with the thickest amount of skin possible, and try to suitably make some much needed UI changes.
This is also what helped inform our decision to go with 10 cores. We could have launched with over 60 cores, sure, but the ensuing fallout would have been a mess and it would have been near impossible to focus on bug reports and issues piling in. By focusing on 10 cores, we can do some much-needed Quality Control where issues inevitably get picked up, we can respond to it and in the process improve the quality of the core. This kind of isolated feedback time with a specific batch of cores is something we have found ourselves in the past always lacking, since it was always off to do the Next Big Thing as new features, cores, and other developments are made on an almost weekly basis. This gives us the much-needed time to focus on a specific batch of cores and polish them before we move on to the next batch of cores.
What a massive release we have for you today! M4xw has been really delivering the goods now and we’re pleased to release Mupen64plusNext 2.0 today. This release would not be as significant as it is today without the combined efforts of LuigiBlood, Gillou, Fzurita and Themaister.
The latest version is now available on Android, Linux, Windows, and Libnx (Switch)! Updating to the latest core is as easy as starting RetroArch, going to Online Updater, and selecting ‘Update Installed Cores’. If you have not installed the core yet, instead go to Online Updater and select ‘Mupen64 Plus Next’ or ‘Mupen64 Plus Next GLES3’ from the list.
Previously, only Parallel N64 had 64 Disk Drive support, courtesy of LuigiBlood. Work on it was left rather incomplete though.
Mupen64Plus Next now has a new implementation that LuigiBlood feels more comfortable with. Currently the way that you load 64DD content with Mupen64 Plus Next is completely different from how you do it on Parallel N64.
First, you need a BIOS file. Make sure the file ‘IPL.n64’ is located in your /Mupen64plus directory.
You can either use the subsystem for 64DD, or you can name the disk image the same as the ROM including extension.
If you need to load a specific cart with the Disk image, that would be: “homebrew.n64” and “homebrew.n64.ndd” then Load Content “homebrew.n64”.
Angrylion and GlideN64 in same build!
Previously, Mupen64Plus Next only had GLiden64 as an RDP graphics option, and only ParaLLel N64 had Angrylion.
Now, Mupen64Plus Next has both, and allows you to choose between them. To do so, go to Quick Menu -> Options, and change RDP Mode. Angrylion is a low-level software-rendered accurate renderer, while Gliden64 is a high-level emulation OpenGL renderer.
Angrylion is the most accurate the graphics are going to get with an N64 emulator – and it can be made relatively fast now thanks to the multithreading capabilities of Angrylion RDP Plus, as well as the Parallel RSP dynarec. You cannot internally change the resolution with Angrylion beyond what the N64 was capable of.
Gliden64 on the other hand takes a more pragmatic approach and emulates the RDP with a high-level approach. It is an OpenGL renderer. You can upscale the graphics, and there is a wide array of settings to tweak.
Most regular people will probably be satisfied by Gliden64 and HLE RSP, and indeed, for many platforms, that might be the only feasible way of attaining fullspeed. But Angrylion definitely fulfills a niche for those that want a more accurate portrayal of N64 graphics – and combined with an upscaling shader, it can still look remarkably good.
Parallel RSP support
Parallel RSP saw its first debut in ParaLLel N64, and now we have it backported to Mupen64Plus Next as well! Read our articles here and here for more information on Parallel RSP.
Parallel RSP is a Low-Level RSP plugin that serves as a replacement for Cxd4. You can use it in combination with Gliden64 and/or Angrylion. With Angrylion you are pretty much required to use either Parallel RSP or Cxd4 as your RSP plugin, HLE RSP won’t work. Cxd4 is an interpreter RSP plugin while Parallel RSP is a dynarec RSP plugin. Parallel RSP should be noticeably faster across the board than Cxd4.
You might see better performance with Mupen64plus Next and Angrylion/Parallel RSP vs. ParaLLEl N4, because Mupen64Plus Next uses the New_dynarec CPU core. ParaLLEl N64 instead uses the Hacktarux dynarec CPU core, which can be a tad bit slower.
NOTE: You can also use Parallel RSP in combination with Gliden64. While HLE RSP has made significant strides in emulating the vast majority of known RSP microcodes, there might still be some microcodes that have either not been reversed at all or were not accurately reversed. In this case, an LLE RSP plugin is always an option, and Parallel RSP ought to be the faster one of the two options.
Angrylion + Parallel RSP on Android – approaching fullspeed on high end phones?
Angrylion is now available as an option for both Parallel N64 and Mupen64plus Next on Android.
Mupen64plus Next definitely has a performance advantage over Parallel N64 when it comes to Angrylion. Tests have shown that the first area in Mario 64 gets about 50-51fps on a Samsung Galaxy S10+ American Snapdragon version and 40/45fps on a Samsung Galaxy S10+ European Exynos version.
Will the next generation of phones be capable of pulling off Angrylion at fullspeed? It’s certainly a tantalizing prospect!
NOTE: There might be several ways you have to ‘nudge’ your Android device to get the best performance out of Angrylion/Parallel RSP. Some things you can try:
– Enable ‘Sustained Performance Mode’. If you find it helps with the framerate, leave it on. If not, disable it.
– Enable ‘Disable Expansion Pak’. It might result in a small performance boost for games that don’t support the Expansion Pak.
– Go to Quick Menu -> Options. VI Overlay can have an additional performance impact on the framerate. ‘Filtered’ is the most demanding option while ‘Unfiltered’ should be fastest.
– Go to Quick Menu -> Options. ‘(AL) Multi threading)’ is set to ‘all threads’ by default, but in case for whatever reason the software does not make the right core determination, you might want to set the amount of cores manually here. Base this number on the amount of CPU cores that your Android device has.
The HVQM RSP microcode has now been implemented for HLE RSP (thanks to the combined efforts of CrashOveride and Gillou). In the past, the FMVs for Pokemon Puzzle League would only show up if you used Angrylion and an LLE RSP plugin. Now the graphics glitches in Pokemon Puzzle League and Yakouchuu II should be gone! This means that you can now use the GlideN64 renderer for these games as well.
Difference between ParaLLel N64 and Mupen64Plus Next
Available plugins Mupen64Plus Next: Gliden64, Angrylion
Available plugins Parallel N64: Glide64, Parallel RDP, Rice, GLN64, Angrylion
In Mupen64Plus Next’s favor – it is based on a much more recent mupen64plus-core version than Parallel N64, and thus has benefited from years of fixes and architectural improvements. It also uses the New_dynarec CPU core on Windows/Linux/Mac. It is a bit faster than the Hacktarux dynarec from Parallel N64.
There are also currently some disadvantages. The sound is currently crackly with some games like Doom 64 and Quake 64. There are currently some experiments being explored to deal with these issues.
64DD support right now is implemented completely differently in both cores.
64DD support (works through the subsystem menu)
Angrylion and GlideN64 are now inside the same build – you can switch inbetween them
HLE and LLE RSP support – with LLE your choices are between cxd4 [Interpreter] and Parallel RSP [Lightning/Lightrec dynarec]
Parallel RSP support for the first time in Mupen64 Plus Next
Available on Android with all of the above!
The latest HLE RSP improvements – HVQM support – Pokemon Puzzle League FMV support works now with HLE RDP renderers like GlideN64
Mitigation for SPECIAL_INT on downcounter flip – fixes freezes in Legend of Zelda: Majora’s Mask
Killer Instinct Gold now works with Angrylion + LLE RSP