Site icon Libretro

RetroArch 1.9.13 release!

Libretro Team


RetroArch 1.9.13 has just been released.

Grab it here.

If you’d like to learn more about upcoming releases, please consult our roadmap here.

UPDATE (11/11/2021): A ninjafix release has been pushed. See our blog post here.

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 to 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

Project IO continues

Project IO continues as we try to abstract all file I/O in libretro cores and RetroArch to meet the Google Play Store’s new policies. Android 11/12 requires the use of the Storage Access Framework for file I/O, as libc stdio access is being restricted as much as possible.

One of the beneficial side effects of Project IO is that in going over each core, we find out all sorts of long standing issues along the way, and we try to improve the cores along the way. So it serves as a much needed quality control check as well.

No RetroArch 1.9.13 for Google Play Store for now

Do not expect frequent updates to the Google Play Store version until further notice for now. This is because of the new Play Store requirements (as explained bove in the Project IO section). Basically what it comes down to is that despite our hardest work and effort, we have missed the deadline, and so any new APK that is pushed to Google Play is likely to be rejected until the minimum SDK Level (30) and SAF is being used. We are trying to work as fast as we can to get to that stage. A realistic target is possibly two weeks from now, but we’d rather not make promises and see how far we can get by that point. In the meantime, downloading it from our site (the non-Google Play Store version), the Amazon App Store, or Huawei AppGallery or all valid alternatives that should receive an update.

Automatic Frame Delay

After introducing unique innovations like runahead in the past, RetroArch continues to innovate once more and remains at the forefront of latency reduction: introducing automatic frame delay! Read all about it in our separate article here.

The aim of this option is to lessen the burden of creating core-specific and also game-specific overrides for Frame Delay, and instead go for “set it and forget it”. With 0 value, the starting point will be half frame time.

It is fairly simple and it is based on frame time averaging with a few different thresholds which filter out false positives and provide quick stabilization with bigger steps depending on the need.

It only goes down, it is temporary, and it will reset on core unload and on SET_SYSTEM_AV_INFO. The necessary values are shown in video statistics and all actions are logged in info level.

Some notes by the author:
* For Windows users – use the XAudio driver for now, WASAPI and DirectSound does not lead to reliable results with Auto Frame Delay for now.
* Early polling could behave better with frame delay. Try setting Polling Behavior from ‘Late’ to ‘Early’ and see if you prefer it that way. Note that that polling setting needs (restart) info with it, since it does not properly refresh in realtime. If it is anything but Late at startup, putting it to Late will be always one frame behind.

‘All Users Control The Menu’ option is back

A much requested feature by WiiU users is back again! This allows all the connected gamepad devices to control the menu simultaneously. It is enabled by default for WiiU and disabled for all other devices.

NOTE: Only player 1 can toggle the menu. This is a limitation of the current input system. But any set Menu Toggle Controller Combo will work fine for all users, so it is probably acceptable for now.

Initialise ‘Explore’ menu on a background thread

Before, accessing the Explore menu would freeze the user interface for up to several seconds (depending on host hardware performance) while playlists and databases are scanned.

1.9.13 just pushes the Explore menu initialisation onto a background thread, so the UI remains responsive while the various processing occurs. (Note that the host platform must of course have threading support – if not, Explore menu initialisation will remain on the main thread)

RetroAchievements – Replace co-routines with tasks

Not important much to endusers but still worthy of a mention to people familiar with the codebase. Replaces the single long-running load task for RetroAchievements with several smaller tasks (which are threaded).

This also eliminates the coroutine code as that was only being used to yield the long-running load task – there wasn’t actually anything else to be coroutine with.

Subtasks (i.e. 1a/1b) are queued together and can be executed in parallel. RetroArch’s task system only has one task thread, but the HTTP task does sort of interleave the server requests so they are more-or-less executed at the same time.

Core improvements

As mentioned before, as part of Project IO, we are going over every core and performing some basic quality control checks. This already resulted in numerous Quality of Life enhancements to cores. Not all of the improvements listed below can be attributed to Project IO, but it’s fair to estimate over 90% of them are.

mGBA

Description: mGBA is a Game Boy Advance emulator

Fixed audio pacing – no more crackles and bad frame pacing

GBA content ran with the mGBA core was sometimes subject to crackling audio and intermittent bad frame pacing (particularly when using low frontend audio latency settings).

It turns out that the core was handling audio suboptimally in the libretro layer. At the set audio sample rate, the frontend expects between 548 and 549 audio samples per frame – but the AVStream audio callback reads and sends exactly 512 samples. This means that the audio callback becomes desynchronised with retro_run() – sometimes 512 samples will get sent to the frontend for the current frame, sometimes 1024 as the core either falls behind or overcompensates. As a result, when the frontend tries to synchronise on audio, jitter can occur – and if the frontend audio buffer is small (when using low latency values), it can sometimes run dry or reach capacity, causing crackling.

