Hacker vandalised our buildbot and Github organization

Libretro Team

Approximately 5 hours ago, we were the target of a premeditated cybercrime attack on our key infrastructure.

The hacker did the following damage:

  • He accessed our buildbot server and crippled the nightly/stable buildbot services, and the netplay lobby service. Right now, the Core Updater won’t work. The websites for these have also been rendered inaccessible for the moment
  • He gained access to our Libretro organization on Github impersonating a very trusted member of the team and force-pushed a blank initial commit to a fair percentage of our repositories, effectively wiping them. He managed to do damage to 3 out of 9 pages of repositories. RetroArch and everything preceding it on page 3 has been left intact before his access got curtailed.

We are still awaiting any sort of response or support from Github. We hope they will be able to help us restore some of these vandalised Github repos to their proper state, and also to help us narrow down the attacker’s identity.

We wanted to clear up some confusion that may have arisen in the wake of this news breaking:

  • No cores or RetroArch installations should be considered compromised. The attacker simply wiped our buildbot server clean, there is nothing being distributed that could be considered malicious to your system. Nothing has happened here and there is no need for any concern.
  • For the current time being, the Core Installer is non-functional until further notice. The same goes for ‘Update Assets’, ‘Update Overlays’, ‘Update Shaders’.

The IP he was using while doing this was ‘54.167.104.253’, which seems to lead back to AWS.

We’re still assessing the situation but moving forward, we think that it’s probably best not to go forward with the buildbot server that was compromised earlier today. We had some long-term migration plans for a move to a new server, but this was always pushed back because we felt that we weren’t ready migration-wise. It might indeed be the case this is the catalyst for just starting all from scratch with a new server instead of trying to migrate the old one over. This would mean that the more commonplace builds for Linux/Windows/Android would be immediately available, but all the specialized systems like consoles, old MSVC builds and whatnot would have to wait for later until we have adapted this properly to the new system.

Lack of automated backups

This brings us onto another key issue – the lack of backups. We last performed a backup of our buildbot server about a couple of months ago. The truth is that while we pay a hefty amount for the servers on a monthly basis already, there is simply not enough money to pile on automated backups as well. We could really use your support on Patreon to help lighten our financial burden here, especially since this now-pretty-much-mandatory server switch will likely cost us an insubstantial amount of money upfront while we keep the current server running for a month longer.

How will we restore things

So, how are we going to restore things? We hope that Github will be able to restore the affected repositories. If they are unable to do so, we could rely on the goodwill of users to source us with git repositories with the full history intact.

As for the buildbot? No idea to be quite frank. If we make the switch to the new server, you’ll get Android/Windows/Linux up and running early again but all other platforms will have to be added as we go along.

It’s a shame what is happening to the emulation and homebrew community. When it isn’t developers leaving for greener pastures deciding it’s no longer worth it, prestigious developers like byuu are being forced to early retirement because of unsavory online gang-stalkers. In our situation, we can’t rule out the possibility that some of these attacks come from some of the same usual suspects (it isn’t the first time we’ve seen them abuse AWS for some of these attacks, we encountered them a year ago earlier targeting our lobby services). Whatever their aim may be, while they will not deter our will to continue working on this project, they have definitely increased our maintenance and cost burden for the time being. And for this we ask for your understanding and support as we attempt to come up with a plan to address these problems moving forward. Supporting us through Patreon is a great way of helping out, especially if we can reach the $1300 goal which means we can spend a bit more each month to make sure our stuff is properly backed up.

As if the complications with Android’s new store policies that requires us to coordinate with new contributors to come up with a workable solution was not enough of a headache, this comes along. With your help and support, we will overcome this and come out stronger than before.

Regarding the Android / Core Installer situation

While we’re on this subject briefly, while it’s off-topic, we felt the need to address this real quick. We will likely be making a version of RetroArch Android that is neutered ONLY for Google Play. It will mean that the Core Installer will not be available for this, and cores will come packaged in additional APKs that can be installed. Apparently there is a 50-core extra APK limit on this until it starts requiring a version of Android over version 8.0. So while trying not to artificially bump the Android OS system requirements, we’re deciding on a 50 core-APK limit for now. Hopefully we can fit nearly most of the cores within such narrow constraints.

