Slashdot Mirror
SDL 2.0 Release Improves 2D/3D Rendering, Better Audio & New Features
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."
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.
Wow, reading /. the last couple of days, it amazes me that opensource development can still happen without a successful kickstarter project!
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.
Apparently wizard is not a legitimate career path, so I chose programmer instead.
I wanted to fetch the SDL2 libs that were on the main site but over the course of a few hours they vanished. No backups are found anywhere and the site is mostly down. This is irritating, wish the direct links weren't taken away. Anyone have a copy of SDL2_mixer.lib and SDL2_image.lib please let me know where to download it. :3
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.
Thank you to everyone who made this possible.
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 ), how does that preclude game consoles?
A set of Python bindings similar in scope to SDL 1.2's Pygame has been released: sdl2.ext.
How does one spell "non-sequitor"?
He probably meant SDL v1.2 which was licensed under the LGPL.
You failed to RTFA, didn't you? It was re-licensed as zlib for 2.0; previously it was GPL so couldn't be statically linked (making it incompatible with the licenses required for most console development).
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.
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.
The license change happened more than a year before Sam Lantinga was hired by Valve.
Mada mada dane.
How does one spell "non-sequitor"?
You got it close; it's -tur. But I don't see how mentioning a second implication of relicensing from LGPL to a permissive license is a non-sequitur in a reply to a comment mentioning a first implication.
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.
Oh, interesting; I did not know that. Thanks for pointing it out instead of yelling at me for being lazy and not looking it up ;)
Apparently wizard is not a legitimate career path, so I chose programmer instead.
The loophole has always been that as long as you don't statically link LGPL'd code, you're okay. In other words, if you use it via a dynamic library you can use it in your proprietary code. What the parent of this thread is upset about is that now that the code is under a license that allows game developers to statically link the library, that means you won't be able to recompile a dll to retarget a game to a platform or desktop environment it perhaps wasn't intended to run on.
How does one spell "non-sequitor"?
With great difficulty, apparently.
Ezekiel 23:20
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'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.
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).
Seems I owned myself.
My comment was more about the parent's implication of PC development being undesirable due to "small PC monitor size."
Didn't occur to me he was talking about physical size rather than the screen's available display resolutions.
SDL was and is a remarkable piece of software,
and I hope every flavor of Linux will incorporate version 2 as part of the standard distribution,
so that gaming on linux will finally be more viable from a developer's perspective.
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.
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?
I'm a big user of SDL 1.2 and to be honest I wasn't going to change. I was poking around today though and found that there's built-in support to remove window decoration (as well as lots of other nice new features). I'd previously tried to remove window decoration myself under Windows in SDL 1.2 by using Win32 calls and wasn't 100% successful.
How's the input latency under 30fps? 20? 10? How's the WinXP regressing? 2000? 9X?
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.