Our changes modifies audio handling in the libretro layer such that the correct expected number of samples is sent to the frontend in proper synchronisation with retro_run(). With this change we no longer experience cracking audio in GBA games, and the 240p test suit demonstrates smooth scrolling.

Note that the changes here only affect GBA content. GB/GBC emulation produces irregular audio sample pacing that is not consistent with the set sample rate, and so I am unsure how best to handle it. The existing AVStream audio callback and fixed buffer size of 512 is therefore maintained for GB/GBC content (since it already seems to produce acceptable results in most cases)

Miscellaneous

While working on the above, we noticed that the audio produced by this core is somewhat ‘harsh’ sounding. We have added an optional (fast) low pass audio filter (with associated strength setting), which softens the generated output to a more comfortable level.

Since we had to modify the core options, we also took this opportunity to update the options to v2 format, with category support.

LRMAME

Description: This is the mainline MAME core based on current sourcecode

Update to 0.237

We have updated the LRMAME core to version 0.237.

1 frame of input lag removed from core

In addition, we are happy to report that a longstanding issue with this core has been resolved. There was previously 1 additional frame of input latency in this core. This has thankfully been shaved off now.

gpSP

Description: This is a Game Boy Advance emulator

x86 32bit/64bit dynamic recompilers

gpSP now has a dynamic recompiler for x86 x64 architecture processors! Now both 32bit and 64bit CPUs have a working dynamic recompiler.

This is now hands down the fastest Game Boy Advance emulator in existence on x86 x64 platforms, outside or inside of libretro/RetroArch. We have benchmarked it ourselves – on an i9 10900KF, we get a regular reading of 2270/2280 fps in fastforward mode with Super Mario Advance 2. This makes it even faster than QuickNES, an 8bit Nintendo Entertainment System emulator. It is a little bit slower than Gambatte (still one of the kings in terms of performant cores) at ~2300fps, but it bears reminding that Gambatte is only targeting 8bit Game Boy consoles as opposed to the 32bit Game Boy Advance.

With Advance Wars, we can get even crazier readings like anywhere from ~4000 to ~5000fps in windowed mode.

Suffice to say, this kind of performance before was simply unheard of for a GBA emulator. Suffice to say, if you were still hurting for performance with a Game Boy Advance emulator before (on whatever ghetto rig you have repurposed), give this a try!

prBoom

Description: This is a Doom/Doom 2/Ultimate Doom/Final Doom game engine core.

In addition to this core now using the VFS for file I/O, we also improved the following listed below.

Fix core options version detection

On recent versions of RetroArch the core options are currently falling back to v0 format (missing sublabels) due to a trivial ‘supported version check’ error in libretro_core_options.h. We fixed the issue.

Fix memory leaks + prevent potential segfault when saving/loading games

We tried fixing every memory leak that we could find in the core.

It also works around a nasty bug in the code for saving/loading games, where an array index can easily go out of bounds.

Note that we had to stub a certain deinit out for the Windows build, the z_zone memory management seems to be pretty hairy on Windows and we unfortunately haven’t found a clean way to fix that yet. However, we don’t expect this to be a big issue on Windows regardless since it’s a dynamically linked core that gets deallocated after unloading anyway. Most of the leaks on the statically linked consoles should be all gone, and that is what ultimately counts at the end of the day.

TyrQuake

Description: This is a Quake 1 game engine core.

In addition to this core now using the VFS for file I/O, we also improved the following listed below.

Fix startup crash on x64 systems

The core would segfault under some circumstances when running the shareware version of Quake on Windows.

It turns out that the code makes a number of assumptions about the width of certain data types when casting pointers, which are not true on a number of platforms. On 64bit Windows this can cause pointer addresses to be determined incorrectly – leading to chaos.

We fixed the issue by using standard fixed-width types for the affected pointer casts. It also cleans up some other related compiler warnings.

Clean up file path handling + fix segfault when loading content from ‘non-standard’ directories

Before, the core would segfault on certain platforms when loading PAK files from non-standard directories (anything other than id1, quoth, hipnotic, rogue) due to illegal usage of strncpy(). This can be observed most easily by attempting to run the shareware version of Quake from RetroArch’s online content downloader.

We fixed this issue, and also cleaned up all file path handling in libretro.c (using libretro-common routines). A number of libretro-common files have also been updated to the latest version.

Fixed memory leaks

We fixed three sources of memory leaks in the core:

* A relatively minor one related to loading PAK files (the file handle was always left open)
* Two serious ones in the sprite handling code, which may potentially trigger multiple times per frame (and which were likely to cause crashes on RAM limited platforms…)

Miscellaneous core improvements

We have been spending time improving fMSX (MSX emulator core), PX68K (X68K emulator core), and Frodo (Commodore 64 emulator core), but are not quite done yet. We will probably spend some time detailing the changes to these cores by the time the next release comes along (two weeks from now).

For WiiU users: Frodo has been added to the WiiU build.

Changelog

1.9.13

Exit mobile version