RetroArch 1.8.2 released!

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

  • BUG/CRASH/GLSLANG: Fix glslang crashing error – managed to reproduce an issue which has been plaguing users for a while, where glslang throws an assert after closing a game (and starting a new one). This would affect all video drivers that use Slang for shaders, such as D3D10/11/12/Vulkan/Metal
  • CHEEVOS: Display Unofficial and Unsupported achievement states
  • CHEEVOS: Pass RetroArch and core versions through User-Agent HTTP header
  • CHEEVOS: Use PSX.EXE if SYSTEM.CNF cannot be found
  • CHEEVOS: Prevent loading state while achievements are still being fetched from server
  • CHEEVOS: Pause hardcore if core doesn’t support achievements
  • CHEEVOS/CRASH: Fix AddressSanitizer + CHD cause hard crash when Cheevos are enabled
  • CORE UPDATER: Only download when new core is available
  • CORE UPDATER: Add option to update all installed cores
  • DRM/KMS: Better detection for the current video mode
  • DYNAMIC RATE CONTROL: Support DRC even when using a vsync swap interval higher than 1
  • EMSCRIPTEN: Fix bug in Emscripten input code
  • EMSCRIPTEN: Changes to support upgraded emscripten SDK
  • FFMPEG CORE: Hardware accelerated video decoding
  • FFMPEG CORE: Implement send/receive encoding API, will allow for hardware accelerated AMD video encoding
  • FFMPEG CORE: The video FIFO can be removed, since we have a ring buffer in its place. This removes unneeded copy operations and as a positive side improves overall decoding speed. Makes 8k60p SW and 4k60p HW decoding feasible on many systems. For now the ring buffer is 32 images deep. This limitation will be removed, once audio and video decoder have their own packet handling.
  • INPUT: Fix ‘Analog stick controls menu even if autoconfig disabled’
  • INPUT/TURBO: Added alternate Turbo-Mode ‘Single Button’ – For systems supporting only a single button, the turbo-button will toggle firing that button without the need to hold it. When holding the button turbo will be suspended and resumed when the button is released. Holding the button may have a different function to just tapping it.
  • IOS: Forcibly disable Threaded Video until UIWindow concurrency issues are fixed
  • INPUT/ANALOG: Fix radial analog deadzone scaling
  • INPUT/ANALOG: Implement proper analog button deadzone
  • INPUT/MENU: Analog stick controls menu even if autoconfig disabled
  • LOCALIZATION: Update Italian translation
  • LOCALIZATION: Update French translation
  • LOCALIZATION: Update Polish translation
  • LOCALIZATION: Update Portuguese Brazilian Translation
  • LOCALIZATION: Update Turkish translation
  • LINUX/LOCALIZATION: Correct Droid Sans Fallback font path in Linux. This should fix Chinese/Korean font display issues on Fedora/RHEL/CentOS/openSUSE/SLE
  • MENU/BUGFIX: When using a keyboard/gamepad/mouse wheel to navigate, the menu scroll position is always maintained and updated in a consistent (and expected) fashion
  • MENU/BUGFIX: When resizing the window, or changing the orientation of a mobile device, the current scroll position is correctly preserved
  • MENU/BUGFIX: All ‘normal’ pointer input is now inhibited when showing message boxes
  • MENU/BUGFIX: The pointer actions ‘select’ and ‘cancel’ both now properly close a message box if it is currently being shown
  • MENU/BUGFIX: Pointer ‘select’ and ‘cancel’ actions are now inhibited when an input bind dialog is active
  • MENU/INPUT: Change ‘User’ terminology to ‘Port’ for input binding
  • MENU/LINUX: Add proper drives to Load Content
  • MENU/MATERIALUI: Halt scrolling when pointer is pressed/stationary
  • MENU/MATERIALUI: Dual thumbnail view
  • MENU/MATERIALUI: Fullscreen thumbnail viewer for boxart
  • MENU/MATERIALUI: Scroll rapidly by press and holding the scrollbar
  • MENU/RGUI: New theme ‘Flux’
  • MENU/OZONE: Thumbnails now have a fade-in animation
  • MENU/OZONE: Fullscreen thumbnail viewer for boxart and pictures
  • MENU/QT/WIMP: Fix dock titles getting cut off
  • MENU/XMB: Fullscreen thumbnail viewer for boxart and pictures
  • MENU/USABILITY: Selectively hide ‘Disallow Non-Slave Mode Clients’ if ‘Allow Slave-Mode Clients’ is disabled
  • MENU/USABILITY: Hide ‘Show desktop menu on startup’ if ‘Desktop menu’ setting itself is disabled
  • MENU/USABILITY: Reimplement Quick Menu – > Shaders -> Watch shader files for changes – can now be turned on/off through touch

  • MENU/USABILITY: Refactor Quick Menu – Controls – each port now has its own submenu
  • MENU/USABILITY: Quick Menu – Cheats – Delete All no longer requires five right button presses – this should fix this functionality for mobile touch users too
  • MENU/USABILITY: Hide Refresh Rate options when Threaded Video is enabled – these settings do nothing with Threaded Video
  • MENU/USABILITY: Hide Logging Verbosity levels behind Logging Verbosity
  • MENU/USABILITY: Get rid of ‘Port Number’ label for Port Binds screen
  • MENU/USABILITY/MOBILE: Should no longer crash when clicking on a cheat entry
  • MENU/USABILITY: Shader parameters now have a dropdown list
  • MENU/USABILITY: Shader passes now has a dropdown list
  • MENU/USABILITY: Video – Hide Windowed Mode settings selectively
  • MENU/USABILITY: Video – Hide Fullscreen Mode settings if windowed mode is not supported by context driver
  • MENU/USABILITY: Selectively hide Network Command Port
  • MENU/USABILITY: Selectively hide Relay Server Location
  • MENU/USABILITY: User Interface -> Appearance – Selectively hide XMB Horizontal Animation setting
  • MENU/USABILITY: Playlists – more selective hiding
  • MENU/USABILITY: Selectively hide Rewind Settings
  • MENU/USABILITY: Selectively hide Overlay Settings
  • MENU/USABILITY: Selectively hide FPS Update Interval based on Display Framerate being enabled
  • MENU/USABILITY: Selectively hide Onscreen Notifications BG Color Settings
  • MENU/USABILITY: Settings -> Logging – Hide ‘Log To File Timestamp’ if ‘Log To File’ is disabled
  • MENU/USABILITY: Video -> Scaling – Hide Custom Viewport X/Y when Integer Scale is enabled as description indicates
  • MENU/USABILITY: Achievement submenu – selectively hide
  • MENU/USABILITY: Settings -> Video -> Aspect ratio – selectively hide/show values based on whether you have Custom or Config selected
  • MENU/USABILITY: Settings -> Video -> Selectively hide Hard Sync
  • MENU/USABILITY: Settings -> Video -> Implement selective hiding for VSync and Hard Sync
  • MENU/USABILITY: Selective hiding of Runahead settings based on global setting
  • MENU/USABILITY: Add Input -> Haptic Feedback submenu
  • MENU/USABILITY: Add Input -> Menu Controls submenu
  • MENU/USABILITY: Settings -> Video -> Max Swapchain Images – Add OK action
  • MENU/USABILITY: Input – Implement OK action for Bind Hold, Turbo Period and Duty Cycle
  • MENU/USABILITY: Input – Hotkey Binds refactor
  • MENU/USABILITY: Move ‘Press Quit Twice’ and ‘Menu Toggle Gamepad Combo’ to Input -> Hotkey Binds
  • MENU/USABILITY: Video – Add sublabel for Video Output submenu
  • MENU/USABILITY: If ‘Favorites Tab’ is disabled, don’t show ‘Add To Favorites’ option in Quick Menu/Playlist menu
  • MENU/USABILITY: If On-Demand Thumbnail Downloader is enabled, hide ‘Download Thumbnails’ from playlist menu screen
  • MENU/USABILITY: Add Audio Driver setting to Audio -> Output
  • MENU/USABILITY: Add Audio -> Resampler settings
  • MENU/USABILITY: Add Audio -> Output and Audio -> Synchronization
  • OPENGL: Shaders are now working properly (only in OpenGL) when rotating both from Core API rotation and from menu video rotation. The fix is clearly visible with crt-royale for example
  • OPENGL: 1:1 PAR is now correct when rotating (both from Core API rotation and from menu video rotation, as you said, in the latter case you currently have to change Aspect Ratio after menu video rotation for it to work)
  • OPENGL: When using Custom Aspect Ratio and rotation (both from Core API rotation and from menu video rotation), Integer Scaling is now working properly (correct multiples of internal resolution). Even when Integer Scaling is not activated, the Custom AR width / height are now correctly labeled using (1x), (2x), … suffixes. You also have to activate Integer Scaling after menu video rotation for it to work
  • OPENGL: For all other Aspect Ratio options, Integer Scaling and rotation (both from Core API rotation and from menu video rotation) are now working properly together (correct multiples of internal resolution). You also have to activate Integer Scaling after menu video rotation for it to work
  • OPENBSD/POWERPC: Should build now on OpenBSD PowerPC
  • PLAYLISTS: Pressing ‘Start’ or long touching a playlist will bring you to a Playlist submenu where you can set a default core, setup thumbnail view, delete the playlist, etc
  • OSX: Forcibly disable Threaded Video until NSWindow concurrency issues are fixed
  • PSP: Solving issue exiting RetroArch by HOME button
  • SCANNER: Manual scanner, not dependent on database files
  • SCANNER/MANUAL: Add option to scan inside archives
  • SCANNER/MANUAL: Enable automatic naming of arcade content via DAT files. This is compatible with DAT files in either Logiqx XML or MAME List XML format.
  • VIDEO: Do not reinit video driver on SET_SYSTEM_AV_INFO unless needed
  • VIDEO: Support DRC even when using a vsync swap interval higher than 1
  • VIDEO LAYOUT: Fixed XML parsing of attributes with spaces, should fix issues with several video layouts
  • VITA: GL1 driver support
  • VITA/VITA2D: Several improvements to Vita 2D driver – menu widgets implemented
  • VITA/VITA2D: Fix clipping and reduce number of calls
  • VULKAN/ANDROID: Workaround weird WSI return codes in landscape mode – Android WSI wants you to use preTransform, and if it is not used correctly, Android 10 will return VK_SUBOPTIMAL_KHR, and we would create a new swapchain every frame. This workaround just ignores this error, since it’s not really an error. A more “proper” fix is to use prerotate and modify the MVP matrices, which might help certain devices with crummy display processors
  • VULKAN/ANDROID: Recreate swapchain on orientation change. ANativeWindow getWidth/Height does not detect any changes when using Vulkan, so use the old onContentRectChanged callback to get notified when size changed. Use those values instead when figuring out how large swapchain to create
  • WINDOWS/XINPUT: Get rid of 128 byte device name limit for XInput device discover – when device name was too long, it would not be picked up by the XInput driver and would instead fallback to DirectInput
  • WINDOWS: ANGLE OpenGL ES 2 support
  • UWP: Fix crashes on startup / prompt for folder permissions when trying to load custom.ini
  • UWP: Fix – Mouse input is offset on high DPI monitors
  • UWP: Fix – Keyboard input hangs sometimes
  • UWP: Fix – Multi-touch support
  • UWP: Fix – Enable menu touch input by default
  • UWP: Fix – Get user language
  • UWP: Fix – Get CPU model name
  • UWP: Fix – Use GLUI instead of XMB on Windows Mobile 10
  • UWP: ANGLE OpenGL ES 2 support

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.

