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 -> Latency and/or Quick Menu – Latency.

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.

This feature is enabled for the Windows, Linux, macOS, Android, iOS, PlayStation3, Xbox OG, Wii and WiiU versions.

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 –

ChaiLove – Another Take on 2D Game Development

Whale from the Love2D logoWhen it comes to 2D game development frameworks, there are many options out there for indie game developers. Every framework has its own pros and cons, and its own use cases. Today, let’s talk about LÖVE, baby.

LÖVE is an awesome framework to make 2D games in Lua. With some modification, these games can be brought to libretro though Lutro. With the advent of C++14, are there tools and features we can bring in to improve the scripting experience behind developing 2D games?

Love2D ChaiScript ChaiLove

Continue reading “ChaiLove – Another Take on 2D Game Development”