Anyone else had this issue? I mean why the game doesn’t support directx 12

  • KoboldCoterie@pawb.social
    link
    fedilink
    English
    arrow-up
    32
    ·
    2 months ago

    GTA4 is 16 years old at this point. Why would you expect it to support DirectX12, which is 7 years newer than the game?

        • over_clox@lemmy.world
          link
          fedilink
          English
          arrow-up
          1
          ·
          2 months ago

          Guess not, but as far as I ever knew, M$ has been known to try to maintain backwards compatibility for longer than most users would even consider necessary.

          XP supported DirectX 7/8/9

          I would have figured that would have continued on with future versions of Windows, but I guess Satya Nadella decided to scrap backwards compatibility.

          Oh well, all the more reason I switched to Linux as my main daily runner after Windows 8 came out. 🤷‍♂️

          • FeelzGoodMan420@eviltoast.org
            link
            fedilink
            English
            arrow-up
            7
            ·
            edit-2
            2 months ago

            But it IS backwards compatible in the way you are describing. You can play a dx9 game on windows 11. So it is backwards compatible. What you cannot do (usually) is force a game built with dx9 features to use dx11/12 features. If the game wasn’t built with new API features (because it released before those features even existed) then you cannot expect it to be able to just “be dx12” all of a sudden.

      • computergeek125@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        edit-2
        2 months ago

        DirectX 12 was released in 2015 with Windows 10, so it’s unlikely to have been ported back to 8.1 and lower.

        MS usually only does current+ with compatibility - so for example FF11 (DirectX 8.1 I think) still works (mostly) on Windows 11, but DX12 won’t work on W7

        • over_clox@lemmy.world
          link
          fedilink
          English
          arrow-up
          2
          ·
          2 months ago

          I wasn’t suggesting that I’d expect newer DirectX to work on older versions of Windows. I was suggesting that I would have expected newer DirectX standards to still be backwards compatible with older DirectX standards.

          Sigh, I guess Satya Nadella decided to scrap backwards compatibility. Oh well, I switched to Linux after Windows 8 came out anyways. 🤷‍♂️

          • computergeek125@lemmy.world
            link
            fedilink
            English
            arrow-up
            6
            ·
            edit-2
            2 months ago

            I mean… DX 9, 10, and 11 were all released prior to Nadella being CEO/chairman.

            But in software, it’s very commonplace for library versions not to be backwards compatible without recompiling the software. This isn’t the same thing as being able to open a word doc last saved on a floppy disk in 1997 on Word 365 2024 version, this is about loading executable code. Even core libraries in Linux (like OpenSSL and ncurses) respect this same schema, and more strongly than MS.

            Using OpenSSL as an example, RHEL 7 provides an interface to OpenSSL 1.0. But 1.1 is not available in the core OS, you’d have to install it separately. 1.1 was introduced to the core in RHEL 8, with a compatibility library on a separate package to support 1.0 packages that hadn’t been recompiled against 1.1 yet. In RHEL 9, the same was true of OpenSSL 3 - a compatibility library for 1.1, and 1.0 support fully dropped from core. So no matter which version you use, you still have to install the right library package. That library package will then also have to work on your version of libc - which is often reasonably wide, but it has it limits just the same.

            Edit because I forgot a sentence in the last paragraph - like DirectX, VC++, and OpenGL, you have to match the version of ncurses, OpenSSL, etc exactly to the major (and often the minor) version or else the executable won’t load up and will generate a linking error. Even if you did mangle the binary code to link it, you’d still end up with data corruption or crashes because the library versions are too different to operate.

  • computergeek125@lemmy.world
    link
    fedilink
    English
    arrow-up
    13
    ·
    edit-2
    2 months ago

    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.

    • Dremor@lemmy.worldM
      link
      fedilink
      English
      arrow-up
      3
      ·
      edit-2
      2 months ago

      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.

      • computergeek125@lemmy.world
        link
        fedilink
        English
        arrow-up
        2
        ·
        edit-2
        2 months ago

        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.

  • FeelzGoodMan420@eviltoast.org
    link
    fedilink
    English
    arrow-up
    3
    ·
    edit-2
    2 months ago

    If you can force Vulkan, you can use DXVK to get it to support DX11 features. Might be a pain in the ass to get it to work though. Not even sure if GTA4 will run on Vulkan.