RetroArch 1.7.2 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.

Highlights

Runahead latency reduction – better latency than the real hardware

This might just be our biggest release yet, thanks in no small part to the new runahead latency reduction system. This feature has already been all the rage over the Internet. Well known people like Durante of DSfix fame praised it and the popular site Ars Technica has dedicated an entire article to this game-changing feature.

We ran an article on this new feature before, and since then, several facts have changed on the ground which bears pointing out. First of all, several performance improvements have been made since. Secondly, the feature has now been enabled for the vast majority of the RetroArch platform ports.

The versions that have this feature enabled and exposed now includes:

Wii

WiiU

Nintendo Switch

Android

PC (Windows)

PC (Linux)

macOS

iOS

Here are some basic things you should know:

Every game has a certain built-in amount of lag frames. In order for the runahead system to perform as expected, you should set it to the same amount of frames to read ahead that the game you’re running is working by. So, for example, if a game like Super Mario World for the SNES has a guaranteed 2 frame input lag, for the best results, set Runahead frames to 2.

You can count the amount of lag frames a game has by using the frame advance feature in RetroArch.

You can count the amount of lag frames a game has by using the frame advance feature in RetroArch. For playable performance, your system should be at least capable of running the core at twice its regular speed. These performance demands go up commensurate to the amount of frames you want to run ahead. The higher performance you get with a core, the more frames you can run ahead at fullspeed.

While the runahead system is core agnostic and therefore technically we don’t need to patch up cores in order to work with the runahead system, there are several things that can be done in order to improve performance considerably. To this end, Dwedit has submitted several patches to some of the cores in order to make them perform much better. Some of these cores include (but are not limited to) the Snes9x cores, QuickNES, FCEUmm, Nestopia, Gambatte, and even Mednafen/Beetle PSX.

There are currently some things you should know about Mednafen/Beetle PSX when it comes to runahead. First of all, in order for this core to work correctly with runahead, you should use the software renderer. The OpenGL and Vulkan renderers are currently buggy with runahead. Second, even after several savestate performance improvements, it is unlikely you will be able to set runahead to higher than 1 frame while still being able to run at fullspeed. This might likely change once our bounty for the Beetle PSX dynarec is finally fulfilled (and on that note, it has already reached $720, and a coder is working on a potential solution)

An often heard question that has been asked is – will this work on a Raspberry Pi? There is no straight answer to this since it heavily depends on the core’s performance. Based on our performance tests on the PS3 and Xbox OG, QuickNES and Gambatte should be at least two cores that should run at fullspeed with runahead set to 6 frames or less. Your mileage may vary on any of the other cores. The quick rule of thumb is that the faster the core, the higher chance there is to get it to run at fullspeed with more runahead frames.

How to check the amount of lag frames a game has

RetroArch has the ability to pause a core and advance it frame by frame. Perform the following steps to determine the amount of lag frames of a game:

Pause emulation (press ‘p’ button on keyboard).

Press and hold the jump button on the controller.

Advance emulation frame by frame (press ‘k’ button on keyboard) until the character jumps.

The number of k presses before you get a reaction should be the number of lag frames you can safely remove with run ahead.

Performance, scalability

So, how well does all this scale? Of course, the more expensive hardware you throw at a latency reduction approach like this the better, but how low can we actually go in terms of specs and still obtain good results? To figure out a basic answer to this question, I decided to test the runahead system on two old game consoles that are not exactly powerhouses at this point. The first of the lot is the Xbox OG, powered by a fairly mundane Pentium 3/Celeron 733MHz CPU. The second is the PlayStation3. Its PPU is roughly equivalent to a Pentium 4 2.4GHz CPU in terms of real-world performance, and even that comparison is probably pushing it. So this is not exactly powerful hardware.

Street Fighter Alpha 3 FBAlpha 2012 No runahead 104fps PS3 Street Fighter Alpha 3 FBAlpha 2012 Runahead – 1 frame 57fps PS3 Mega Man 2 QuickNES No runahead 124fps PS3 Mega Man 2 QuickNES runahead – 1 to 6 frames 124fps PS3 Mega Man 2 Nestopia No runahead 124fps PS3 Mega Man 2 Nestopia Runahead – 1 frame 76fps PS3 Mega Man 2 Nestopia Runahead – 2 frames 54fps PS3 Super Mario World Snes9x 2010 No runahead 113fps PS3 Super Mario World Snes9x 2010 Runahead – 1 frame 78fps PS3 Super Mario World Snes9x 2010 Runahead – 2 frames 65fps PS3 Super Mario World Snes9x 2010 Runahead – 3 frames 56fps PS3 Sonic 1 Genesis Plus GX No runahead 116fps PS3 Sonic 1 Genesis Plus GX Runahead – 1 frame 51fps PS3 Bomberman 94 Mednafen PCE Fast No runahead 124fps PS3 Bomberman 94 Mednafen PCE Fast Runahead – 1 frame 83fps PS3 Bomberman 94 Mednafen PCE Fast Runahead – 2 frames 66fps PS3 Sonic 1 SMS Gearsystem No runahead 120fps PS3 Sonic 1 SMS Gearsystem Runahead – 1 frame 63fps PS3 Sonic 1 SMS Genesis Plus GX Runahead – 1 to 6 frames 124fps PS3 Mega Man 2 QuickNES Runahead – 1 to 6 frames Fullspeed Xbox OG Mega Man 2 FCEUMM Runahead – 1 frame Fullspeed Xbox OG Mega Man 2 FCEUMM Runahead – 2 frames Not fullspeed Xbox OG Sonic 2 Genesis Plus GX No runahead Fullspeed Xbox OG Sonic 2 Genesis Plus GX Runahead – 1 frame Not fullspeed Xbox OG