RetroArch 1.8.2 – Usability Improvements

This is an addendum article to our main RetroArch 1.8.2 release post. To read the main article, read this here.

Fullscreen thumbnail viewer

We have added a fullscreen thumbnail viewer to Material UI, Ozone, and XMB. It’s analogous to RGUI’s fullscreen thumbnail view mode.

When viewing any playlist thumbnail view, fullscreen thumbnails may be shown for the selected entry by:

Long pressing the entry (mouse or touchscreen)

Pressing start on a gamepad

Pressing space on a keyboard

When fullscreen thumbnails are shown, any menu action will disable them again.

Here are some random example screenshots of fullscreen thumbnails in action:

MaterialUI – Dual thumbnail support

RetroArch has added dual thumbnail support to the Material UI menu driver.

A new Show Secondary Thumbnail In List Views option has been added under User Interface > Appearance. When enabled, two thumbnails are shown in all List views (Small, Medium, Large) – but only if the display is actually wide enough to show two thumbnails. It looks something like this:

If the Secondary Thumbnail option is set to OFF and the user explicitly requests a thumbnail view with secondary thumbnails enabled, the global Secondary Thumbnail option will automatically be set to an appropriate value. This prevents users with fresh installs (default options) from getting a list of ‘missing thumbnail’ images when selecting a view with mandatory secondary thumbnails. NOTE: This does not affect per-playlist thumbnail overrides – if the user wishes to force disable secondary thumbnails with such an override, they are still free to do so.

