RetroArch 1.9.11 released!

Libretro Team


RetroArch 1.9.11 has just been released.

Grab it here.

If you’d like to learn more about upcoming releases, please consult our roadmap here. The next version of Lakka (with an updated RetroArch 1.9.11 version) is scheduled to be released very soon!

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

Steam information

In case you have missed our previous announcement, take the time to read this article.

TLDR – we switched over to the Soldier runtime for Steam Linux builds which should increase compatibility with various Linux distributions.

As for how things are progressing on Steam, we are currently waiting on new depots before we can add the next batch of core DLCs. Stay tuned!

Miyoo – Pocket Go, PowKiddy Q90-V90 and New BittBoy now supported

We now have an official build (dubbed Miyoo) for the cheap impulse purchase handheld consoles listed below:

  • Pocket Go
  • PowKiddy Q90-V90
  • New Bittboy

These are cheap, low-spec ARM handheld consoles powered by OpenDingux that can be bought for $50 or less. Currently we have only a few cores available in this official version, but expect us to expand the cores list significantly soon. And as a result of the initiative Project IO, expect cores to become more suitable for low-end devices like this and its ilk as well. We care very much about continuously improving our cores so that they become more suitable for the low-end spectrum of devices. And the nice thing about that is that this ends up benefiting the high-end devices as well.

NOTE: We are not affiliated or have any association with the companies behind these devices.

HID subsystem unification – WiiU Gamecube adapter now works on Mac

Previously, the WiiU and Mac ports used a completely different HID subsystem. This has now been unified, so that both WiiU and Mac use the same underlying system.

Thanks to this, Mac RetroArch gets some nice additions, such as Gamecube WiiU adapter support. It should also work on WiiU RetroArch itself. Currently it only works with the first gamepad in controller port 1.

Further, author gblues remarks: “I don’t have any of the devices in order to confirm, but I think the other HID devices (SNESUSB, HID-capable PS4 controllers, etc.) should start working.”.

NOTE: While the WiiU side has been tested, there might still be things that don’t work like they did before. Hopefully whatever issues are found can be patched up in subsequent versions.

RetroArch PS2 – Resolution switching support

1.9.11 provides the ability to change the resolution for RetroArch PS2. The approach used is based on how it was implemented in the past for the Wii.

We finally have 240p support for RetroArch PS2! 240p probably is recommended to play on CRT. However, 480p is recommended for HDTV (component cable is needed however for progressive scan).

Features:

  • Be able to change resolution on PS2 (it’s possible to use 240p and 288p modes now)
  • You can center the video content on the CRT screen (new settings option for Video Offset X/Y)

Instructions

You need an RGB SCART cable for 240p/288p video modes.
You need an AV component cable for 480p/576p. Be aware that 576p is only available for the latest PS2 console versions (SCPH-750XX and higher).

Project IO – Wrapping file I/O

We have put in an extraordinary amount of work into our core library and trying to update them one by one so that they no longer use direct file I/O where possible. We are of course nowhere near done with this yet, but along the way it has given us the opportunity to do quality control checks on cores, and fix issues where necessary. Think of it as a glorified quality control check if you will.

Here are the cores we managed to cover thus far:

As you can see considering this list and how many cores Libretro/RetroArch has in total, We are nowhere near done yet of course.

Why are we doing this? Both the UWP/Xbox port and the Android port require it. Direct file I/O is more and more beginning to get sidelined on these platforms due to ‘security concerns’. In order to achieve this, each core that needs to use disk I/O will need to go through libretro’s VFS layer (Virtual File System).

Along the way, we have investigated if certain cores are not better off doing away with file I/O altogether, and if the input file can just be passed to the core as a memory buffer. For some cores, we have done just that. Other issues we found in other cores were memory leaks (sometimes related to disk I/O), and we took the time to plug those leaks.

Other design considerations along the way involve a core writing to multiple config files – for the cores we maintain ourselves, we try to avoid this. Instead, settings should just be part of the core options instead. So to that end, we will be modifying cores like Prboom (the Doom engine core) so that it no longer writes an auxiliary prboom.cfg file inside the saves directory, but instead writes those values back to the core options. This is going to be a bit tricky since the Prboom core allows you to access and change the settings in-game with its built-in Setup menu. In order to accomplish being able to change core options on the fly programmatically, jdgleaver graciously implemented an extension to the libretro API that allows us to do this.

