RetroArch 1.7.2 — Achieving better latency than original hardware through new runahead method

Even though sub-frame latency in software emulators has been achieved, some developers kept pushing beyond, and found a way to surpass even real hardware in response time. We have Dwedit to thank for this particular method.

Most systems more complex than the Atari 2600 will display a reaction to input after one or two frames have already been shown. For example, Super Mario Bros on the NES always has one frame of input latency on real hardware. Super Mario World on SNES has two frames of latency.

The Libretro forum post linked above provided patches to RetroArch that can effectively “remove” this baked-in latency by running multiple instances of a core simultaneously, and quickly emulating multiple frames at a time if input changes.

This strategy has some analogs to frame rollback, similar to how GGPO handles high-lag connections. And in fact, if you set the “read ahead” frames on the experimental builds ridiculously high, you can get a feeling for what’s going on behind the scenes.

Here’s another article from a few years ago illustrating the basic concept.

Accurate? No way. Fascinating? You betcha. Mere “same latency as real hardware” is SO last month…

This feature has since been incorporated into RetroArch and will make its first proper debut in the upcoming RetroArch 1.7.2. Users who want to get a sneak peek at this feature can already experiment with it by downloading the latest nightly version of RetroArch, and downloading the latest version of the Snes9x core.

Once the game is running, go to Settings -> Frame Throttle.

The setting ‘Run-Ahead to Reduce Latency’ is what you want to enable. From there on out, you can specify the amount of frames that you want to run ahead. Be advised that how well this will work with the game in question will depend on the game’s built-in amount of lag frames, so experimentation is key here.

Be aware that this method is highly resource intensive. The higher the number of frames you are going to run ahead of emulation, the higher demands it places on your CPU. For instance, Snes9x on a Core i7 7700k CPU would normally run at 1500fps with Super Mario World. With runahead set to 2 frames, we get 440fps. With runahead set to 4 frames, it will be lowered even further to 250fps. So fast cores are key for making this latency reduction approach feasible.

Right now, we are going to be enabling this feature for the Windows, Linux, macOS, and Android versions. Console ports that depend on static linking won’t be able to take advantage of this feature.

We hope you will look forward to this feature and tons of other exciting changes that will be packed into RetroArch 1.7.2! Playing Super Mario World and other SNES games with their built-in 2/3 frames of latency removed is definitely a game changer and will hopefully breath fresh air into these old games.

If you would like a technical breakdown of this method, read this post here by Dwedit, the author of this method (incidentally, he also made PocketNES a long time ago, a NES emulator for the Game Boy Advance which was a big breakthrough back in its day).

Libretro API now supports experimental Direct3D11 hardware rendering!

We, as the developers of RetroArch and Libretro, are proud to announce that yet another new option is available to developers who are using the Libretro API. In addition to being able to use Vulkan and/or OpenGL for hardware rendering, you can now also use Direct3D 11 inside your cores!

While it should be noted that this is still in an experimental stage, there is already a core that will be taking advantage of this — the PPSSPP libretro core, which has recently been upstreamed thanks to Ali Bouhlel and Henrik Rydgard, the original developer. You will be able to use either Direct3D 11 (on Windows), OpenGL or Vulkan renderers with the PPSSPP core.

Some history –

Libretro as an API started out in 2010/2011 only allowing for software rendered graphics. This is truly platform and hardware-agnostic, and for most systems that do not use any kind of 3D rendering and have little to gain from moving over to hardware-accelerated graphics APIs this is the preferable strategy. However, because software rendering has to be handled by the CPU, is only really practical for older games/emulators emulating older 2D-based systems.

OpenGL hardware rendering was added as an option to the Libretro API back in 2013. This coincided with Android and iOS ports appearing for RetroArch, and this was before the platform holders all decided to go their own separate ways and start targeting their own APIs. So being able to target OpenGL (ES and non-ES) as a developer in your libretro core was a great and convenient way to make cross-platform code that would run on most platforms. The only requirements for using OpenGL in your core was that you would adhere to at least OpenGL 2.x on the desktop and/or OpenGL ES 2.0 on mobile. While fixed-function OpenGL was theoretically possible, we only ever provided a test core for it, and we had an unwritten agreement in general that OpenGL usage in Libretro cores should be non-fixed function.