A new Draw Thumbnail Backgrounds option has been added under User Interface > Appearance. This is enabled by default (which matches the existing behaviour), and when disabled allows thumbnails to be drawn without a solid colour background.

Selective hiding for settings

Several important improvements have been made when it comes to the settings and the overall presentation of them.

Let’s go over some of the most important changes:

  • We have subdivided many cluttered entries into submenus. Examples: Video -> Scaling, Output, CRT Switch Res.
  • We have included dropdown lists now for several important actions, such as ‘shader parameters’.
  • We now selectively hide options based on context. For instance, if you have Vsync disabled, it makes no sense to show you ‘Vsync Swap Interval’ as well. So when Vsync is disabled, the screen gets refreshed and the Swap interval setting is not shown until you turn Vsync on again. We have made sure to implement this in as many settings categories as possible, see our exhaustive changelog for the nitty gritty.
  • There were many settings which were not clickable before with touch-based devices such as mobile phones.

Let’s now go into some specific examples of what we consider by increased usability – let’s take Video -> Scaling –

Aspect Ratio is currently set to ‘Core Provided’. We now bring up the dropdown box, and we select ‘Custom’ from the list.

Upon selecting ‘Custom’, we can now see several entries have appeared – ‘Custom Aspect Ratio X Position’, ‘Custom Aspect Ratio Y Position’, ‘Custom Aspect Ratio Width’, and ‘Custom Aspect Ratio Height’. If you read the description for X and Y position, you’ll notice that the sublabel states that if ‘Integer scale’ is enabled, these settings will be ignored and the X/Y position will be done automagically. In the past, we’d just have listed all these settings regardless of what aspect ratio is selected. Now watch what happens when we set Integer Scale to enabled –

