Announcement

Collapse
No announcement yet.

sdl12-compat 1.2.54 Pre-Release Gets More Games Running On This SDL2 Compatibility Layer

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by oiaohm View Post

    That mistake. API compatible is required.
    https://github.com/libsdl-org/SDL/bl...ADME-dynapi.md

    Issue here is there are SDL1 and SDL2 games that static link SDL1 SDL2 into themselves. Its the SDL2 and later that can use SDL_DYNAMIC_API​ in the static case to force a new SDL version. SDL1 if static linked to use sdl12-compat is rebuild.

    Also this sdl12-compat is being used with open source games so API compadible is important as well.

    So both ABI and ABI compatible is required.
    Is it e​ve​n possible​ to be​ ABI-compatible​ without also be​ing API-compatible​. Hmm, maybe​ it is but it se​e​ms like​ e​xtra e​ffort.

    Comment


    • #12
      Originally posted by nanonyme View Post

      Is it e​ve​n possible​ to be​ ABI-compatible​ without also be​ing API-compatible​. Hmm, maybe​ it is but it se​e​ms like​ e​xtra e​ffort.
      Exactly. I wasn't saying API compatibility is not important too, but ABI compatibility generally implies API compatibility. I also get the impression that porting from SDL1 to SDL2 isn't that hard either.

      Comment


      • #13
        Originally posted by nanonyme View Post
        Is it e​ve​n possible​ to be​ ABI-compatible​ without also be​ing API-compatible​. Hmm, maybe​ it is but it se​e​ms like​ e​xtra e​ffort.
        Originally posted by Chewi View Post
        Exactly. I wasn't saying API compatibility is not important too, but ABI compatibility generally implies API compatibility. I also get the impression that porting from SDL1 to SDL2 isn't that hard either.
        It is possible to be ABI compatible without being API compatible. Like API macros and other things need in the source build from headers have to exactly match up.

        API(Application Programing Interface) has different compatibility requirements than ABI(Application binary interface).

        Porting from SDL1 to SDL2 does result in lot of code base testing.

        Yes lot of people have the idea that ABI compatible also equals API compatible that is incorrect. Lets take Mingw headers vs MSVC headers for making Windows applications the result binary out can be ABI compadilble but you will find that the MingW headers are not API compatible with the Microsoft provided msvc headers for making Windows applications macros and other things in the header files can be done differently/named differently even that they generate the same ABI outcome.

        ABI compatible does not equal API compatible same with the reverse. Both can be true at the same time or only 1 can be true.
        Last edited by oiaohm; 03 September 2022, 06:49 AM.

        Comment


        • #14
          Originally posted by theuserbl View Post
          SDL versions < 2.0 are licensed under the LGPL.
          For static linking the LGPL is like the GPL: The created program have to be publised under an LGPL-compatible OpenSource license. So anybody can then rebuild the program with sdl12-compat.
          That contains a fatal presume. Valve has quite a few documented cases where developers remade a game with a new version of compiler and the game logic no longer worked right. Having the source code does not mean you can always rebuild the program without massive amount of effort.

          To be able to rebuild here you need API compatible right. So that the SDL 1.2 headers and so on contain the right macro names and so on and compilers user has does not decide not to build the program due to something that used to be acceptable no longer being acceptable.

          Future proofing the static linked cases having SDL_DYNAMIC_API​ equal in sdl12-compat would be a good thing. Also having recommendation against static linking would also be good thing. Reduce the amount of area end user has to rebuild so reducing compiler issues.

          Comment


          • #15
            Originally posted by Quackdoc View Post
            time to go back and enjoy some old games, maybe I can even find a real cheap CRT monitor somewhere to plug into my hd 4350
            Thanks to the CRT revival "real cheap CRT" may be harder than you think.

            Comment


            • #16
              Long term API compat defeats the purpose of using libraries to simply the implementation of windowing and context initialization. Eventually, a library that is maximally compatible will be a lot more kludgey than a fresh one. Compatibility layers are a great way to handle things like this. Some day, most OpenGL programs will be old, and fine tuned hardware specific GL drivers will go the way of the dodo, and be gladly replaced with compatibility layers like Zink.

              Comment


              • #17
                Originally posted by microcode View Post

                Thanks to the CRT revival "real cheap CRT" may be harder than you think.
                im hoping the local thriftshop might have a usable CRT, certainly wont buy one without testing it however

                Comment

                Working...
                X