In 2016, the next-generation Vulkan graphics API was launched, and nearly at the same day, RetroArch and Libretro as an API started supporting the Vulkan API. Later that year, new Vulkan renderers for two of our emulators, Beetle PSX and Parallel N64, were made. Since then, Vulkan support has been added to other libretro cores as well, such as PPSSPP and the Dolphin core.

Now in 2018, there is an additional third option available to developers — Direct3D11 support! Targeting this API will of course limit you to Windows 7 and later. However, there are valid reasons for targeting Direct3D 11. On some devices like the Surface Pros, OpenGL drivers are apparently notoriously bad and you need to use Direct3D rendering in order to get decent performance. To this day, users of AMD GPUs on Windows still complain about OpenGL renderers performing worse than their Direct3D equivalents. Whether this is deliberate through sabotage or it’s just circumstantial misfortune, there are legitimate reasons for targeting Direct3D 11 from a performance perspective, and since UWP supports D3D11 natively and using either Vulkan or OpenGL would only be possible through several abstraction layers, it is nice in our humble opinion that the option exists vs. it not existing at all.

We would of course much prefer that there was a real crossplatform graphics API that magically worked everywhere, had great performance everywhere, and that required somebody to just write a graphics renderer once. Unfortunately, industry powers for whatever reason never seem to want things to actually get too easy for developers, so until then, covering all our bases with the Libretro API and trying to support as many of the predominantly available graphics APIs as possible seems to be a more pragmatic decision.

And what’s more, thanks to the excellent SPIRV-Cross project, we are fast approaching a situation where the Direct 3D 11, Direct 3D 12, Vulkan and (maybe soon?) OpenGL drivers available in RetroArch will be capable of using the same shaders instead of each needing their own separate shaders.

See here a video of PPSSPP running with Direct3D11 on RetroArch –

RetroArch 1.7.1 -Released!

RetroArch 1.7.1 has just been released! Grab it here.

This latest version has also been uploaded to the Google Play Store.

If you’d like to show your support, consider donating to us. Check here in order to learn more.

General changelog