As you can see, X and Y Position are now hidden from view. They won’t be shown again until you turn Integer Scaling off, at which point they’ll actually serve a purpose again.

Now let’s try another aspect ratio. This time we’ll select ‘Config’.

We notice that the Custom Aspect Ratio settings are now gone, since they no longer serve a purpose for the currently selected aspect ratio. Instead, another setting is shown, Config Aspect Ratio.

Now, to contrast that with how things were previously –

in the past, not only would all the Custom Aspect Ratio settings be shown regardless of whether the aspect ratio was actually set to ‘Custom’, but also ‘Config Aspect Ratio’ would be shown even though the user might not have set Aspect Ratio to ‘Config’. This of course caused lots of unnecessary clutter which leads to confused users who can’t find the needle in a haystack anymore.

We have implemented tons of these usability flourishes everywhere and we hope this leads to an increased positive user experience.

MaterialUI Playlist management

It’s now possible to long press a playlist inside the Playlist tab and go to a Playlist submenu. From here, you can do various actions to the playlist, including deleting the playlist and setting a default core association to every entry in the playlist that has not yet been configured to start with a specific core.

RetroArch 1.8.2 – Accessibility features for blind people

RetroArch singlehandedly takes big strides to cater to an underrepresented group of people, opening up a whole new world of entertainment.

See here the perspective of a blind person talking about the new accessibility features available in the latest nightly versions of RetroArch. This and more will be available out of the box starting as of version 1.8.2.

Also read our version 1.8.2 release announcement post here.

Written by Devin Prater, Certified Assistive technology instructor
Edits by Barry Rowe, AI Service and Accessibility contributor

Background

For decades, video games have offered entertainment for many people. Childhoods were changed by iconic franchises like Super Mario, Zelda, Final Fantasy, and Castlevania. People can reasonably count on others to understand the meaning behind video game references.