It might be worth mentioning what kind of approach we take to file I/O in a core.

  • If a core’s input files (read: ROM for an emulator core) can fit reasonably into memory without exhausting main RAM, we are always in favor of setting ‘need_fullpath = false’ for a core. This way, the frontend can pass the content to the core as a memory buffer. Advantages of this? soft-patching support covered by the frontend. Other advantages are not limited to but include: less memory copies (see the next point), better performance due to no disk I/O after initial load, etc.
  • In case the memory buffer can be flagged as ‘persistent’, it can even remove the need for additional memory buffer copies in the core. Meaning less RAM being used. We have found that we unfortunately cannot do this for every core, as in some cases, a core might still be writing to the memory buffer after initial setup/reading of the input file (think of memory patching). In such cases, the memory buffer is not really persistent, so the core itself still has to maintain its own memory buffer copy.
  • If we can avoid disk I/O in a core, we try to do it. There are multiple reasons for this. One is performance : disk I/O can be by far one of the biggest bottlenecks in your system, and its performance can be entirely variable and random depending on what storage device you’re using. The other one is because from the perspective of a core, we don’t want users to have to place specific config files in specific places in order to change settings. Ideally, as many settings as possible are just implemented through core options so that the user always knows that he only needs to edit this one file instead of several stray files. This is obviously the goal, and it might still be the exception to the rule, but we’ll keep going through cores and seeing what the status of it is in certain cores, and make suitable adjustments.
  • Disk I/O happening during runtime is rarely a good idea from a performance perspective. You run the risk of introducing micro stutters and/or other undesirable issues. We therefore try in libretro cores as much as possible to avoid direct file writing to log files or any other examples of direct disk I/O for the duration of a core. For instance – this is the reason why the frontend is in control of SRAM saving/loading in libretro since its inception. Games like Shiren The Wanderer on SNES would write to SRAM as a ‘scratchpad’ every single time you move or press a button in the game. If you were to write to disk for every single step you take, not only do you incur wear and tear on storage devices with a limited amount of max read/writes like SSDs, but you’re also creating performance issues due to disk I/O. Hence our reason for always being mindful of what gets written to disk or read from disk in general.
  • Another issue relating to the location of files on disk – for the cores that we self-maintain, we like to be able to not demand of the user that they need to place required asset files in specific locations, like the system dir. Of course this is unavoidable for things like BIOS files, but for certain assets that the emulator itself provides, an effort should be made to try to embed these resources into the core so that it’s not the user’s problem to have to place all these cores somewhere. This increases core portability and makes it so the only thing a user has to care about is just moving a core over to the core directory, maybe supplying a BIOS in the system dir, and he is done from that point on and off to the races.

Expect us to be going over more and more of the cores. The Google Play Store (and Android itself) is pretty much going full-force in sandboxing disk I/O, and Xbox UWP has its own issues when it comes to direct file I/O (apparently it copies files that use direct disk I/O over to a temporary dir first before touching them or reading them, which can get clogged up fast). So it’s important that a lot of the cores have been covered by the time 1.9.12 rolls out.

Project IO – Improvements to cores

Here is a small example of the kinds of improvements that have been made to various cores as a result of Project IO that users will be able to appreciate and notice:

  • FCEUmm – Fixed a bug where it would cause the core to fallback to core options with no sublabels.
  • Game Music Emu/GME – Content loading has been fixed. Also fixed – a segfault when an invalid content path is provided, a segfault when loading content successively. And a few of the more obvious memory leaks has been fixed (there remain many more in this core though)
  • Gambatte – Now has toggling between palettes by pressing the L/R buttons.
  • Handy – the BIOS has been made optional, previously it was required but was not actually used. EEPROM save files are now generated in the frontend save directory, instead of the content directory. All logging is now performed via the frontend logging callback, and audio processing to libretro has been made more efficient.
  • PocketCDG – A file handle leak has been fixed.
  • RACE – The loading of real BIOS files has been disabled. This never actually worked before (the bios path was not configured corectly), and the use of a real BIOS with RACE is strongly discouraged – the relevant code path is not properly tested, and there are known issues with games.
    A workaround for a rare segfault (buffer overflow) has been added (the underlying cause of the overflow remains unknown, but this at least prevents the core from crashing and seems to have no adverse side effects)
  • QuickNES – Now has toggling between palettes by pressing the L/R buttons.

Direct3D9 driver works again!

