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 : 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.
Why is nobody competing with them? It doesn’t seem like a hard type of game to make, and they’re doing such a terrible job that it should be easy to compete with them.
The fact that there aren’t many alternatives likely means that making a Sims-like game isn’t as simple as it looks. That being said, there are a bunch of life sims under developement right now (probably because EA is doing a terrible job) such as Paralives, Inzoi and Alterlife.
Just a heads up, Alterlife likely never got off the ground. They mocked up a demo video with store assets 3 years ago, but were never heard from again. I still have it on my wishlist, but my hopes are not up, lol.
As a PC player, I’m glad our hardware cousins get to play 1.6 - it’s a good update and ConcernedApe again going above and beyond. What I’m most excited for though is that this may mean Haunted Chocolatier gets back into development. Fields of Mistria did a good job scratching the itch before I ran out of Early Access content, but I’m really looking forward to seeing what Barrone comes up with in his next game
I don’t think ConcernedApe does the console and mobile versions, I would assume he got back to Haunted Chocolatier after 1.6 dropped on PC. Pretty sure he licenses the porting process.
If you can force Vulkan, you cna use DXVK to get it to support DX12 features. Might be a pain in the ass to get it to work though. Not even sure if GTA4 will run on Vulks .
I recently was holding out hope for a franchise that was similarly treated. I can tell you from experience that Sims 5 will make a billion dollars and they will then fire all the programmers who made it.
no, that’s the problem, there won’t be a new Sims game. Sims 4 has been a zombie of a Sims game since it came out 10 years ago and EA just announced that they’re more than happy to let it’s corpse shuffle around for the foreseeable future, rather than make a Sims 5 that people actually like.
I love the type of gameplay that the Sims (specifically building and character creation, other stuff is boring af) has but it sucks so much to play because it’s so limited unless you spend thousands on all the dlc. I am a game dev (well, I call myself that but I’ve never released anything cuz I’m too busy with finishing up college rn) and I really want to make a life sim game one day. I’ve seen plenty of indie life sims fail unfortunately, but I’m still going to try anyways. I have a few ideas I haven’t seen anyone else do. So many of these games fail that I’m not afraid to try something a bit crazy and hope it sticks.
I go the other way. When AA/AAA batteries are too weak for high drain devices, I save them for my remote controls. They usually last for months due to the intermittent use and low wattage.
Will Wright! We need you, now more than ever! We need simulation games! We need llamas! We need a great vision of weird fun you can have! Will Wright is…Will Wright is apparently busy with an AI powered game that looks extremely vaporware. Nooooo…
bin.pol.social
Najstarsze