Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

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

timothy posted about a year ago | from the simple-is-modest dept.

Graphics 42

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."

cancel ×

42 comments

Sorry! There are no comments related to the filter you selected.

Staticlinkable to closed software not a good thing (3, Insightful)

rvalles (649635) | about a year ago | (#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.

Re:Staticlinkable to closed software not a good th (0)

HaZardman27 (1521119) | about a year ago | (#44551753)

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.

Re:Staticlinkable to closed software not a good th (4, Informative)

Narishma (822073) | about a year ago | (#44552123)

The license change happened more than a year before Sam Lantinga was hired by Valve.

Re:Staticlinkable to closed software not a good th (3, Informative)

HaZardman27 (1521119) | about a year ago | (#44552371)

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 ;)

Re:Staticlinkable to closed software not a good th (1)

tepples (727027) | about a year ago | (#44551859)

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.

Re:Staticlinkable to closed software not a good th (1)

Gaygirlie (1657131) | about a year ago | (#44551947)

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?

Re:Staticlinkable to closed software not a good th (1)

Ded Bob (67043) | about a year ago | (#44551997)

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

Re:Staticlinkable to closed software not a good th (1)

Gaygirlie (1657131) | about a year ago | (#44552021)

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.

Installation Information (4, Informative)

tepples (727027) | about a year ago | (#44552103)

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.

Re:Installation Information (2)

Gaygirlie (1657131) | about a year ago | (#44552139)

Well, thanks for clarifying that bit.

Re:Installation Information (4, Informative)

tlhIngan (30335) | about a year ago | (#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.

Re:Installation Information (1)

tepples (727027) | about a year ago | (#44554775)

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 agreement, for example, already got a major revision to support home offices. Nintendo still requires "industry experience" (whatever that means, apart from having shipped a playable game for Windows, Mac, iOS, or Android), but now it defines a "secure facility" as just a separately locked room.

as AAA titles become de-emphasized and the next gen will be about indie games.

Even if only to keep all their user base from belonging to OUYA.

Re:Installation Information (4, Insightful)

Unknown Lamer (78415) | about a year ago | (#44556463)

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...

Re:Staticlinkable to closed software not a good th (0)

Anonymous Coward | about a year ago | (#44552853)

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.

Re:Staticlinkable to closed software not a good th (0)

Anonymous Coward | about a year ago | (#44552017)

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).

Re:Staticlinkable to closed software not a good th (0)

Anonymous Coward | about a year ago | (#44551967)

How does one spell "non-sequitor"?

Re:Staticlinkable to closed software not a good th (1)

tepples (727027) | about a year ago | (#44552149)

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.

Re:Staticlinkable to closed software not a good th (0)

Anonymous Coward | about a year ago | (#44553611)

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.

Re:Staticlinkable to closed software not a good th (2, Funny)

K. S. Kyosuke (729550) | about a year ago | (#44553065)

How does one spell "non-sequitor"?

With great difficulty, apparently.

Re:Staticlinkable to closed software not a good th (1)

adisakp (705706) | about a year ago | (#44553113)

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.

Re:Staticlinkable to closed software not a good th (2)

assassinator42 (844848) | about a year ago | (#44554401)

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.

without a kickstarter project? (1, Funny)

Anonymous Coward | about a year ago | (#44551695)

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

Re:without a kickstarter project? (2)

NatasRevol (731260) | about a year ago | (#44552011)

Well, it's probably because they want GMO plants as payment.

SDL2 libs aren't available (0)

Anonymous Coward | about a year ago | (#44551757)

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

Re:SDL2 libs aren't available (0)

Anonymous Coward | about a year ago | (#44552669)

Why don't you just compile the libraries by yourself? The hg repository is nowadays easy to use for compiling the libraries. Just "./autogen.sh", "./configure", "make" and "sudo make install" and you have the latest and greatest binaries.

Thanks! (3)

Kludge (13653) | about a year ago | (#44551925)

Thank you to everyone who made this possible.

Python bindings (2)

tepples (727027) | about a year ago | (#44551949)

A set of Python bindings similar in scope to SDL 1.2's Pygame has been released: sdl2.ext [readthedocs.org] .

Re:Python bindings (0)

Anonymous Coward | about a year ago | (#44552361)

Thanks, all I could find was a few dead projects.

SDL_main (1)

Anonymous Coward | about a year ago | (#44552189)

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.

Re:SDL_main (1)

jones_supa (887896) | about a year ago | (#44554991)

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.

Actually some pretty nice improvements (4, Insightful)

gman003 (1693318) | about a year ago | (#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.

Re:Actually some pretty nice improvements (3, Interesting)

Unknown Lamer (78415) | about a year ago | (#44557627)

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).

Re:Actually some pretty nice improvements (1)

Yvanhoe (564877) | about a year ago | (#44561837)

Hehe, it sounds like the recent release of a neat version of GLFW woke up the SDL developpers. Can't say I will complain!

License change (2)

Necreia (954727) | about a year ago | (#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).

remarkable piece of software (0)

Anonymous Coward | about a year ago | (#44554319)

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.

Vsync? (1)

jones_supa (887896) | about a year ago | (#44554865)

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?

Re:Vsync? (0)

Anonymous Coward | about a year ago | (#44560941)

SDL_Renderer *renderer = SDL_CreateRenderer(sdlWindow, -1, SDL_RENDERER_PRESENTVSYNC); // with VSYNC

and

SDL_Renderer *renderer = SDL_CreateRenderer(sdlWindow, -1, 0); // no VSYNC

does the job.

SDL_WINDOW_BORDERLESS (2)

Graspee_Leemoor (302316) | about a year ago | (#44557055)

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.

So.. (0)

Anonymous Coward | about a year ago | (#44558403)

How's the input latency under 30fps? 20? 10? How's the WinXP regressing? 2000? 9X?

Does the SDL 2.0 support Occulus Rift? (1)

Anonymous Coward | about a year ago | (#44560921)

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.

Re:Does the SDL 2.0 support Occulus Rift? (1)

Hsien-Ko (1090623) | about a year ago | (#44561257)

So...... it'll be blurry and filtered to hell?

Re:Does the SDL 2.0 support Occulus Rift? (0)

Anonymous Coward | about a year ago | (#44561843)

What do you mean?

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>