We consider any PC from the year 2005/2006 (whether desktop or laptop) to be significantly more powerful than either of those consoles, so these test results bode quite well for the scalability and feasibility of the runahead method.

Features like the runahead system will also naturally increase the demand for ever faster cores so that people on lower specced hardware can use runahead with more frames in advance.

CRT Switch Res – GroovyMAME-like features for 15KHz capable CRT monitors!

Thanks to forum-user Alphanu, RetroArch now has the ability to query cores for their exact video timing data, which can be used to switch to native-resolution, 15 kHz modelines for use with standard-definition CRT TVs.

This is a big step for retro purists, as RetroArch can now output “pixel-perfect” video with accurate timing to compatible displays, even quickly switching between interlaced and non-interlaced modes on the fly.

This capability is currently Windows-only and requires modelines to be created in advance by CRT_EmuDriver or Custom Resolution Utility with a compatible GPU. Linux support is coming soon.

In case you’d like to learn more, follow these links:

Direct3D improvements, additions, and a new Direct3D10 driver

With RetroArch 1.7.1, we really stepped our game up to finally start treating Windows as a first-class citizen platform. You have seen this in the form of dedicated Direct 3D 11/12 video drivers that had the ability to run the same shaders as Vulkan, our new slang shader spec that is made possible by the impressive Khronos/ARM-backed project SPIRV-Cross.

Increased backwards compatibility

Previously, the Direct3D 11 driver required that your graphics card driver supported at least Shader Model 5.0. We have since downgraded this requirement to Shader Model 4.0. As a result, I am now able to use the Direct3D 11 video driver on an old 2010 laptop GPU that only supports Shader Model 4.0 (it’s an ATI Mobility Radeon HD 4300). We also try to support more D3D11 feature levels instead of just defaulting to 11.0.

New Direct3D 10 video driver

On some systems, though, you won’t be able to make use of the Direct3D 11 driver no matter what. One of those systems happened to be another old laptop I had lying around here. This one has a Geforce 9200M GS, and the specs state that it supports up to Direct X 10 and Shader Model 4.0. Direct3D 11 is a no go on this GPU even with the increased backwards compatibility.

It’s for this purpose that me and aliaspider spent some time to finally make the Direct3D 10 driver feature-complete. Direct3D 10 should be available from Windows Vista and up, whereas Direct3D 11 is available from Windows 7 and up. The Direct 3D 10 driver should be feature complete and identical to the Direct3D 11 driver, with the sole exception of hardware rendering contexts not being available right now with Direct3D 10.

Which brings us to the last Direct3D-related subject…

Direct3D-powered libretro cores are now possible!

This feature is easily worth its own article, but since we already covered this before and because 1.7.2 has so many huge features, we will relegate this to a side note. Nevertheless, it is none the less important.

Up until now, if you wanted to use hardware-accelerated 3D rendering in a libretro core, your options were OpenGL and/or Vulkan. There is now a third option – Direct3D 11, and the first libretro core that supports this is the PPSSPP core!

With all these features, we now have everything in place to really do an UWP version of RetroArch justice.

Input remapping system improvements

The input remapping system (available from Quick Menu -> Controls) had many obvious limitations previously. Some of these included:

It was not possible to map keyboard from more than one gamepad (for instance with Dosbox)

It was not possible to map more than one button to the same action

It was not possible to unmap buttons or analogs

It was not possible to map a button to trigger an analog response (for instance, in an N64 emulator, running in Super Mario 64 with the D-pad)

It was not possible to map an analog to another analog

It was not possible to map an analog to produce a button response

Most of these restrictions have now been lifted at long last thanks to radius, and the visual representation is also much improved now.

To read more about this, also visit the related forum thread here.

Do note that all your existing remap files are now obsolete, and you should start from scratch. This was a necessary evil unfortunately in order to progress.

Various Quality-Of-Life improvements

We have tried to do various consequential Quality-of-Life improvements for this release: