Site icon Libretro

RetroArch 1.8.2 released!

Libretro Team

Merry Christmas, everyone!
RetroArch 1.8.2 has just been released.

Grab it 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 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!

Big features

Accessibility for blind people

With RetroArch 1.7.8, we introduced the AI Service. This exciting feature makes it possible to do on-the-fly machine translation of foreign languages to any language of choice. Especially handy for all those dozens of old Japanese video games that never saw a translation either due to lack of financial interests/feasibility or obscurity. Now, with version 1.8.2, we are once again heading into uncharted waters where fear will dare, and introducing fullblown accessibility features for blind people.

This feature can be found under Settings -> Accessibility. Right now, it is only implemented on Windows, macOS and Linux.

There’s an entire article dedicated to this feature alone – read our blog post here to learn more.

To learn more about how to use it, read our dedicated wiki page on it.

Update all your installed cores with one simple press!

One of the most requested features since the beginning!

You can now update all the cores you have installed by going to Online Updater and selecting ‘Update Installed Cores’. It will check every single installed core, verify if there is an updated core on our buildbot, and upon detecting that the version on the buildbot is newer, it will download the new core automagically for you.

This fixes a number of serious issues that people had with the update process before. One, the tedium of having to update your cores one by one. Two, the uncertainty of whether or not an updated core is even available. When you were updating a core before, you had no idea whether you are downloading the same versioned core, or whether it was a newer version.

This brings us to the second biggest improvement. Before downloading a core, RetroArch will check if the core available on the buildbot is newer. If so, it will download the core and rewrite the existing core. If not, it will inform you that this core is already updated to the latest version, and therefore RetroArch won’t bother downloading the core again. This saves us bandwidth and you bandwidth and time. A win-win I’m sure you’d agree.

Manual content scanner (w/o checking the database)

Talk about another long-requested feature, here it is finally!

From this version on, there is a new simple manual content scanner – i.e. a ‘dumb’ scanner that matches all files (based on user configuration) without checking the databases. The interface looks like this:

The scan options are as follows:

Content Directory: Select directory to scan. The starting path for this is configured via the normal File Browser path in Settings > Directory, so it is highly recommended to set this first before beginning a scanning session.

System Name: This corresponds to the conventional ‘database’ setting, used to name the resultant playlist and to identify thumbnails. This has the following options:

Content Directory: The name of the content directory is used

Custom: Allows entry of a custom name

The user can also select the name of any installed database

Custom System Name: This is the name used when System Name is set to (it is otherwise ignored)

Core: Allows a default core to be specified

File Extensions: Allows user to filter scanned files by specifying a space-delimited list of allowed file extensions. Some further notes are required here:

If File Extensions is left blank and no Core is specified, all files are scanned

If File Extensions is left blank and a Core is specified, all files supported by the core (+ all archive files) are scanned

If File Extensions is specified, only files with matching extensions are matched. An example use case: The PCSX ReARMed core supports both bin and cue files, which means you end up with a mess of duplicates in the playlist by default. Setting File Extensions to cue excludes the bins and keeps everything clean.

Overwrite Existing Playlist: When enabled, any existing playlist content will be erased (useful if the user previously made a mistake, and wants to start over). When disabled, only content not already present in the playlist will be added (useful as a second pass to a conventional database scan, to pick up any files that were missed)

Scan inside archives

In addition to this, the manual scanner also has an option called ‘Scan Inside Archives’. Here’s how it works:

Scan Inside Archives DISABLED:

If no Core and no File Extensions are specified, all archives will be treated as valid content, and will be added (as the archive itself) to playlists

If a Core or File Extensions are specified, archive files will be ignored unless they have a file extension included in the Core or File Extensions list of supported file types (and again, in this case the archive itself will be added to playlists)

Scan Inside Archives ENABLED:

If no Core and no File Extensions are specified, all archives will be scanned: if they contain a single file, the internal path to that file will be added to playlists; if they contain multiple files, the archive itself will be added to playlists (i.e. we assume MAME-style content if archives contain multiple files)

If a Core or File Extensions are specified, archives in the supported file types list will be added to playlists directly. Other archives will be scanned, and the first internal file on the supported file types list will be added instead

This makes scanning quite a bit cleaner and more rigorous. Users who don’t archive their ROMs can leave Scan Inside Archives disabled and not think about it. Users who do archive their ROMs can enable Scan Inside Archives and be assured that only compatible content will be added to playlists, using the same ‘internal referencing’ that is currently used by the old database-based scanners.

Enable automatic naming of arcade content via DAT files

The manual content scanner also has a new Arcade DAT File option.

This is compatible with DAT files in either Logiqx XML or MAME List XML format. When a DAT file is selected, a lookup is performed for each item of scanned ‘archive-type’ content. This allows automatic conversion of ‘meaningless’ arcade file names (e.g. garou.zip) into proper description labels in playlists.

These DAT files are readily available online – e.g.:

https://github.com/libretro/FBNeo/tree/master/dats
http://www.progettosnaps.net/dats/MAME/
https://github.com/libretro/mame2003-plus-libretro/blob/master/metadata/mame2003-plus.xml

Less RAM-intensive

