Announcement

Collapse
No announcement yet.

SDL2 Gets Useful Dynamic API Support For Games

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

  • SDL2 Gets Useful Dynamic API Support For Games

    Phoronix: SDL2 Gets Useful Dynamic API Support For Games

    Ryan Gordon has added dynamic API support to the SDL2 library that's commonly used by cross-platform games. This dynamic API library should prove to be very useful for games and allows gamers to easily override the SDL library used by a particular game...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Couldn't this be used for cheating, e.g. link in a modified version that render the enemies in a clearly visible color?

    Comment


    • #3
      Hmm, I don't see much benefit in this. This will just encourage developers to continue their bad habit of static linking things. You're not supposed to do that, ever; if you do that with SDL, you might also do that with OpenAL, and OpenAL doesn't have such an override, so you'll be stuck without sound in the long run anyway. It's better to just ask the developers to not do silly things like that.

      Comment


      • #4
        Originally posted by Pajn View Post
        Couldn't this be used for cheating, e.g. link in a modified version that render the enemies in a clearly visible color?
        NO. SDL is just a low level API. That kind of logic is not built-in.

        Comment


        • #5
          Originally posted by GreatEmerald View Post
          Hmm, I don't see much benefit in this. This will just encourage developers to continue their bad habit of static linking things. You're not supposed to do that, ever; if you do that with SDL, you might also do that with OpenAL, and OpenAL doesn't have such an override, so you'll be stuck without sound in the long run anyway. It's better to just ask the developers to not do silly things like that.
          It seems the lead developer of libSDL may be looking towards a Wayland future since he mentioned Wayland specifically in his post. It seems that right now at least the display server/protocol is more likely to change at the moment than the audio system. This seems like a wise move to make sure that libSDL programs where the developer has made the choice of using static linking still work on Wayland with the developer having to specifically enable it.

          Comment


          • #6
            Very good. That flexibility can be very useful.
            Static linking for basic libraries can cause a lot of problems.

            Wish this kind of dynamic API/library support was standard.
            Or that C/C++ and the platform(Linux,...) was better designed to have such flexibility in a pragmatic way.

            Comment


            • #7
              Originally posted by paintbynumbers View Post
              It seems the lead developer of libSDL may be looking towards a Wayland future since he mentioned Wayland specifically in his post. It seems that right now at least the display server/protocol is more likely to change at the moment than the audio system. This seems like a wise move to make sure that libSDL programs where the developer has made the choice of using static linking still work on Wayland with the developer having to specifically enable it.
              The bad thing is that this most likely won't work from older SDL versions. I see it like this:
              Code:
              /* Pseudocode */
              if (SDL_DYNAMIC_API is set) {
                  // Some checks here that the SDL_DYNAMIC_API is valid...
                  mapAllCallsTo(SDL_DYNAMIC_API);
              } else {
                  // Use calls in this library
              }
              So all versions having this should already support Wayland (except when it's compiled out, but then the dev that did it did it with a reason, no?).

              Comment


              • #8
                OpenAL-soft is LGPL, so no static linking legally.

                Couldn't this be used for cheating, e.g. link in a modified version that render the enemies in a clearly visible color?
                SDL_HighlightEnemies(SDL_RED); SDL_EnableAutoAim(true); SDL_HideHacksFromServer(true);

                Comment


                • #9
                  Originally posted by TAXI View Post
                  So all versions having this should already support Wayland (except when it's compiled out, but then the dev that did it did it with a reason, no?).
                  Sure, they will probably target Wayland 1.3 or 1.4 with the next libSDL release but they may want to take advantage or features in a newer API version or possibly something in the xdg-shell. Likely the libSDL API function signatures require no changes but a newer libSDL could provide better Wayland support.

                  Comment


                  • #10
                    Originally posted by curaga View Post
                    OpenAL-soft is LGPL, so no static linking legally.
                    Well, thank goodness for that. Still, that was an example, I mean that the same problem applies to other libraries as well, not only SDL.

                    Comment

                    Working...
                    X