For people who are blind, however, these games could only be enjoyed through their great music, or by reading novelizations or fanfiction. Audio games have been created, to fill the void of video games which could not be played, an some blind people braved fighting games by memorizing menus and special attacks, but audio games were few in number, and didn’t usually have much content.

Emulation

Emulation has helped many people who are blind relive their childhood playing fighting games. With the rise of machine learning, however, blind gamers now have another tool in their arsenal: optical character recognition, the extracting of text from images. With this being a part of many screen readers, blind people could use that to read menus, character select screens, and unspoken dialog.

RetroArch

RetroArch is the first “emulator” to now offer Accessibility to blind people by speaking the interface. Along with the text-to-speech AI service, RetroArch has not only become the first emulator to implement accessibility for blind people in menus, but also in reading game text as well.

This doesn’t, however, mean that all games are accessible. A blind person still cannot get Super mario into the castle in Super Mario 64, nor defeat Lavos in Chrono Trigger, although perhaps one could probably play Radical Dreamers now. Much more work will be needed to make video games completely accessible to blind people, even portraying health bars in fighting games through sound cues. Even so, the accessibility of RetroArch means that blind users of Windows, MacOS, and Linux can enjoy the state of the art in video game accessibility through emulation.

How to enable accessibility

Once you’ve downloaded and installed RetroArch, there are two ways to enabled accessibility. The first way is by turning it on via the menu. Once RetroArch is started press: right, then up seven times, then enter (on some systems this could be the x key), and then right. You should hear “Accessibility Accessibility Enable ON” at this point. If this doesn’t, restart RetroArch and try again. This method navigates the menu, which may change in later versions, so you should read the RetroArch Accessibility Docs for any updated key presses.

The second method is to enable it via the command line. This is done by running the RetroArch executable (for example: retroarch.exe) in the command line or terminal. On windows for instance, once you’ve opened the command line, navigate to the RetroArch folder, and run “retroarch.exe –accessibility” and you should hear “RetroArch Accessibility On. Main Menu Load Core.” From there you can navigate right to the settings submenu, and then down to the Accessibility option, and then turn set Accessibility Enable on. Now you’ll be able to start RetroArch with accessibility from outside the command line as usual.

If these options don’t work for you, it could be that your OS does not have the required speech libraries or voices that RetroArch needs. For windows, RetroArch uses the Windows Narrator, which you can read how to download additional voices for here. On MacOS, it uses the “say” command, which you can read how to download voices for here. And on Linux it uses Espeak. For Ubuntu, you can install espeak by running “sudo apt-get install espeak” and then “sudo apt-get install espeak-data” for the additional voices.

Using the AI Service with Accessibility

The AI Service can also use the Accessibility narrator for Text-to-Speech. This can be done by going to the AI Service settings section, and changing the AI Service Output to “Narrator Mode.” This handles the Text-To-Speech, but the AI Service still needs to process the game screen to get that text. You can follow the setup instructions for the AI Service here.

Conclusion

While people without disabilities have been able to play thousands of video games, both current and past, blind people have not had the ability to enjoy more than a handful of video games. Through
emulation, this is beginning to change. Games which were once only playable if one could memorize menus and selection screens are becoming accessible using OCR, and more will be possible through the hard work of developers who may build upon this foundation for accessible video game emulation.

RetroArch is the first emulation center to provide accessibility for the user interface, and an AI service to perform OCR on video games, allowing blind users of all three major desktop operating systems to enjoy playing fighting games now with knowledge of any text that appears onscreen. It is hoped that this is only the beginning of a great advancement in accessibility, with RetroArch paving the way to even greater video game accessibility for people who are blind.

Flycast world’s first Dreamcast emulator to receive Vulkan renderer – available later today on RetroArch with nightly core!

The first Dreamcast emulator ever to get a Vulkan renderer. Completely open-source, written from scratch, and available later today on RetroArch. Update your core later today to get the latest version with the Vulkan renderer! Available for Android, Windows, and Linux.

For more information, read down below…

Wait … a new what?

