Site icon Libretro

RetroArch 1.10.2 release!

Libretro Team


RetroArch 1.10.2 has just been released.

Grab it here.

If you’d like to learn more about upcoming releases, please consult our roadmap 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. We have always prioritized the endusers experience, and unlike others, we have never emburdened them with in-app ads, monetization SDKs or paywalled features, and we intend to continue to do so. 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

Big improvements for Steam and Steam Deck users


We’re gearing up for Steam Deck, and in the process we are finally starting to turn the RetroArch Steam version into something more than just a plain port (courtesy of Mats).

We came up with a SteamWorks shim that allows RetroArch Steam to interface with the Steamworks API. Mist, our middleware tool, runs in a separate process, runs concurrently wtih RetroArch Steam, and functions as a bridge between this separate process interfacing with Steamworks and the GPL application itself running in an entirely different process. This is 100% GPL compliant and the same approach has been employed by numerous other examples on Steam, including the aforementioned Icculus.

Thanks to Mist, here are some of the big new features for Steam users (and in particular, Steam Deck users):

As a result of these changes, the Steam port is starting to become its own thing rather than just a straightforward no-frills port of the Windows/Linux versions.

Improved audio sample pacing / latency in many cores

Big improvements have been made to several cores concerning improved audio latency and audio sample pacing.

Not only should performance be better, but you should also be able to lower audio latency buffers now while still getting perfect sound.

Here are some of the cores that have received work recently on this front:

For example, frame time deviations in a core like Snes9x 2010 are now extremely low with a default 64ms audio buffer. We measured 0.4 to 0.3% deviation, and this figure could likely be optimized even further by fiddling some more with audio buffer latency, or changing the audio driver.

Other measures have also been taken to further improve audio latency. Some cores have been updated now so that audio gets pushed to the frontend (i.e. RetroArch) AFTER the video frame has been uploaded. This is just in case the audio upload blocks for too long due to audio processing and syncing performed by the frontend. Uploading the video frame as soon as possible after the emulation loop is generally a good idea since it potentially avoids unnecessary input latency.

Steps have also been taken in cores to minimise use of the audio batch callback (for example, Tyrquake and Snes9x 2010), leading to better audio sample pacing, less overhead and better overall performance.

For Miyoo users

The following cores have been added for Miyoo platform users:

For OpenDingux users

The following cores have been added for OpenDingux platform users:

UI/UX improvements


RGUI, MaterialUI and Ozone menu drivers now have new color themes. ‘Gray Dark / Gray Light’ themes have been added.

For XMB users, vertical fade adjustments have been made so that it functions a bit better like the original. Title margin can now also be adjusted, so that the title won’t cut off anymore on display devices with overscan (i.e. CRT TVs).

For RGUI users, 6×10 extended ASCII and Latin Extended A and B fonts have been added. These will enable most Latin alphabets to be displayed in RGUI.

For Ozone users, a thumbnail scaling option has been added (Settings->User interface->Appearance). This option scales the size of the thumbnail sidebar, which in turns means the thumbnails are scaled along with it. It should scale the thumbnails so that they should fill up more screen real estate now in the right sidebar. See the picture below for an example.

Manage Input Remapping Files

1.10.2 adds a new Manage Remap Files submenu to Quick Menu > Controls:

This updates correctly in real-time (the previous save/remove remap menu entries do not…), and only shows relevant options. When removing a remap, existing files are re-scanned and the one with the next highest priority (if found) will be loaded.

In addition, the currently active remap file will be saved automatically when closing content – i.e. it is no longer necessary (or indeed possible!) to save the file manually after each change.

We have also added a new Reset Input Mapping entry under Quick Menu > Controls > Manage Remap Files:

We have also fixed a nasty bug that could cause remap file corruption (incorrect or unwanted entries) when saving a remap after resetting one or more binds.

Prevent ‘global’ configuration of input libretro device type

Before, RetroArch allowed the input ‘libretro device type’ to be set globally per-user. This was nonsensical for a couple of reasons:

1.10.2 fixes the issue by:

Note that device type is no longer stored in the main RetroArch config file, only in input remap files.

WiiU – Optimize for Gamepad

RetroArch WiiU adds a new option (Settings -> Video -> Output -> Optimize for GamePad). When enabled, it uses a 960p viewport if the user is on either 720p or 1080p (if they’re on 480p, they’re already optimized for GamePad). It defaults to off, so the native TV resolution is still preferred out of the box.

Explanation

The Wii U is a weird case with RetroArch because of the two screens (TV and Wii U GamePad). The Wii U can be configured to output video at 480p, 720p or 1080p (or interlaced equivalents), whereas the GamePad has a native 480-line display. While it is possible to send different images to the TV and GamePad, RetroArch currently sends the same image to both. This creates a bit of a conundrum as 480 does not divide evenly into any of the other available resolutions.

When running 240p content, setting the Wii U to 720p just works, because a 3x integer scale (240*3 = 720) on the TV also happens to be a 2x integer scale (240*2 = 480) on the GamePad. However, when running 480p content, having the Wii U set to 720p will result in a poor image all around, with non-integer scaling from 480->720 on the TV, and then even worse, 480->720->480 on the GamePad.

Running the Wii U at 1080p, you get the worst of all worlds. Absolutely nothing divides evenly into 1080, so no matter what content you’re playing, you’ll need either large borders or a filter/shader to stretch to that non-integer resolution, and putting that 1080p image back on the 480p GamePad makes it even worse again. Many users only use 720p because of the poor results you get from 1080p currently.

By running 1080p with a 960p viewport, you can do things like a 4x integer scale of 240p content which becomes a 2x integer scale on the GamePad, or a 2x scale of 480p content which becomes a 1x native display on the GamePad. Even more exotic resolutions like the Game Boy Advance (160p) are enhanced, with 160 dividing 6x into 960 or 3x into 480. This one change makes 1080p a lot less useless on Wii U.

And more

Not listed here of course are all the countless improvements made to individual cores since the last version. We might go into more detail on that sometime later, but rest be assured that cores are updated on a daily basis and receive heavy improvements, so keep updating your core library to get the latest benefits at all times!

Changelog

1.10.2

Exit mobile version