DirectX, OpenGL, Visual C++ Redist and many other support libraries in software programs typically require the same major version of the support libraries that they were shipped with.
For DirectX, that major version is 9, 10, 11, 12. Any major library change has to be recompiled into the game by the original developer. (Or a very VERY dedicated modder with solid low level knowledge)
Same goes for OpenGL, except I think they draw the line at the second number as well - 2.0, 3.0, 4.0, 4.1, 4.2, 4.3, 4.4.
For VC++, these versions come in years - typically you’ll see 2008, 2010, 2013, and the last version 2015-2022 is special. Programs written in the 2013 version or lower only require the latest version of that year to run. For the 2015-2022 library, they didn’t change the major version spec so any program requiring 2015+ can (usually) just use the latest version installed.
The one library that does weird things to this rule is DXVK and Intel’s older DX9-on-12. These are translation shim libraries that allow the application to speak DX9 etc and translate it on the fly to the commands of a much more modern library - Vulkan in the case of DXVK or DX12 in Intel’s case.
Edited to remove a reference to 9-on-12 that I think I had backwards.
I know I’m a bit late, but here is some more info that may be of use to some.
OpenGL/GLSL
OpenGL, is a set of “extensions” (currently 160 as of OpenGL 4.6), which is a subset of features that has to be implemented by each vendor/manufacturer driver.
To be considered compliant with OpenGL 4.0, you have to implement all its extensions. This base serves as the first stepping toward the next step, OpenGL 4.1, which is basically 4.0 with some more extensions, and so on untill the current OpenGL 4.6.
But as everything in OpenGL 4.0 is also in OpenGL 4.6, a driver for 4.6 will run any 4.0 games. But if you used an extension found in the 4.3 spec, your game won’t work on a 4.2 level driver… Well, most of the time, as it may already have implemented the extension you need, but did not implement yet enough of them to reach the 4.3 specs.
To complicate things even further, you have the cut-to-size versions, aka OpenGL ES, which targets embedded devices with a stripped down version of OpenGL.
As an example of this, you can find here the compatibility matrix for the open-source Mesa collection of drivers : https://mesamatrix.net/
DirectX
DirectX, in contrary, is a monolithic spécification. You either support DX11, or you don’t.
Part of it is implemented in the NT kernel (Linux équivalent in Windows) by MS, through its libraries, and the other is implemented by the GPU manufacturer, in their drivers.
DX version are often tied to Windows versions (DX12 with Windows 11), for multiple reasons. It requires the right features available in the NT kernel, the right hardware to be run, and, lets be honest, it is a great sale argument to try to push users to get the latest Windows version. Same goes with hardware manufacturers, it is a great way to make sure your customers upgrade for a GPU that support the latest DX version.
Subsequent versions are not compatible with each other, that’s why, if you play a DX9 game, you have to install the correct driver that (still) supports DX9, and the DX9 libraries.
To convert or not to convert to new API version ?
To convert a game from DX9 to DX10, you have to rewrite part of the underlying engine, which mean putting ressources and money into it.
Most publisher won’t bother, as the return on investment isn’t good enough to motivate such work. The new features won’t be used, and even though it usually give a substantial boost to performance, those games are often old enough to work exceptionally well on the current era hardware anyway.
So, once again, why bother ?
The specific case of DX12 (and Vulkan)
DX12 is to DX11 what Vulkan is to OpenGL. Both are a dramatic philosophical shift in the graphical API world. Previously, graphical APIs where at a higher level in the stack, which reduced their complexity, at the cost of bigger overhead.
Now with those two new beasts, you get a lot lower in the stack, which mean a lot closer to the hardware itself. You loose some of the ease of use in exchange for a lot less overhead, and thus potentially better performances.
But if your game worked on previous APIs, your are out of luck, as the changes are so radical you’d probably have to rewrite the whole engine renderer. It cost a lot, so only very few games goes this way, mostly the very successful ones, and probably mostly to gain experience with those new paradigms before starting to go all DX12/Vulkan for future games.
Thanks! I learned something new today, and that makes today a good day. I’ll strike out a few relevant parts of my answer when I get a minute to open the beast.
DirectX, OpenGL, Visual C++ Redist and many other support libraries in software programs typically require the same major version of the support libraries that they were shipped with.
For DirectX, that major version is 9, 10, 11, 12. Any major library change has to be recompiled into the game by the original developer. (Or a very VERY dedicated modder with solid low level knowledge)
Same goes for OpenGL, except I think they draw the line at the second number as well - 2.0, 3.0, 4.0, 4.1, 4.2, 4.3, 4.4.
For VC++, these versions come in years - typically you’ll see 2008, 2010, 2013, and the last version 2015-2022 is special. Programs written in the 2013 version or lower only require the latest version of that year to run. For the 2015-2022 library, they didn’t change the major version spec so any program requiring 2015+ can (usually) just use the latest version installed.
The one library that does weird things to this rule is DXVK and Intel’s older DX9-on-12. These are translation shim libraries that allow the application to speak DX9 etc and translate it on the fly to the commands of a much more modern library - Vulkan in the case of DXVK or DX12 in Intel’s case.
Edited to remove a reference to 9-on-12 that I think I had backwards.
I know I’m a bit late, but here is some more info that may be of use to some.
OpenGL/GLSL
OpenGL, is a set of “extensions” (currently 160 as of OpenGL 4.6), which is a subset of features that has to be implemented by each vendor/manufacturer driver.
To be considered compliant with OpenGL 4.0, you have to implement all its extensions. This base serves as the first stepping toward the next step, OpenGL 4.1, which is basically 4.0 with some more extensions, and so on untill the current OpenGL 4.6.
But as everything in OpenGL 4.0 is also in OpenGL 4.6, a driver for 4.6 will run any 4.0 games. But if you used an extension found in the 4.3 spec, your game won’t work on a 4.2 level driver… Well, most of the time, as it may already have implemented the extension you need, but did not implement yet enough of them to reach the 4.3 specs.
To complicate things even further, you have the cut-to-size versions, aka OpenGL ES, which targets embedded devices with a stripped down version of OpenGL.
As an example of this, you can find here the compatibility matrix for the open-source Mesa collection of drivers : https://mesamatrix.net/
DirectX
DirectX, in contrary, is a monolithic spécification. You either support DX11, or you don’t.
Part of it is implemented in the NT kernel (Linux équivalent in Windows) by MS, through its libraries, and the other is implemented by the GPU manufacturer, in their drivers.
DX version are often tied to Windows versions (DX12 with Windows 11), for multiple reasons. It requires the right features available in the NT kernel, the right hardware to be run, and, lets be honest, it is a great sale argument to try to push users to get the latest Windows version. Same goes with hardware manufacturers, it is a great way to make sure your customers upgrade for a GPU that support the latest DX version.
Subsequent versions are not compatible with each other, that’s why, if you play a DX9 game, you have to install the correct driver that (still) supports DX9, and the DX9 libraries.
To convert or not to convert to new API version ?
To convert a game from DX9 to DX10, you have to rewrite part of the underlying engine, which mean putting ressources and money into it.
Most publisher won’t bother, as the return on investment isn’t good enough to motivate such work. The new features won’t be used, and even though it usually give a substantial boost to performance, those games are often old enough to work exceptionally well on the current era hardware anyway.
So, once again, why bother ?
The specific case of DX12 (and Vulkan)
DX12 is to DX11 what Vulkan is to OpenGL. Both are a dramatic philosophical shift in the graphical API world. Previously, graphical APIs where at a higher level in the stack, which reduced their complexity, at the cost of bigger overhead.
Now with those two new beasts, you get a lot lower in the stack, which mean a lot closer to the hardware itself. You loose some of the ease of use in exchange for a lot less overhead, and thus potentially better performances.
But if your game worked on previous APIs, your are out of luck, as the changes are so radical you’d probably have to rewrite the whole engine renderer. It cost a lot, so only very few games goes this way, mostly the very successful ones, and probably mostly to gain experience with those new paradigms before starting to go all DX12/Vulkan for future games.
Thanks! I learned something new today, and that makes today a good day. I’ll strike out a few relevant parts of my answer when I get a minute to open the beast.