RetroArch’s Direct3D9 driver finally works again after a long period of downtime. This is important because of our commitment to old hardware. You will find that many GPUs on Windows might have either spotty OpenGL drivers or they have no OpenGL support beyond OpenGL 1.0/1.1 (hopelessly archaic, a spec dating back to the late ’90s). Your previous options when faced with a graphics card that either doesn’t support OpenGL 2.0 or Direct 3D 10/11 would have been SDL or OpenGL 1.0. Now there is a viable third option – Direct3D 9.

Just to temper expectations:

  • Right now there is no shader support yet. Hopefully later on we can get the Cg and HLSL backends to work.
  • Only RGUI is fully supported as a menu driver right now. The graphics are still not displaying properly when using MaterialUI, Ozone or XMB. So only use RGUI for now with the Direct3D9 driver.
  • It relies right now on Direct3DX for font rendering, which is deprecated. Hopefully we can get rid of this dependency later on.

Of course, if your GPU is more than capable, we’d highly encourage you instead to use Direct3D 10/11/12 drivers in RetroArch. Use Direct3D9 only as a last resort when your GPU absolutely does not support Direct3D 10 and/or later.

NOTE: It will be very unlikely Direct3D9 will get Slang shader support. Most likely it will be limited to the old-style Cg shader format (since HLSL on Direct3D9 is nearly equivalent to Cg). It is our hope that we will be able to reuse the same Cg shaders for both the Cg and HLSL backends, and that people will be able to switch inbetween the two backends. For now, the HLSL and Cg backends are non-functional until further notice.

It is worth mentioning that RetroArch supports a wide variety of Direct3D versions. There is a working driver for Direct3D 8, Direct3D 9, Direct3D 10, Direct3D 11, and Direct3D 12. We do this to cast a large wide net so that we can support as many older GPUs as possible without having to resort to non-hardware accelerated rendering. Direct3D 8 driver will be unlikely to ever get shader support because pixel shading was very much in its infancy back then. Direct3D 9 will likely get Cg/HLSL9 shader support. Direct 3D 10/11/12 meanwhile fully support the new modern slang shader format that other video drivers also use (such as OpenGL 3/Core, Vulkan, and Metal).

Changelog

1.9.11

  • ANDROID: New launcher logo – will fill the corners on the homescreen
  • D3D9: Driver works again (RGUI only and software rendered cores work, no shader support yet)
  • HID/MAC: WiiU GameCube Adapter now works
  • HID/WIIU: WiiU and general HID subsystem unified/merged
  • INPUT: Refactor menu toggle combo button logic to allow quit combo button
  • INPUT/UDEV: Add mouse relative check and set appropriately to fix issue
  • LIBNX/SWITCH: Splitted Joycon button mapping
  • LIBRETRO: Add environment callback to enable cores to notify the frontend that a core otion value has changed
  • MIYOO: Add initial port
  • OPENDINGUX/RG350: Enable tinyalsa for the RG350
  • PS2: Add ‘Change Resolution’ option
  • PS2: Add option to change video windows offsets
  • STEAM/LINUX: Move to new ‘soldier’ runtime
  • WAYLAND: Remove xdg-shell-v6 protocol
  • WINDOWS: Fix non-ASCII text display in window title
  • WINDOWS 11: Shows Windows 11 version name now (Information -> System Information)
  • UWP: Further improvements to WinRT VFS layer

RetroArch 1.9.10 released!

Libretro Team


RetroArch 1.9.10 has just been released.

Grab it here.

If you’d like to learn more about upcoming releases, please consult our roadmap here. The next version of Lakka (with an updated RetroArch 1.9.10 version) is scheduled to be released very soon!

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

RetroArch is now finally on Steam!

On September 14, 2021, RetroArch finally appeared on Steam (available here). It is available right now for both Linux (SteamOS) and Windows. See our initial release article here. Since then, we have already had over 100K+ downloads on Steam and over one million visits. Thanks to you all! We aim to make RetroArch the very best it can be.

What you need to know:

  • New cores are coming as DLC additions.
  • There is no macOS version available on Steam yet (but we’d like to!)
  • Remote Play is supported. We make no guarantees as to how well this will work.
  • Steam Cloud sync should be supported for save files.
  • There is work underway on automation – the idea is that both cores and RetroArch on Steam would be updated automatically.

