Site icon Libretro

Development Plan – March 13, 2023

A new concept we’re going to try, we’ll see if it lasts. Expect irregular blog posts like this, whenever something is on our mind that we want to share. It’s basically like a development diary where we discuss future plans for upcoming versions and what we have been thinking about doing.

Raising the lowest common denominator

RetroArch pushes the concept of backwards compatibility to an absolute extreme. It’s one of our definite pet peeves and something we’re quite proud of. The degree to which we push this is quite irregular in the modern day software industry but we believe it differentiates us from the rest of the pack, and in a good way.

That being the case, recently we believe that in order to improve the out of the box enduser experience, it is perhaps necessary to start making some general baseline assumptions on what endusers realistically are using in terms of hardware. Let’s explain what is behind this idea.

The Steam Mac version was a good opportunity for us to establish some minimum baseline system requirements to make sure that RetroArch on Mac would run well out of the box.

We provide two macOS versions right now (because we are as ever all about being backwards compatible):

Steam on macOS requires you to have at least macOS El Capitan (10.11) installed or later. It does not support anything lower. This meant that we could go with our Metal/GL universal build that targets macOS High Sierra (10.13). In doing so, we could reasonably assume that the Macs capable of running this OS should have at least a GPU with support for the Metal 2 graphics API. This allows us to just set the default video driver to Vulkan, which should guarantee a high level of performance and also compatibility with cores that provide a Vulkan hardware context.

The current Vulkan MoltenVK implementation in RetroArch Mac is actually quite a bit faster than the native Metal video driver right now. Perhaps it hits more optimal codepaths in the MoltenVK implementation because the Vulkan video driver is more well optimized than the Metal one. This is all of course speculation. Other nice things that came out of the Vulkan driver being supported on Mac is that we provide HDR support now on Mac for the Vulkan driver.

Anyway, onto the point. Currently, there are 5 different Windows versions.

Right now, all these versions (except for the UWP version, which has ‘d3d11’ as the default) fallback by default to the ‘gl’ video driver. ‘gl’ is the first OpenGL-based video driver that was written for SSNES/RetroArch. It targets OpenGL 2.x on the desktop and OpenGLES 2 for mobile, and it can use the (now considered deprecated) ‘glsl’ shader spec.

There are several problems with defaulting to ‘gl’ by default:

Defaulting to ‘gl1’ by default would be most ‘compatible’ but it’d really severely limit the out of the box featureset that the general user can use, so this is simply not a good option.

We therefore had the following idea: we can assume that the ‘main version’ is going to run on at least Windows 7 and later, because MSYS2/Mingw-w64 versions as of now only targets Windows 7 as a minimum OS. Therefore, we can raise the lowest common denominator a bit. We can reasonably assume that a system running Windows 7 has at least a DirectX11-class GPU. Therefore, the ‘main’ Windows version from now on will start defaulting from ‘gl’ to ‘d3d11’. This has various benefits:

Do note, that compatibility with cores that rely on OpenGL will not be an issue, because RetroArch has the ‘auto switch video driver per core’ enabled by default. So you won’t lose anything in the process when you need to start up a core that requires OpenGL.

We believe that in making this change, the default out of the box experience for a new user starting RetroArch for the first time will be much better. The few users that will encounter difficulties because their GPU does not meet the DirectX 11 requirements could force the video driver to ‘d3d10’ manually by simply editing retroarch.cfg, but we don’t expect there to be many. We figure that the people who would have problems with ‘d3d11’ would have the same issues with ‘gl’ regardless.

It’s always good of course to cast a very wide net when it comes to hardware backwards compatibility, but considering DirectX 11 was released in 2009/2010, we can consider that people running a main build targeting at least Windows 7 should at least have a GPU that can support a 13-year old graphics API.

The next step in defaulting to some more practical default settings for modernday hardware is probably going to be defaulting to XAudio 2.8 / 2.9 for the main Windows build. Right now we use XAudio 2.7. The benefit of XAudio 2.7 is that it is the most backwards compatible way of implementing XAudio2. However, it requires you to install the old deprecated DirectX 9 SDK, which doesnt come installed by default on modern Windows versions. Windows 8 started providing XAudio 2.8 DLLs by default, and Windows 10 started providing XAudio 2.9 DLLs by default. So what we are going to do probably at startup is determine if we are running Windows 8 or higher, and if so, try to use XAudio 2.9 first. If it doesn’t succeed, try XAudio 2.8. We will have to create at least a second new Xaudio driver for this, so that we retain backwards compatibility for Windows 7 and older OSes. They will have to resort to XAudio 2.7 still.

Do note that all Windows versions prior to Windows 7 will continue to work as expected. We are mainly talking here about the main MSYS2/Mingw-w64 build, which has Windows 7 as a minimum OS.

Also, don’t be concerned, you will still be able to use the OpenGL and Vulkan drivers, or even Direct3D 10 or 12. We are only talking here about the ‘video driver’ which is going to be used at first startup.

Exit mobile version