– 3DS: Now correctly reports amount of CPU cores.
– 3DS: Frontend rating is now correctly implemented for both New 3DS/2DS and Old 3DS/2DS.
– 3DS: Initial networking support, HTTP requests won’t work yet.
– 3DS: Now reports memory and battery state.
– AUDIO: Added ‘Audio Resampler Quality’ setting to Audio Settings. Setting this higher will increase sound quality at the expense of sound latency and/or performance. Setting this value lower will improve sound latency/performance at the expense of sound quality. Only has an effect if the Sinc resampler is used, and you have to restart the game for changes to take effect.
– CHEEVOS: Fix unofficial achievements not being loaded.
– CHEEVOS: Show savestate menu entries when no achievements are found even if hardcore mode is enabled.
– CHEEVOS: Support Neo Geo Pocket.
– COMMON: Bugfix for issue related to ‘Windows mouse pointer visible when running MESS or MAME cores’.
– COMMON: Fix bug ‘Last item in a Playlist is ignored’.
– COMMON: New LED API. Driver implemented for Raspberry Pi, proof of concept implemented for core MAME 2003.
– COMMON: Add quick menu option to watch shader files for changes and recompile them automatically (Linux only for now).
– D3D8: Direct3D 8 can now work on systems that have Direct3D 8 installed.
– D3D9: Add menu support for MaterialUI/XMB.
– D3D10: Initial video driver implementation.
– D3D11: Initial video driver implementation.
– D3D11: SPIRV-Cross/slang shader support for D3D11.
– D3D12: Initial video driver implementation.
– DINPUT: don’t reinitialize input driver on network events / media insertion / network drive connection
– INPUT: show friendly names when available under input binds and system information
– INPUT: show the config name when available under system information
– GUI: Allow changing menu font color.
– GUI: Menu visibility options for RGUI and MaterialUI.
– GUI/MaterialUI: Works now with D3D8, D3D9 Cg, D3D11 and D3D12 drivers.
– GUI/XMB: Add Monochrome Inverted icon theme.
– GUI/XMB: Allow changing menu scale to 200%.
– GUI/XMB: Works now with D3D8, D3D9 Cg, D3D11 and D3D12 drivers. Menu shader effects currently don’t work on D3D8/D3D9 Cg.
– HAIKU: Restored port.
– KEYMAPPER: prevent a condition that caused input_menu_toggle to stop working when a RETRO_DEVICE_KEYBOARD type device is enabled
– GL: ignore hard gpu sync when fast-forwarding
– IOS10/11: Handle hardware keyboards and iCade controllers
– LOCALIZATION: Update Italian translation.
– LOCALIZATION: Update Japanese translation.
– LOCALIZATION: Update Portuguese-Brazilian translation.
– LOCALIZATION: Update Spanish translation.
– NETPLAY: Add menu option to select different MITM (relay) server locations.
– OSX: Modify HID buttons detection algorithm.
– QB: Added –datarootdir.
– QB: Added –bindir and –mandir and deprecated –with-bin_dir and –with-man_dir.
– QB: Added –docdir.
– SHADERS: Allow saving of shader presets based on the parent directory (Saving one for */foo/bar/mario.sfc* would result in *shaders/presets/corename/bar.ext*). We decided it’s safer to still isolate the presets to a single core because different cores may treat video output differently.
– SHADERS: Don’t save the path to the current preset to the main config. This was causing weird behavior, instead it will try to load *currentconfig.ext* and it will save a preset with that name when select *apply shader preset*. The resulting shader will restore properly after restarting and even after core/parent/game specific presets are loaded
– SOLARIS: Initial port.
– SWITCH: Initial Nintendo Switch port, based on libtransistor SDK.
– PS3: Enable Cheevos.
– PSP: Enable threading support through pthreads.
– SHADERS: SPIRV-Cross/slang shader support for D3D11.
– SHIELD ATV: Allow the remote / gamepad takeover hack to work with the 2017 gamepad
– SUBSYSTEM: Subsystem saves now respect the save directory
– SUBSYSTEM: You can now load subsystem games from the menu (see https://github.com/libretro/RetroArch/pull/6282 for caveats)
– VULKAN: Fix swapchain recreation bug on Nvidia GPUs with Windows 10 (resolved in Windows Nvidia driver version 390.77).
– WINDOWS: Improved Unicode support (for cores/directory creation and 7zip archives).
– WINDOWS: Show progress meter on taskbar for downloads (Windows 7 and up).
– WINDOWS: WS_EX_LAYERED drastically decreases performance, so only set it when needed (transparency in windowed mode).
– WIIU: Overlay support.
– WIIU: Transparency support in menu + overlays.
– WIIU: Increased stability during core switching.
– WIIU: Shader support.
– WIIU: Menu shader effects added (shaders).
– WIIU: Add missing time/clock support. (also fixes RTC [Real Time Clock] in Gambatte)
– XBOX OG: Restored port.

Highlights

New Direct3D 11/12 driver

RetroArch 1.7.1 now features very robust and feature-complete Direct3D 11/12 drivers for Windows users! Direct3D 11 should be available to users starting as of Windows 7, whereas in order to use Direct3D 12, you need Windows 10.

See here the following features:

  • Supports Slang shaders, the same shader format that Vulkan uses
  • Suports the menu; supports MaterialUI and XMB.
  • Supports overlays.
  • All menu shader effects have been ported.

Do note that right now, it is recommended you use the Direct3D11 driver instead of Direct3D 12. D3D11 is many times faster than D3D12, and while there are still gains to be had, we are not necessarily sure if the D3D12 driver will ever be able to outperform the D3D11 driver.

The Direct 3D 11/12 video drivers should work with any libretro core that does not require either OpenGL or Vulkan to function.

Some minor features which are currently not available is features like Max swapchain image control, GPU Hard Sync and/or Black Frame Insertion.

Emscripten/Web Player back in action and better than ever

Toad King has graciously not only restored the Web Player, but made it better than ever.

Now using WebAssembly under the hood, not only is it a lot faster, but it also now has the XMB menu by default and should work properly with builtin gamepad support from your browser.

You can find the Web Player here. You can also reach the Web Player at any time by going to retroarch.com and clicking on ‘Web Player’ in the topright hand part of the site.

Xbox port back from the dead

People always keep insisting that us supporting ancient compilers like Microsoft Visual Studio 2003 is pointless. Well, in this case it allowed for the long-dormant RetroArch Xbox OG version to be resurrected rather effortlessly. And we were able to write a Direct3D 8 video driver as well which works for both PC as well as Xbox OG.

The Xbox OG port is now more in lock-step with official mainline than ever. It no longer uses some proprietary hokey menu system but it just uses RGUI as the default. I could have included XMB as well, but we still have some work left to do in terms of making sure we can render text with Direct3D8 instead of relying on D3DX, and there were still some texture-related UV issues, so that factored into our decision to only go with RGUI for now.

Right out of the gate, there are 21 cores available for the Xbox version, far more than in any other time period of its lifecycle.

Other noteworthy features – it now supports overlays.

Subsystem support – Game Boy 2-player Link, Super Game Boy support with SNES emulators, etc

This feature allows cores to specify a subsystem, which may be a different system like in this video, or an add-on (think Super Gameboy / Genesis lock on).

Previously, cores that supported subsystems (think Super Game Boy / Sufami Turbo with SNES9x emulators) needed to be started from the commandline in order to be able to use Super Game Boy/Sufami Turbo mode.

The following cores should already have subsystem support:

  • Same Boy (allows for up to 2-Link netplayer)
  • bSNES (Super Game Boy and Sufami support should work through the menu)

NOTE: You need to set the Filebrowser Directory to your starting point directory if you want to use the subsystem feature. It will not work properly without.

Universal shader spec gaining steam – Vulkan/D3D11/D3D12/WiiU all using the same shaders now

There are several video drivers now that all make use of the same universal shader format, Slang:

  • Vulkan
  • Direct3D11
  • Direct3D12
  • WiiU

What this means is that all these video drivers are able to use the same shader format without having to convert from one format to another. The magic happens courtesy of SPIRV-Cross, itself a Khronos project.

We hope that in the future, the slang shader spec will be supported by most of RetroArch’s video drivers (such as OpenGL and the other Direct3D drivers). This represents a very important step towards realizing that ultimate goal.

Veteran RetroArch users will probably remember that we first tied our wagon to Nvidia’s Cg shader format. As that spec gradually fell out of favor and even Nvidia abandoned it wholesale, it was for a time uncertain for us which new format we would have to go with. You had GLSL on mobile and desktop GL, and HLSL for Direct3D. Now, with SPIRV-Cross, we finally have an exit strategy for the increasingly deprecating Cg ecosystem of shaders.

That being said, we still intend to continue supporting Cg and the shader system, and platforms like PlayStation3 and Xbox 360 wholly depend on it in fact.

WiiU port vastly improved

The WiiU port has been significantly improved upon in many ways.

  • Overlay support.
  • Transparency support in menu + overlays.
  • Increased stability during core switching.
  • Shader support (slang).
  • Menu shader effects added (shaders).

There are shaders out in the wild as add-on packs. Shaders are not compiled at runtime, unlike on PS3.

Switch port

OK, so we can’t roll a public release out for this one yet since it still relies on baking in the content through squashfs. However, the Switch homebrew is recently heating up with the release of the Homebrew Launcher, and also competing SDKs like Libnx.

However, we hope that by the time 1.7.2 comes out, we will have something in a ready-made fashion available to all.

Configurable audio resampling

While RetroArch is also well set to deliver a latency experience almost on par with the actual hardware under the best circumstances, it also continues to help people find new solutions to their one core common problem – latency.

If you are using the Sinc resampler, you can set the quality of the resampling by going to Settings -> Audio and adjusting ‘Audio Resampler Quality’. The highest settings will produce the best possible sound quality at the expense of performance and/or latency, while the reverse is true by setting it to one of the lower values.

What’s coming next for RetroArch

We will have a separate blog post on this soon, as well as more separate blog articles detailing some of the other progress that has been made on the cores front.