Lastly, we hope that new users can be understanding of the fact that RetroArch’s UI might have a bit of an initial learning curve. We are a small team, and we definitely intend to simplify the UI at least for beginners in the coming months, but we are simply not ready yet. So we hope people are understanding of this and appreciate the swiss knife flexibility and power of RetroArch in the meantime instead of focusing on the overall complexities or whatnot of the UI/UX.

The Steam version should be updated to 1.9.10 soon.

High Dynamic Range fixes for D3D11/D3D12!

  • Fixed contrast to be more correct – now scales from 0-10 linearly and behaves more the way you’d expect it to – changed name to ditch legacy settings users may have
  • D3D11/HDR: Fixed D3D11’s blend, rasterizer and topology states not being set to the sames when using HDR and leaving the menu – caused issues with PCSX2’s Shadow of the Colossus
  • Added ability to skip inverse tonemapper to the shader via the constant buffer using ‘inverse_tonemap’ – set to 0.0f to skip
  • Fixed potential bug when swapping between HDR and SDR and the bit depth not being set correctly

Filters

1.9.10 adds a new Picoscale_256x-320×240 video filter. This uses a number of high quality, high performance algorithms developed by irixxxx for Picodrive standalone to upscale 256×224, 256×239 and 256×240 content to 320×240 (content of any other resolution is passed through unchanged).

Much like the existing Upscale_256x-320×240 filter, this is intended for use on platforms/devices with native 320×240 resolution support, where it greatly reduces aliasing while producing a significantly sharper image than conventional (hardware) bilinear filtering.

Three filter variants are provided:

Picoscale_snn_256x-320×240: ‘Smoothed’ nearest neighbour
Picoscale_bl2_256x-320×240: 2-level-bilinear with 2 quantized weights
Picoscale_bl4_256x-320×240: 4-level-bilinear with 4 quantized weights

Essentially, both image ‘smoothness’ and performance requirements increase in order of snn -> bl2 -> bl4.

Go here to see several screenshots demonstrating the output of each filter type: (click for full-size images)

These filters are highly efficient. Tested with the Snes9x 2005 Plus core (a lightweight core which is nonetheless at the upper limit of many low powered handheld devices), we see the following increase in total performance overheads when each filter is applied (note that the existing Upscale_256x-320×240 filter is included for comparison):

Filter Performance overhead
No filter +0%
snn +8%
bl2 +13%
bl4 +30%
upscale_256x_320x240 +27%

The performance overheads relative to the existing Upscale_256x-320×240 filter are:

Filter Performance overhead
snn -69%
bl2 -45%
bl4 +14%

Thus SNN and BL2 in particular have very little performance impact.

All credit goes to irixxxx – many thanks for giving us permission to use your work in RetroArch!

In other video filter news, the Switch/libnx port now also has video filters support!

Playlist Manager – New ‘Refresh Playlist’ option

The manual content scanner provides a quick and easy method for generating playlists – but there exists no convenient way to update playlists that already exist. If a user adds content to a ROM directory then they must go to the trouble of reconfiguring and re-running the manual scan (including selecting the ROM directory, system name, default core, etc.); if they have simultaneously removed some files, then they are also obliged to go to the relevant ‘playlist manager’ menu and ‘clean’ the playlist. This is time consuming and tedious.

1.9.10 adds a new Refresh Playlist option to the ‘playlist manager’ menus. When selected, the current playlist will be re-scanned with the manual scan configuration that was last used to generate/edit the playlist. ‘Refreshing’ a playlist also populates all entries of the Manual Scan menu – so it is easy to tweak values should the user wish to update the allowed file extension list, etc..

In addition: a new Validate Existing Entries option has been added to the manual scan interface. When enabled, any existing playlist is checked before commencing the content scan; entries referring to missing files, or files with invalid extensions, are then removed.

Validate Existing Entries is disabled by default, but automatically enabled whenever a playlist is refreshed. Thus selecting Refresh Playlist will both add new content and remove missing/invalid entries.

Note:

  • This functionality will not work with playlists generated before this commit, since they will lack the required metadata. It will be necessary for the user to re-run a ‘normal’ manual scan for any playlist they might want to later refresh; thereafter, the Refresh Playlist option will appear in the relevant ‘playlist manager’ menu and maintenance becomes a one-button affair.
  • We can only ‘refresh’ playlists created via the manual content scanner – not the database scanner. When performing a database scan, there is no practical method for extracting all required metadata for a repeat operation.

3DS – Add bottom screen idle state