On our download site (and on F-Droid), we will have a RetroArch Android version that will work as before – with the Core Installer feature completely left intact. We feel this is a much superior version to what will be available on the Play Store, but unfortunately Google will force our hand here.

RetroArch 1.9.0 released!

Libretro Team


RetroArch 1.9.0 has just been released.

Grab it here.

A Libretro Cores Progress Report will follow later.

Remember that this project exists for the benefit of our users, and that we wouldn’t keep doing this were it not for spreading the love with our users. This project exists because of your support and belief in us to keep going doing great things. If you’d like to show your support, consider donating to us. Check here in order to learn more. In addition to being able to support us on Patreon, there is now also the option to sponsor us on Github Sponsors! You can also help us out by buying some of our merch on our Teespring store!

Highlights

Explore View for playlists

Probably the highlight of this release – there is a new ‘Explore’ view for all playlists.

The Explore view takes advantage of the Libretro databases’ metadata history of content. It allows you to search / find content based on criteria such as:

  • Amount of players
  • Developer
  • Publisher
  • System (game console/platform that the game released on)
  • Origin (country of origin that the game was developed in)
  • By Release Year
  • By Genre

The ‘Explore’ view only shows the content that has been added to your playlists. It will not show entries that haven’t yet been added to your collection.

The metadata is currently a bit on the incomplete side, but you can expect us to add more and more metadata to the Libretro database as we go along. This is only the beginning.

Usecases

There are tons of ways you can use the Explore view to find what you want. Here are some of them:

Granular filtering

Here is a good example of the kind of powerful context-sensitive filtering that is possible with the Explore view.

  • Go to Explore
  • Type in ‘super’, will list all entries in your collection that has ‘super’ in the name. 219 entries are shown.
  • We will now filter the entries by a specific developer to narrow down our search. We go to ‘Additional Filters’, and select a developer of choice. Now out of 219 entries, only 25 entries are still shown that matches this criteria (name has ‘super’ in the title, AND is from a specific developer)
  • Let’s add another filter to narrow down the search even more. We go to ‘Additional Filters’ again, and this time we select ‘By Release Year’, ‘1993’. There’s now only 6 entries shown that matches this criteria (name has ‘super’ in the title, AND is from a specific developer, AND was released in the year 1993).
  • Let’s add another filter. We go to ‘Additional Filters’, ‘Region’, ‘Europe’). Now only 3 entries are shown that matches this criteria (name has ‘super’ in the title, AND is from a specific developer, AND was released in the year 1993, AND was released in region ‘Europe’).

NOTE: It should be mentioned that in the future, if you want the metadata to be updated automatically in existing versions of RetroArch, you should go to ‘Online Updater’ and select ‘Update Databases’. After this, you might have to restart.

Enhanced playlist search functionality

