Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
Graphics Open Source Software

SDL 2.0 Release Improves 2D/3D Rendering, Better Audio & New Features 42

Posted by timothy
from the simple-is-modest dept.
An anonymous reader writes "Simple DirectMedia Layer 2.0 has finally been released. The cross-platform multimedia layer used by hundreds of cross-platform games has seen its first major release in years. The SDL 2.0 release has many new features including GL3 and OpenGL ES rendering support, a new 2D rendering API, better full-screen / multi-window support, multiple input support, Android and iOS support, power management, and other new functionality. SDL 2.0 can be downloaded from libsdl.org."
This discussion has been archived. No new comments can be posted.

SDL 2.0 Release Improves 2D/3D Rendering, Better Audio & New Features

Comments Filter:
  • by rvalles (649635) on Tuesday August 13, 2013 @08:14AM (#44551683)

    With SDL 1.2, if there was a bug on SDL... or if in need to run the game on the new directfb/wayland/whatever frontend, updating SDL was enough.

    With SDL 2 linked statically against some closed game... not so much.

    • It makes sense that it happened, though. Now that Sam Lantinga works for Valve, I'm imagine Valve considers SDL to be "their" technology for use on Linux systems.
    • by tepples (727027)
      The (weak) copyleft license of SDL also meant that games couldn't be recompiled for distribution on game consoles. This meant that despite SDL's support for two or more joysticks, it wasn't very practical to make a game that uses them due to the smaller average PC monitor size. Some people have a home theater PC, I'll admit, but very few, and probably not enough to make a major-label game viable.
      • The (weak) copyleft license of SDL also meant that games couldn't be recompiled for distribution on game consoles.

        Uh, what? It's licensed under the zlib - license ( http://www.gzip.org/zlib/zlib_license.html [gzip.org] ), how does that preclude game consoles?

        • by Ded Bob (67043)

          He probably meant SDL v1.2 which was licensed under the LGPL.

          • He probably meant SDL v1.2 which was licensed under the LGPL.

            LGPL still does allow linking against proprietary code, so I don't see the problem there, either. There are plenty of commercial, proprietary games that use SDL for one or another thing.

            • by tepples (727027) <tepples@[ ]il.com ['gma' in gap]> on Tuesday August 13, 2013 @08:55AM (#44552103) Homepage Journal
              Like the GPL, the LGPL requires distributions of executable applications to provide "scripts for controlling installation" (2.1) or "Installation Information" (LGPLv3) for running an application with a modified library. Console makers have shown themselves unwilling [slashdot.org] to allow video game publishers to provide this sort of Installation Information to the public.
              • Well, thanks for clarifying that bit.

              • by tlhIngan (30335) <[ten.frow] [ta] [todhsals]> on Tuesday August 13, 2013 @10:16AM (#44553099)

                Like the GPL, the LGPL requires distributions of executable applications to provide "scripts for controlling installation" (2.1) or "Installation Information" (LGPLv3) for running an application with a modified library. Console makers have shown themselves unwilling to allow video game publishers to provide this sort of Installation Information to the public.

                Actually, in general, console makers are against open-source period. Technically speaking, you COULD use GPLv2 code in your game (making it GPLv2), but pretty much all the console makers prohibit any sort of thing like that. In 2009, the ScummVM team found ScummVM used in 3 Wii games [wikipedia.org] and then people realized their SDK agreement prohibited open-source.

                And naturally, the installation information will never be public because it'll contain private keys that the console makers would rather keep private.

                About the only code allowed for a console game is BSD or BSD like (zlib, apache, etc). where the developer has full control of the code.

                Of course, the Wii U, Xbox One and PS4 will probably see hefty revisions to their developer agreements as AAA titles become de-emphasized and the next gen will be about indie games.

                • by tepples (727027)

                  Technically speaking, you COULD use GPLv2 code in your game (making it GPLv2), but pretty much all the console makers prohibit any sort of thing like that.

                  Some Slashdot users who replied to the ScummVM-on-Wii and VLC-on-iOS stories would prefer to reword it to place the blame on the other party, however: "You could release your game on a locked-down platform, but pretty much all the GPL library authors prohibit any sort of thing like that. Copyleft takes away the ability to release on what may be the best platform for the job. This is why I and others who agree will avoid copylefted software in favor of permissively licensed software."

                  Of course, the Wii U, Xbox One and PS4 will probably see hefty revisions to their developer agreements

                  The Wii U developer agre

              • Then.... write your own damn game library if you don't want to play nice.

                The anti-copyleft trend in the "open source" world has been awful. Possibly because the kids these days don't remember how awful it was before there was Free Software for basically any task you needed. But they'll know soon enough...

    • by adisakp (705706)

      With SDL 1.2, if there was a bug on SDL... or if in need to run the game on the new directfb/wayland/whatever frontend, updating SDL was enough.

      With SDL 2 linked statically against some closed game... not so much.

      Perhaps this is for iOS / Android? Statically linking allows for dead-stripping of unused code and possibly considerably smaller binaries which is ideal for Mobile Apps that will run on limited platforms -- especially since you can't update a single dynamically linked binary for a mobile app anyhow.

      • I believe you can actually update the QT libraries on Android separately using Ministro. I don't know if any other libraries do something like this.

  • by Anonymous Coward

    Wow, reading /. the last couple of days, it amazes me that opensource development can still happen without a successful kickstarter project!

  • by Kludge (13653) on Tuesday August 13, 2013 @08:40AM (#44551925)

    Thank you to everyone who made this possible.

  • by tepples (727027) <tepples@[ ]il.com ['gma' in gap]> on Tuesday August 13, 2013 @08:41AM (#44551949) Homepage Journal
    A set of Python bindings similar in scope to SDL 1.2's Pygame has been released: sdl2.ext [readthedocs.org].
  • by Anonymous Coward

    It looks like they've stopped using the preprocessor to hijack the entry point for SDL_main. That practice caused no end of annoying mysterious problems in the past - I can't wait to get home and test to see if it's true.

    • That has always been a little PITA. :) I never got the combination of Windows + Qt Creator + SDL to make the entry point to work. Linux + Qt Creator + SDL worked, and Windows + Visual Studio + SDL worked.
  • by gman003 (1693318) on Tuesday August 13, 2013 @10:24AM (#44553199)

    I've been reading through the improvements, and this actually seems like a big step forward for SDL. It's dropping antique crap like CD audio playing, moving towards a more modern GPU-focused system. They're not keeping old API bits around just for compatibility, but none of these changes seem like change-for-the-sake-of-change. I'm particularly interested in the OpenGL 3.0 stuff - getting a "modern" OpenGL context set up is a pain in twenty asses, and if they can simplify that, all the better.

    • For me, the best improvement is that joysticks are hot pluggable now. So now all of the obnoxiousness with deprecating use of the linux joystick protocol in favor of evdev and losing calibration and button remapping is finally worth it. Combined with the sixaxis daemon [sourceforge.net], emulators and native games are downright pleasant to use nowadays (yeah yeah, you have to give evil Sony tons of money, but I like to delude myself into thinking the input device people aren't as evil as the rest of the company). If only most programs didn't get confused by the accelerometers making configuration a pain (dear fellow hackers: please require an axis to change by some threshold and not just have a non-zero value in auto-configuration. I'm looking at you armagetronad).

    • by Yvanhoe (564877)
      Hehe, it sounds like the recent release of a neat version of GLFW woke up the SDL developpers. Can't say I will complain!
  • by Necreia (954727) on Tuesday August 13, 2013 @10:26AM (#44553213)

    One of the more interesting changes is the license switch from LGPL to zlib.

    I suspect this was done due to the rise of SFML (Simple and Fast Multimedia Library).

  • I never got this command to enable OpenGL vsync properly under Windows:

    SDL_GL_SetAttribute(SDL_GL_SWAP_CONTROL, 1);

    However this works:

    typedef bool (APIENTRY *PFNWGLSWAPINTERVALFARPROC)(int);
    PFNWGLSWAPINTERVALFARPROC wglSwapIntervalEXT = 0;
    wglSwapIntervalEXT = (PFNWGLSWAPINTERVALFARPROC)wglGetProcAddress("wglSwapIntervalEXT");
    if (wglSwapIntervalEXT) {
    wglSwapIntervalEXT(1);
    }

    Why did the SDL-specific method not work with any GPU? Does it work in 2.0?

  • by Anonymous Coward

    I ask because Occulus Rift is the next MUST need and MUST support in future Games.
    It is a new Game experience and will be similar like the rise of the first 3d video accelerator Voodoo Graphics cards.

"Lead us in a few words of silent prayer." -- Bill Peterson, former Houston Oiler football coach

Working...