Some nice QoL improvement for RetroArch 3DS users! 1.9.10 allows the bottom screen on the 3DS to be disabled when idle. On compatible devices, the bottom screen backlight is toggled.

If no core is running, the bottom screen is always idle with the backlight turned off.

If a core is running with the bottom screen in it’s ‘default state’, the bottom screen will idle in ~6 seconds. The displayed text “Tap the bottom screen to go to the Retroarch menu” fades out and the LCD backlight is disabled.

When interacted with the screen, the backlight turns on and toggles the menu as usual.

When in the menu / paused, the bottom screen remains active.

RetroAchievements/Cheevos improvements

Don’t write achievement credentials to override

Ignores changes to cheevos_token, cheevos_password, and cheevos_username when generating config override files.

While this is particularly important for not remembering a stale authentication token, not entering any credentials until after loading content, and then saving the override could lead to the actual password being stored in the override even after the authentication token is generated and put in the master settings file.

Since neither the authentication token nor the password should be stored in the override file, I believe it also makes sense to exclude the username, as having a per-override username would also require a per-override authentication token or password. If a players wants to have a separate retroachievements user for a specific core, they can still manually add the entries to the override file, but those will be cleared out any time they update the override file from within the application. A better solution would be to use separate master configs and launch using the –config option.

Disable slowmotion when enabling hardcore mode

There’s already code preventing the user from toggling (or otherwise using) slowmotion when achievement hardcore mode is enabled. Slowmotion provides an advantage for the user’s reflexes, so we don’t allow it in hardcore mode.

This addresses an issue where the user could enable hardcore mode with slowmotion already toggled on, and it would remain on. The user would be locked in slowmotion as the toggle would be disabled, but with enough patience, it could be worth it. With this change, slowmotion is disabled when enabling hardcore mode.

Changelog

1.9.10

  • 3DS: Add bottom screen idle state
  • 3DS: Add unique IDs for Gearboy/Gearcoleco/Gearsystem, correct CAP32 code
  • 3DS/SAVESTATES: Fix RAM states to file when core deinits
  • AUDIO/MIXER: Pad sample buffers to prevent potential heap-buffer-overflows when resampling (fixes crash when using 30 kHz menu audio files)
  • AUDIO/LINUX/SNAP: Add JACK support
  • CHEEVOS: Don’t write achievement credentials to overrides
  • CHEEVOS: Disable slowmotion when enabling hardcore mode
  • D3D9: Fixed MVP matrix issue for RGUI texture (main game frame still won’t show up though)
  • D3D11/D3D12/HDR: Fixed contrast to be more correct – now scales from 0-10 linearly and behaves more the way you’d expect it to – changed name to ditch legacy settings users may have
  • D3D11/HDR: Fixed D3D11’s blend, rasterizer and topology states not being set to the sames when using HDR and leaving the menu – caused issues with PCSX2’s Shadow of the Colossus
  • D3D11/D3D12/HDR: Added ability to skip inverse tonemapper to the shader via the constant buffer using ‘inverse_tonemap’ – set to 0.0f to skip
  • D3D11/D3D12/HDR: Fixed potential bug when swapping between hdr and sdr and the bit depth not being set correctly
  • D3D11/D3D12/HDR: Added numerous helper functions to help create the correct values to colour the UI – normally the white UI elements should be rendered at paper white not max brightness for various reasons
  • BUGFIX/ANDROID: Fix crash that could happen on Android with Sameboy core – would crash on rumble function
  • GFX/WIDGETS: New regular widget message appearance
  • INPUT/MOUSE: Add distinct mouse zero index label for drivers that do not support multimouse
  • INPUT/RUMBLE: Add generic rumble gain to input settings
  • INPUT/UDEV/X11: Add workaround to fix keyboard input when using X11 + Udev
  • LIBNX/SWITCH: Add Video Filters support
  • LOCALIZATION: Fetch translations from Crowdin
  • OPENDINGUX/BETA: Disable OpenAL
  • PLAYLISTS: Add ‘Refresh Playlist’ option
  • STEAM: Initial release on Steam
  • UWP/VFS/XBOX: Improvements and bugfixes to UWP VFS driver
  • VIDEO/REFRESH RATE: Automatic PAL/NTSC refresh rate switch where available – as long as the platform display server allows changing refresh rates and the display has the desired refresh rate
  • VIDEO FILTERS: Add ‘Picoscale_256x-320×240’ video filter
  • WIIU/HID: Fix analog inputs on HID devices