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):

• Main version is the High Sierra build (10.13 and later). We also call this the Metal/GL universal build. This build has OpenGL, Metal and Vulkan/MoltenVK drivers, it has slang shader spec support, and is generally considered the most full-featured build.
• Second version is the Lion (10.7 and later) version. This is a more pared-back, stripped-down version. It provides OpenGL (3.2 core context) support (because Lion was the first macOS version to support OpenGL 3.2 and higher). It does not provide Vulkan or Metal driver support because of the minimum OS requirement.
• Well, technically, there is a third version. This is a PowerPC version targeting macOS/OSX 10.5. It has OpenGL (up to 2.x) support. This build is not provided by our buildbot right now as our buildbot infrastructure lacks the development tools to build it. It might be introduced at a later undisclosed date.

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.

• Main version – compiled with MSYS2/Mingw. We consider this the Windows 11/10/8/7 version. This is the most full-featured build. It has Vulkan/OpenGL/D3D11/D3D12/D3D10/D3D9 video driver support, it has slang shader support, it has a builtin ffmpeg core, and it has the Qt5-based desktop UI builtin.
• 2nd version – the UWP version, compiled with either Visual Studio 2017, 2019 or 2022. The UWP (Universal Windows App) build is more feature limited than the regular Windows build, but it does have Direct3D 11/12 support and slang support. It does not have Vulkan video driver support. OpenGL support is dependent on ANGLE and is spotty, it is used by cores as a last resort when a Direct3D 11 renderer is not available instead. The UWP app can be used on Windows 8/10/11, and Xbox One/Series consoles.
• 3th version – Windows Vista/XP build, compiled with Visual Studio 2010. Features are more limited than the main version. Other limiting factors: because Visual Studio 2010 has partial/incomplete C++11 language support (called C++0x at the time), this version does not have the Vulkan video driver or slang support (the latter relies on SPIRV-Cross/GLSLang, both C++11 code). The Windows Vista/XP build does have Direct3D 9 and OpenGL (2.x) support.
• 4th version – Windows 2000 / ME / 98SE build, compiled with Visual Studio 2005. This version is even more stripped back than the Windows Vista/XP build, but sacrifices are necessary so that we can target these obsolete/ancient OSes. Other limiting factors in terms of featureset is of course the complete lack of C++11/C++0x language support in Visual Studio 2005.
• 5th version – Windows 98 / 95 build, compiled with Visual Studio 2003. This is the most pared back version of them all. We currently haven’t provided any builds of this version since 2020 since our current buildbot infrastructure lacks a Visual Studio 2003 compiler. Maybe it will come back one day.

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:

• There are now more modern OpenGL drivers in RetroArch, such as ‘glcore’, which targets OpenGL 3.2 Core and higher.
• Spotty OpenGL driver support for some video cards/GPUs. OpenGL support on Windows for vendors is often an afterthought. The most egregious example is probably Intel for some of their iGPUs, where the only OpenGL version supported is ancient OpenGL 1.1 (literally late ’90s). This means that you have to resort to ‘gl1’ and lose a ton of features that you’d have access to with ‘gl’ or ‘glcore’.
• Direct3D support can generally be assumed to be better for most video cards/GPUs compared to OpenGL. Especially the case for AMD and Intel.

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:

• HDR support out of the box
• Better compatibility with most GPUs
• Slang shader support, the cross-GPU shader spec that we want everyone to use (instead of deprecated glsl spec)

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.