We recommend that systems that are RAM-starved, such as game consoles, make use of this feature if they experience problems with the database-based scanner system that has been the only option up until now.

Much faster video playback with improved ffmpeg core

An entire article was dedicated to this. Read more about it here.

RetroArch 1.8.2 now has much faster video decoding. You can select between hardware video decoding or threaded software decoding.

When using the video playback core (ffmpeg), go to Quick Menu -> Options in order to fiddle with the options. To set it to hardware video decoding, set ‘Use hardware decoder (Restart)’ to ‘auto’. If your GPU driver supports any of the accelerated video backends that ffmpeg supports, it should use this under the hood. If it fails to find either a suitable backend or if the video codec is not hardware accelerated, it will fall back to software video decoding (the previous default in past RetroArch versions).

NOTE: If you know what you’re doing, instead of setting ‘Hardware decoder’ to ‘Auto’, you can set it to any of the specific APIs – DXVA2, D3D11VA, VDPAU, VAAPI, QSV, CUDA, Videotoolbox, DRM, OpenCL, and/or MediaCodec.

If your system for whatever reason does not have hardware accelerated video decoding capabilities available but it does have a multi-core CPU, you can alternatively take advantage of threaded software decoding. To use this, go to Quick Menu -> options, and set ‘(Use hardware decoder (Restart)’ to ‘off’. The next setting to configure is crucial – ‘Software decoder Thread count (Restart)’. You can either leave this at ‘auto’ if you trust in the program to intelligently pick the right amount of cores for decoding based on your CPU’s capabilities, or set it to a specific number.

Make sure to restart the video player if you make any of these changes, the changes won’t take effect on the fly.

Multi-threaded video decoding and color conversion

Not only can the video decoding itself be multi-threaded, but so can colorspace conversion. This was previously a single threaded operation. This also obviously results in a big performance boost.

To play it safe, the default encoder being used is the software decoder for now, since it’s the most robust decoder and should produce the best results for most users right now (Embedded systems aren’t particularly well supported yet by the ffmpeg hw decoding backend). Both the threaded video decoding and hardware video decoding are orders of magnitude faster than video playback in previous RetroArch versions.

Vulkan Android fixes

Themaister spent some time fixing some longstanding issues with the Vulkan driver on RetroArch Android.

You can now finally change from landscape to portrait orientation and vice-versa. The framebuffer is now properly rebuilt on the fly. Seems like a minor thing, but it was very inconvenient to have to start something from landscape mode and then be forced to stay in landscape mode (or vice versa) if you didn’t want the screen output to be messed up as a result.

An even more important bug got fixed related to glslang – this should improve overall system stability for every video driver that implements glslang for shader support (Direct3D 10/11/12, Vulkan, OpenGL Core, WiiU GX2 Video driver, Metal).

Usability improvements

We have dedicated an entire separate article to it since the list of improvements is so exhaustive. Check it out here.

Vita improvements

The Vita platform port has seen some significant improvements too.

We have a bounty now where we stress the importance of bringing over OpenGL 1 hardware context support to libretro. Many old game platforms have fixed function GPUs with a featureset roughly comparable to OpenGL 1.4, so it makes sense to have a hardware context for GL 1.x. Right now, Libretro offers a couple of options for people wanting to make cores implementing OpenGL – you can either target desktop OpenGL (of any particular version), or you can target OpenGL ES 2/3. The key requirement for both though is that it requires the use of FBO (Frame Buffer Object) – if your GPU and/or API has no support for that, it’s over and out as far as GL core support is concerned.

OpenGL 1.x had no notion yet of FBOs, so obviously this hardware context will not have any such requirements. We encourage you to contribute to this bounty if you are excited about the potential this can bring to older game console platforms and other older hardware. You can find the link here.

Vita now has an OpenGL 1 driver implemented. As soon as the Libretro GL 1.x support is done, Vita users can stand to benefit from the GL-centric cores that can be brought over to Vita as a result.

However, for now, we heavily recommend you use the Vita2D driver as your primary video driver. Speaking of which, several improvements have been made to it as well – menu widgets have been implemented, and it should be more optimal now due to a reduction of draw calls.

Changes

We could write an entire book about all the changes, improvements and features that made this release what it is thanks to our dedicated inhouse team and all the generous contributors that continue to contribute to the project. So without further ado, view our changelist below – and realize that there are many things we might not have even covered in this release –

1.8.2

What’s next?

We’re going to be figuring out a solution soon so we can add ANGLE support for both the regular Windows desktop versions as well as the UWP version (the version used on platforms like Xbox One for instance). If you don’t know what all this is about, check our article here.

For people annoyed about the lack of communication regarding the Steam version, we get you, but if you take even a cursory glance at steamdb, you can see that we are hard at work on that front as well. We will update you later on this front as we have been told it’s best to only make further statements on this when things have become more concrete in terms of release. We learned our lesson with the initial announcement. We apologize for the radio silence, we are just cautious about how we present this to the outside world. We hope we have some positive news for you there soon. In the meantime, please appreciate all the effort and hard work that went into this current version as a consolation. After nearly a decade in development, we feel as strongly as ever to have RetroArch be all it can be. We hope you will join us in that endeavor in the upcoming decade to come.

Exit mobile version