The renderer is the emulator component that emulates the Dreamcast/Naomi GPU chip, namely the PowerVR Series2. It was one of the first generations of 3D chips, with only a fixed pipeline. The PowerVR2 supported DirectX 6.0, which was the graphics API used by Windows CE games on the Dreamcast. Successors of the PowerVR2 would later be found in the original iPhone and iPod Touch (PowerVR4), iPhone 4 and iPad (PowerVR5) and many many other mobile devices. Now the Dreamcast GPU is more than 20 years old. You might think it should be easy to emulate such an ancient chip on modern hardware, right? Well … yes for the most part. But there’s one thing that the PVR2 does really well, and it’s order-independent transparency. And even today this is still not trivial to implement even on modern hardware. You won’t find this feature in Open GL or DirectX, and you need a pretty recent version of these APIs to be able to emulate it, which means manually sorting individual pixels from back to front and blending them together, and doing this for each visible pixel on the screen!

OK, but what about Vulkan?

For those of you who are not familiar with Vulkan, it is a relatively new 3D graphics API, basically a follow-on to Open GL. Open GL is quite permissive and has little declarative constraints. You just throw stuff at the driver when you need to and the driver’s job is to figure it out. The downside of this is that the Open GL driver often needs to guess what you’ll do next and he might not guess right. And when it doesn’t, performance suffers. Vulkan is radically different in that everything must be declared in advance, in great details, and there’s very little room for improvisation on the part of the driver. Vulkan works much closer to the hardware than Open GL does. So you can expect less overhead, more reliability and better performance in many cases.

The downside of Vulkan is the sheer amount of code you have to write to display just a single triangle on the screen, let alone a full-featured Dreamcast renderer. Last time I checked, the Vulkan renderer had 47 source files and around 7800 lines of code. (The Open GL renderer only has around 6000 lines of code.)

So what do we get?

As with Open GL, there are actually two Vulkan renderers: The first one uses a traditional single render pass with per-triangle or per-mesh sorting done by the CPU. The second one is capable of order-independent transparency with per-pixel sorting performed by the GPU. It uses multiple subpasses to compose the final image: the first subpass draws the opaque geometry depth map and the shadows casted on them. The second subpass renders all opaque geometry to a temporary color framebuffer, and transparent geometry into a huge pixel linked list. The last subpass then renders shadow volumes for translucent geometry. And finally all pixels are sorted and blended together using the opaque framebuffer of the previous subpass as background.

The next Flycast nightly build will have support for Vulkan on all major platforms: Windows, Linux and Android. In terms of features, the new renderer should be on par with the Open GL renderer, with the notable exception of lightgun crosshair and VMU screens display, which will be added soon. However, expect to find bugs and crashes here and there as is expected with any new piece of software. Also it may be slower than Open GL depending on many factors such as GPU, driver version, game being played, etc. We’ll do our best to fix any issue encountered and overcome performance issues. When reporting problems, make sure to indicate what GPU you’re using and the Vulkan driver version. It is highly recommended to upgrade your drivers to the latest version available, especially on mobile.

Here is a showcase of the differences between the basic and OIT renderers. By the way, this also applies to Open GL.

Here the hair of these ladies show glitching triangles in basic mode.

In Speed Devils 2, the shadow volumes (called “Modifier Volumes” in Dreamcast literature) are used in a special way to project headlights. This is only possible by using deferred rendering.

In this example, look at Ryo’s cast shadow on his left. There is a fog effect applied to this scene, but the basic single pass renderer cannot apply a fog effect to the cast shadow. In the OIT renderer, the shadow is perfectly fogged.

In Jet Set Radio, the character is composed of translucent polygons, and these polygons can be shadowed as well. Only the OIT renderer can properly render shadows cast on translucent polygons.

To finish, here is another seldom used GPU features: secondary accumulation buffer. It can be used to do tri-linear filtering and other effects. This is Evil Dead – Hail to the King and it is clear that the basic renderer is having a hard time here.

Final thoughts

Yes, the per-pixel alpha transparency option which to this date was only available on Windows and Linux now also works on Android with the Vulkan renderer. However, keep in mind that per-pixel alpha sorting is heavily memory bandwidth-limited. It has been tested on a Mali G76 (Samsung Galaxy S10+) – and it runs acceptably at 640×480 or 800×600 resolution. Your mileage may vary depending on the GPU power inside your Android phone. We recommend you to find that sweet spot which works best for you, and if results are too bad with per-pixel alpha enabled, turn back to per-triangle.