Before, RetroArch’s inbuilt ‘search’ function was woefully inadequate:

  • The user presses RetroPad ‘X’ (or keyboard ‘/’, or Material UI’s search icon), and enters a search term
  • The navigation pointer jumps to the first match

    • That’s it. There is no way to continue searching from that point, or to do much of anything, really. It’s mostly a non-feature…

    The search functionality has now been enhanced as follows:

    • When viewing a playlist, the user presses RetroPad X (or /, etc.) as normal, and enters a search term
    • This becomes a filter – all matching entries will be displayed
    • The user can then perform another search to further refine the results. An arbitrary number of filters may be stacked in this fashion
    • Pressing ‘cancel’ clears the last entered filter

    Here’s an example of the search feature in action:

    Content loading animations

    A new “Load Content” Startup Notification option has been added under Settings > On-Screen Display > On-Screen Notifications. When enabled, a brief animation is shown whenever content is launched – it looks something like this –

    • The animation is disabled when running a core without content (there are some underlying technical issues that prevent this)
    • The animation is disabled when running content with ‘in-built’ cores (imageviewer, music/video player).
    • The animation works both for content launched via the menu and via the command line

    Easy dropdown lists for input remapping

    Before, when you wanted to remapp inputs via the Quick Menu (Quick Menu > Controls > Port N Controls), the user had to press left/right ad nauseam in order select an appropriate core input for each controller button. This is somewhat cumbersome, and highly awkward on touchscreen devices.

    In this new version we have added drop-down lists to the input remap entries. For example, when viewing this:

    …the user can now press OK (or keyboard enter, or tap/click the entry) to open a list of available inputs:

    This works for both controller and keyboard Device Types.

    In addition:

    • You can now use the RetroPad start button to reset (unbind) controller keyboard remaps (when Device Type is a keyboard type, obviously!)
    • Fixed a bug whereby pressing RetroPad select on certain entries would spawn a message box with no text – this would be invisible, and would therefore appear to ‘hang’ the menu.

    FFMpeg/Video Player Improvements

    • A new progress overlay bar has been added to the ffmpeg core (embedded in RetroArch for Windows/Linux). When you skip forwards or backwards via the directional keys or D-pad, you will see this interface appear for a brief period of time.
    • Lockups could occur when playing videos if a forwards seek operation would take the target playback position past the end of the file. We have added the following workaround: seek operations are limited to a point 1 second before the end of the file, and if the user attempts to seek past the end then playback of the file will restart from the beginning.
    • Solved several big memory leaks upon opening videos

    iOS/tvOS Metal Renderer

    RetroArch on iOS/tvOS now supports Apple’s Metal graphics API. Slang shader support is already implemented and all software rendered cores should work.

    Currently the iOS/tvOS build will default to OpenGL because of a few outstanding issues that still have to be resolved:

    • Slang shaders degrade performance noticeably on most cores
    • When audio is interrupted, it doesn’t resume with the Metal renderer (OpenGL seems ok)

    Other general menu improvements

    • The RGUI menu now shows boolean settings as a ‘toggle switch’ if you have the setting ‘Show Switch Icons’ enabled (Settings -> User Interface -> Appearance).
    • Previously, RetroArch would have the bad habit of resetting the selection cursor to the first entry in the menu after returning from almost every list of selectable values for a setting. For example, if you go to Settings -> Drivers -> Audio and change the audio driver (or press Back), the selection cursor will be reset to the first entry of the Drivers menu instead of the Audio item from where we were originally. This has been fixed.
    • People previously complained that it was possible to set drivers to ‘null’ that are necessary for RetroArch to work, such as ‘Menu’ and ‘Video’. It’s now no longer possible to set a driver to ‘null’ unless there is no driver available for this type.
    • MaterialUI – The Playlist screen now shows icons of the associated system.
    • The three separate Scan Directory/Scan File/Manual Scan entries are now moved into a submenu called ‘Import Content’. They are no longer shown in any ‘top level’ menu. This unclutters the Playlist screen.
    • You can now selectively hide/enable widget notifications of several types. For instance, autoconfig messages, load content animation popups, cheat code notifications, fastforward notifications, screenshot indications, and more can all be individually configured. You no longer have to disable widgets altogether if you don’t like any one of the widget UI elements, you can now just opt to disable the widget that you don’t like.
    • (Windows only) Screen resolution dropdown list improvements – it no longer includes multiple duplicate entries.

    File I/O/Memory improvements

    A significant amount of time has been spent reducing RetroArch’s memory footprint and reducing disk I/O overhead when doing menial operations such as loading a configuration file or a playlist inside RetroArch.

    Changelog

    There’s much more to this release than meets the eye. See the CHANGELOG below for a more detailed breakdown.

    1.9.0

    • 3DS: Fix sound crackling when paused
    • ANDROID/VIBRATION: Fixes “Vibrate on Key Press” having no effect on Android devices, which occurred because only the off time/strength was defined in what should have been a pair of off/on values
    • AUTOCONFIG: Ensure correct directory is used when saving autoconfig profiles
    • BLUETOOTH: Add a Bluetooth driver (Lakka-only for now)
    • CHEATS: Fix for wrong number of remaining cheat search matches on some machines
    • CHEEVOS: Option to play sound on achievement unlock.
    • CHEEVOS: Upgrade to rcheevos 9.1
    • CHEEVOS: Restore display of unlocked achievements across hardcore modes
    • CHEEVOS: Hash buffered data when available
    • CHEEVOS: Fix ‘Auto Save State freezes RetroArch while Cheevos is enabled’
    • CORE OPTIONS: Pressing OK (or clicking/tapping) on a ‘boolean toggle’ core option no longer opens a drop-down list. The value now toggles directly, just like boolean options everywhere else in the menu
    • CORE OPTIONS: Toggling an option that changes the number of core options being displayed (i.e. things like `Show Advanced Audio/Video Settings) no longer resets the navigation pointer to the start of the list
    • CORE OPTIONS: Before, RetroArch would identify core option values as being ‘boolean’ if they had labels matching the specific strings enabled or disabled. Most core devs would abide by this, but not always… As a result, we sometimes would end up with misidentified values, with all kinds of Enabled, Off, True, etc. strings littering the menu, in place of proper toggle switches. All boolean-type value labels are now detected, and replaced with standard ON/OFF strings.
    • CLI: A new command line option –load-menu-on-error has been added
    • CRT: On the fly CRT porch adjuments – these changes allow a user to adjust how the porch algorithm generates the 15khz/31khz output. Giving the ability to change over/under scan.
    • CONFIG FILE: Optimise parsing of configuration files
    • D3D9/D3D11: Fix core-initiated D3D9/D3D11 driver switches
    • DRIVERS: Implemented protection to avoid setting critical drivers to nothing thus preventing the user from locking him/herself out of the program
    • EMSCRIPTEN: Fix input code to ignore unknown keys
    • FFMPEG CORE: Prevent seeking past the end of files (hang fix)
    • FILE I/O: VFS and NBIO interfaces will now use 64-bit fseek/ftell where possible, should allow for reading/writing to files bigger than 2GB
    • INPUT MAPPING/REMAPPING: Add input remap drop-down lists
    • IOS: Fixed iOS 6 version
    • IOS: Hide the home indicator as it obscures the content too frequently
    • IOS/METAL: Metal video driver now works on RetroArch iOS
    • IOS/METAL: Support getting video metrics to support proper touchscreen interactions
    • LOCALIZATION: Updates for several languages (synchronized from Crowdin)
    • MEMORY/LINUX/ANDROID: Fix reporting of free memory
    • MEMORY/WINDOWS: Fix reporting of free memory
    • MENU: Enlarged INT/UINT selection limit from 999 to 9999
    • MENU: Fix cursor forced to first entry after displaying lists
    • MENU: Make Notification Font option visible when Graphics Widgets are enabled
    • MENU/RGUI: Add optional ‘toggle switch’ icons
    • MENU/WIDGETS: Add optional widget-based ‘load content’ launch feedback animation
    • MENU/WIDGETS: Make notification font size option visible when graphics widgets are enabled
    • ODROID GO ADVANCE: Video driver – fix race condition with RGUI callback
    • PLAYLISTS: Change playlists to use dynamic arrays. Instead of a fixed initial 12MB memory allocation (99999 * 128 byte (on 64bit arch)), use a dynamically growing array
    • PLAYLISTS: Playlist base content directory paths – portable playlists
    • PLAYLISTS/SEARCH: Enhanced playlist search functionality
    • PLAYLISTS/DATABASE: Add ‘Explore’ view
    • PLAYLISTS/DATABASE/EXPLORE: Show system icons in explore view
    • PS2: Improve FPS Limiter
    • RUNAHEAD: Prevent runahead from being disabled permanently when an error occurs
    • SCANNER: Add more region codes for GameCube/Wii game detection
    • SHADERS/SLANG: Increased Slang max Parameters, Textures & Passes
    • VIDEO FILTERS/BLARGG: Make Blargg_snes filter customizable
    • WINDOWS/RAWINPUT: Fix invalid calls to dinput_handle_message when input driver is not set to dinput
    • X11: Add lightgun support

    Other news

    We will follow this up with more news soon on all the recent core developments that have been going on. As usual with these blog posts, there’s a lot we don’t have time to touch on when it comes to bugfixes, improvements and additions to the Libretro/RetroArch project.

    New and improved versions of the Dolphin and Citra cores will be coming soon. The PPSSPP core is now being actively updated again and should be up-to-date with the Git upstream repository. In addition to this, there are several other big new things that will be discussed soon.

New PlayStation1 core SwanStation now available for RetroArch!

Libretro Team

SwanStation is a totally new PlayStation 1 (aka PSX) emulator focusing on playability, speed, and long-term maintainability. Accuracy is not the main focus of the emulator, but the goal is to be as accurate as possible while maintaining performance suitable for low-end devices. “Hack” options are discouraged, the default configuration should support all playable games with only some of the enhancements having compatibility issues. A “BIOS” ROM image is required to start the emulator and to play games. You can use an image from any hardware version or region, although mismatching game regions and BIOS regions may have compatibility issues. A ROM image is not provided with the emulator for legal reasons, you should dump this from your own console using Caetla or other means. SwanStation includes hardware rendering (OpenGL, Vulkan and D3D11), upscaling and 24-bit color and a 64-bit dynarec.

It is currently available on the Libretro buildbot for the following platforms:

  • Windows
  • Linux
  • Android (AArch64-only)

Features

  • Relatively high degree of compatibility
  • Has three hardware renderers: OpenGL, Vulkan, and Direct3D11
  • Allows you to internally upscale the resolution
  • Has a dynamic recompiler and cached interpreter CPU core
  • Ability to run PSX CDROM emulation on a separate thread, reducing frame time spikes

    • How to get it

    There are two ways to install and/or update the SwanStation core:

    a – If you have already installed the core before, you can go to Online Updater and select ‘Update Installed Cores’.

    b – If you haven’t installed the core yet, go to Online Updater, ‘Core Updater’, and select ‘Sony – PlayStation (SwanStation)’ from the list. It will then download and install this core.

    BIOS required

    SwanStation, like Beetle PSX, requires a real BIOS in order to work. There is no HLE BIOS like PCSX ReARMed.

    A “BIOS” ROM image is required to start the emulator and to play games. You can use an image from any hardware version or region, although mismatching game regions and BIOS regions may have compatibility issues. A ROM image is not provided with the emulator for legal reasons, you should dump this from your own console using Caetla or other means.

    Recognized BIOS images:

    • scph5500.bin
    • scph5501.bin
    • scph5502.bin

    Benchmarks

    System specs: CPU – Intel Core i7 7700k | GPU – Geforce RTX 2080 Ti (11GB VRAM, 2018) | 16GB RAM

    We’ve performed some basic performance tests between SwanStation and Beetle PSX HW. We are using the same baseline resolution (1x) for both cores, and we try to make the test as fair as possible by disabling features such as PGXP and texture filtering for Beetle PSX HW (both features which SwanStation lacks).

    SwanStation

    Title Direct3D11 Vulkan OpenGL
    Tekken 3 396fps 414fps 335fps
    Alien Trilogy 538fps 552fps 499fps

    Beetle PSX HW

    NOTE: Beetle PSX HW does not have a Direct3D 11 renderer

    Title Vulkan OpenGL
    Tekken 3 326fps 229fps
    Alien Trilogy 480fps 473fps

    As you can see, on average performance is overwhelmingly in SwanStation’s favor. It does have to be said that Beetle PSX HW right now has some unique features that SwanStation lacks, such as PGXP and texture replacement.

    Conclusion

    You should definitely give SwanStation a go if you want a high performance PlayStation1 emulator. If you find Beetle PSX HW to be running too slowly for you on your system, you should check if SwanStation is faster instead.

(Coming Soon) RetroArch 1.9.0 – Widget-based ‘load content’ animation

Libretro Team

A new “Load Content” Startup Notification option has been added under Settings > On-Screen Display > On-Screen Notifications. When enabled, a brief animation is shown whenever content is launched – it looks something like this –

Notes:

  • The animation is disabled when running a core without content (there are some underlying technical issues that prevent this)
  • The animation is disabled when running content with ‘in-built’ cores (imageviewer, music/video player).
  • The animation works both for content launched via the menu and via the command line

Mupen64Plus-Next – v2.1

m4xw

The long-anticipated big update to Mupen64Plus-Next has finally arrived!

Important Information and notes

Beforehand, be warned that the core name changed…
As you probably know, up until now, the flavour (if it’s a GLES/GL build) was appended to the Core Name, this caused the frontend to categorize them with the appendix. Now with Vulkan support added, this would break remap/game specific core options/etc anyway, so I decided to just kill it and append it to the version (there was never a good reason why I added it to the name to begin with…).
Now a new folder named `Mupen64Plus-Next` will be created inside your config folder on first start.
You can move and rename your existing core config override, core options and shader presets there, named accordingly (Mupen64Plus-Next.cfg/opt/slangp…).

RetroArch Nintendo Switch Notes

With the development of the threaded renderer support we noticed a few Issues in our platform specific Audio drivers, especially audren_thread, that will cause some cores, most often multithreaded cores, to randomly freeze. We have a fix for this in the pipeline, while also nearly halving our current audio latency.
Due to time concerns tho, I didn’t get to push the fix yet and it needs more testing.
So, for now, I recommend switching to the `switch_thread` audio driver until the issues are fixed.
Another core where it’s likely to happen is PPSSPP, so if you encounter random freezes, give it a try, the only thing you will lose is audio in in-game recordings.

GlideN64

This new version of Mupen64Plus-Next should be up-to-date with the most recent versions of GLideN64.
Here are some highlights, which are now available in the libretro-core as well!

Threaded Renderer

There’s now a ‘threaded rendering’ option for the libretro core. Enabling this can significantly increase performance, at the expense of slightly more input latency.
It has been available upstream for a while, but the implementation doesn’t play well with how a libretro core works.
I started work on it sometime mid last-year and after more than a dozen iterations and months of testing, it’s now ready for production.
An enormous shoutout to fzurita, who originally came up with the implementation!

How to use it


To use it, go to Quick Menu, Options. Make sure you have set ‘RDP Plugin’ to ‘GLideN64’ (the setting will not do anything with Angrylion and/or ParaLLEl RDP). Then turn ‘Threaded Rendering’ either on or off, and then restart the core (Close Content, and loading content again with the core).
Please note, I am aware that switching between fullscreen and windowed currently crashes when a game is running with the threaded renderer (same applies to changing Video Threaded in RetroArch), a fix is on my todo.

Benchmarks

Tests were performed on a Core i7 7700k desktop PC with a Geforce RTX 2080 Ti.

Game Non-Threaded Threaded Resolution
Super Mario 64 719 VI/s ~1000 VI/s 2x Native Resolution
Super Mario 64 701 VI/s ~1000 VI/s 4x Native Resolution
Super Mario 64 742 VI/s 780 VI/s 3840 x 2880

NOTE: These tests were performed with hyper threading enabled and CPU throttling, so take these figures with a grain of salt. The main important thing to take away from this is that VI/s is nearly 300 units of measurement faster at 2x to 4x native resolution compared to non-threaded rendering in this test.

This feature will significantly help platforms like Nintendo Switch and Raspberry Pi.

Dithering

In the past, HLE renderers have not really attempted to implement dithering (of course, with LLE RDP renderers you get it for free). An N64 game is typically rendered using a 16bit color buffer, and dithering is then used to reduce color banding and create the illusion of a higher color depth. GLideN64 in the past has always used 32bit rendering.

There are several new core options available:

  • Dithering Pattern
  • Dithering Quantization
  • RDRAM Image Dithering Mode

If you use native N64 resolution, you also may enable a dithering pattern to get a more authentic look, but even if you like to play in HD, this is something worth trying out!

ParaLLEl RDP

By now you’ve heard all about the revolutionary Vulkan-powered ParaLLEl RDP renderer, which debuted first in ParaLLEl N64. It is now included for the first time in Mupen64Plus-Next.

All the same features are available and more –

  • Compatibility on Android with ParaLLEl RDP should be much higher now as a result of a much more up-to-date mupen64plus-core. Games like Paper Mario, GoldenEye 007 and others would previously just crash on Android with ParaLLEl RDP+RSP.
  • Performance should be roughly ~5-10% faster on average than ParaLLEl N64. Sometimes a bit more.
  • Some compatibility issues that happened even on PC x86/x64 with ParaLLEl N64 are not an issue with Mupen64Plus-Next (such as Perfect Dark crashing at startup, Pokemon Snap graphics glitches, Mario no Photopi not working, Conker’s Bad Fur Day).

Over time we will probably repurpose ParaLLel N64 and let Mupen64Plus-Next take center stage.

Improved Core Options

Sub-labels descriptions got added to the core options. I hope this will make them a bit less confusing.
Please note that it’s currently not possible to hide the options on the fly so depending on the build configuration this might get a bit cluttered.
I am looking for solutions, but this should be a great improvement over the last versions nontheless!

Bugfixes and changes

– Android: Fixed garbage on the framebuffer with GLES3 (where the overscan would be)
– Android: Switched to “on Vertical Interrupt buffer swap mode” (might take slightly more perf) since the touch overlay was pretty much unusuable without it
– Updated Parallel-RSP
^- – Fix some stability issues in parallel-rsp on 64-bit
– Added Native Resfactor core option (set to disabled / 0 to use custom resolutions as you are used to)
^- Note: With Native Resfactor the resolution option will act as viewport size!
– Added Copy Aux to RDRAM core option
– Added a script to regenerate the INI Headers, updated to the latest variants
^- Note: It seems I still had cheats for OoT subscreen fix and DK64 bone displacement from when I first wrote the core, these caused some issues after it was fixed in the core, so I got rid of them for good, it was a oversight.
– Remove CountPerOp=1 for Quake 2 and Goldfinger
^- Note: After speaking with some upstream folks, nobody knows why it was even forced to 1, it caused crippeling performance on Android and Switch and after hours of testing no gamebreaking Issue was found, in the future I might work on getting rid of Count-Per-Op for good, it’s a nasty approximation.
– Allow higher Count-Per-Op
– Nintendo Switch: Lowered Firmware version requirements
– Added support for linking against system libaries
– Fixed LLE Fallback falsely being treated as supported, fixes F-Zero X Expansion HLE
– Exposed Hybrid filtering

These fixes are incorporated in both ParaLlEl N64 and Mupen64Plus-Next:

  • Vigilante 8’s character portraits are no longer wrongly coloured.
  • Mario Tennis’ intro screen no longer has tons of graphics bugs

Dynarec Issues

Over the last months, testers repeatedly encountered freezes in Ocarina of Time. I and Gillou spent hours on investigating the Issue and tracked it to the dynarec.
Sadly even after syncing core instances and comparing each recompiled block with the working MSVC builds led nowhere yet (tho we found a few other issues in code invalidation, which might’ve been an issue or not as well as borked caller saved regs..)
These fixes are still in the development stage and thus not included here. However I brought back the good ol’ TLB Invalidation hack as core option.
Setting it to the “Ignore TLB Exceptions if not using TLB“ option will allow the game to continue so you can save it and restart (For this Issue you actually need to Close Content and start it again, a soft reset wont be enough). You will notice it happens when you suddenly see Epona carrots. Of course this is not a fix, but a side-effect is also that a bunch of broken romhacks work and it’s also useful for the upcoming GDB Server implementation, so I figured I will add it anyway.
Take note that this is confirmed as a mupen64plus-core upstream issue and that this Issue does not arise with Cached or Pure Interpreter!

Differences between Mupen64Plus-Next and ParaLLEl N64

  • ParaLLEl N64 has the following RDP plugins: Glide64, GLN64, Rice, Angrylion, ParaLLEl RDP. Glide64, GLN64, and Rice are aimed more at the lowend of graphics cards.
  • Mupen64Plus-Next has the following RDP plugins: GlideN64, Angrylion, ParaLLEl RDP.
    GLideN64 should be the best-in class HLE RDP renderer, but might have higher performance and GL requirements than the lower-end Gliden64/GLN64/Rice from ParaLLEl N64.
  • Both ParaLLEl N64 and Mupen64Plus-Next have the same RSP plugins (HLE, cxd4 LLE interpreter, and ParaLLEl RSP)
  • ParaLLEl N64 uses the Hacktarux dynarec for x86 32bit/64bit, and new_dynarec for ARM. Mupen64Plus-Next uses new_dynarecs for both x86 and ARM architectures, and tends to be a bit faster as a result.
  • ParaLLEl N64 has some built-in game specific alternate control schemes that you can switch on/off with the Select button. Mupen64Plus-Next does not have this yet.

Conclusion

Moving forward, we recommend you use Mupen64Plus-Next if you want to use LLE N64 (ParaLLEl RDP/RSP) with the highest compatibility and best performance.
Also, GLideN64 (provided your graphics card meets the OpenGL requirements) will work better than ParaLLEl N64’s equivalents.
Furthermore, Mupen64Plus-Next has a up to date version of mupen64plus-core, so it tends to have less game compatibility issues and the sound is better in games like Body Harvest.

ParaLLEl N64 might get repurposed towards the lower end as a result.

As a final note I want to give my thanks to dmrlawson for giving me a helping hand, fzurita for being very helpful, gonetz and his contributors for doing a awesome job with GLideN64 and Gillou68310 for all the hours he put in helping me investigate the dynarec issues (also thanks to Thom Rainier for never getting tired of OoT testing) as well as themaister for his work on Parallel RSP/RDP and the Vulkan implementation in Mupen64Plus-Next!

– m4xw