Some clear advantages of the Vulkan renderer is that frame pacing is much better than the OpenGL renderer, and performance is far higher when it comes to texture uploads and/or framebuffer manipulation. For example – when you KO an opponent in Dead Or Alive 2 against an explosive wall – the framerate would often tumble a bit on GL, but no such issues with Vulkan. Similar improvements can be noticed in Virtua Tennis 2 – when certain framebuffer effects happen after a replay, performance is much more steady with Vulkan thanks to the high degree of parallelism.

With Vulkan, we have heard reports that virtually all sound crackles and stutters are gone. That’s because with vulkan you choose the sync points where you wait. In GL the driver has to guess and sometimes it fails. These effects are using render to texture, and with OpenGL this creates sync issues.

RetroArch – Hardware video decoding – coming soon!

As you may well know, RetroArch has embedded video player support on platforms such as Windows, and Linux. Just like VLC, Kodi, mpv and other video players out there, it accomplishes this by leveraging the ffmpeg project.

Up until now, all video decoding was performed entirely in software. This means that the CPU has to do all the decoding instead of being able to delegate it to the GPU. This meant that on some systems, video playback could be too slow if the CPU was too underpowered. This so happens to be the case on many ARM SoC devices out there, such as the Raspberry Pi and Odroids.

Now, we finally support hardware video decoding through ffmpeg’s own APIs! This should really help on systems where there is a CPU bottleneck and the GPU happens to support hardware decoding. Whether or not you are able to decode 1080p, 1440p or 4K on hardware depends entirely on your GPU’s capabilities however.

In addition to hardware decoding, frame based multithreading is now enabled for SW based video decoders, but actual effectiveness hasn’t been proven yet.

The core switches back to SW based decoding if the HW based decoding couldn’t be initialized.

The following backends have been tested:

  • DXVA2 [Windows]
  • D3D11VA [Windows] (it will use this when using the D3D11 driver
  • VDPAU [Linux] (Tested on an AMD System with VDPAU to VAAPI layer)
  • VAAPI

We have performed the following tests so far:

  • Nvidia Titan XP/RTX 2080 Ti
  • – Can hardware decode 1080p/1440p/4K content.

  • Intel UHD 630
  • – Can hardware decode 1080p/1440p/4K content.

  • AMD Radeon R9 290x
  • – This is a slightly older card from 2014. It only supports 1080p hardware video decoding at best. 1440p and 4K content therefore falls back to software video decoding. This means that if your CPU is not up to the task, you won’t be able to run this content at fullspeed.

As a stress test video, we picked a 4K video (3840×2160) with a total bitrate of 29561 kb/s (h264/AVC1, YUV420P), running at 30 frames per second. The CPU we’re using for this test is an Intel Core i7 7700k. With such a CPU, we don’t really have a CPU bottleneck and we are merely GPU bound when it comes to rendering the content.

With software decoding (the current default in RetroArch) – we averaged around 55fps with the 2080 Ti. Our CPU load averages around 15% with GPU load averaging around 11%.

With hardware decoding (the 2080 Ti defaults to DXVA2 for this test) – we averaged 77fps with the 2080 Ti. Our CPU load averages around 11% with GPU load averaging around 20%.

NOTE: The above is long since out of date – the same video is now 256fps with hardware decoding and 224fps with threaded video decoding at an automatically defined amount of threads. Quite the improvement from 55fps I’m sure you’ll agree.

What remains to be done

We will still need to gather tests for the following backends:

  • Cuda
  • Videotoolbox
  • DRM
  • OpenCL
  • Mediacodec

Future plans

In short, we hope this will really help out RetroArch’s video playback capabilities not only on desktops such as Windows and Linux, but also on the ARM SoCs, and in specific our own Linux distribution, Lakka.

But hardware video decoding is not the end-all-be all. There is certainly a lot of room for improvement for future speedups, and these are being investigated. But that’s the subject of another blog post somewhere down the line.

For now, rest assured that big things are coming up for the next version of RetroArch!