SDL 2.0.0 is out after many years in development | Hacker News Reader

SDL 2.0.0 is out after many years in development

lists.libsdl.org

256 pointslifthrasiir61 comments

Lately I started using SFML instead of SDL for C++ Game Development. However, I'll still use SDL on future projects I hope. It's a brilliant library, so compact and portable that the games you write will be able to be compiled to a lot of platforms, even high school graphing calculators[1].

The SDL development still impresses me and 2.0.0 is a major milestone and multiple windows, new OpenGL, touch support, Android and iOS support are here to keep SDL alive with all the new frameworks and "engines". I hope it does well!

[1]: http://www.omnimaga.org/index.php?topic=12378.0

The network and scenegraph stuff that SFML comes with is quite nice--the choice of C++, though, makes other language bindings a bit more clunky.

Yeah, imo SFML's biggest weakness is that it is written in C++ instead of C.

I really like SFML, I've been using for a small game project of mine as well. The API is just nice and beautiful.

I was wondering how SDL 2.0 stacks up against SFML? Does anyone know much about it?

I'm only doing 2D game development, so SDL's "simple 2D rendering API that can use Direct3D, OpenGL, OpenGL ES, or software rendering behind the scenes" is perfect for my needs. However it needs to support two basic things:

* Rotation (additional matrix transformation like scaling & shearing would be nice as as well)

* Transparency (being able to apply a color filter not necessarily limited to the alpha channel, like an RGBA filter would be nicer)

Does it support the above? (I'm guessing it does -- just want to be sure.)

Also, I know Android/iOS support for SFML is in the pipeline, but the fact that it's not ready yet is another reason it might be good to switch to SDL 2.

Yes. SDL_RenderCopyEx and SDL_SetTextureAlphaMod is what you want.

Ah, thanks. SDL_RenderCopyEx seems like a very versatile function[1]. The 2D Accelerated Rendering doc[2] seems to cover all my basic 2D rendering needs. The wiki[3] is really nice, and I like the page listing APIs by category[4].

I think I'm going to switch to SDL, primarily for the Android/iOS support!

[1] http://wiki.libsdl.org/moin.fcg/SDL_RenderCopyEx

[2] http://wiki.libsdl.org/moin.fcg/CategoryRender

[3] http://wiki.libsdl.org/moin.fcg/

[4] http://wiki.libsdl.org/moin.fcg/APIByCategory

There's a decent post on SO about it...

http://stackoverflow.com/questions/2842198/which-is-better-s...

And naturally, it has been closed.

Looks like they changed their license from LGPL to zlib as well. I wonder if this will increase adoption, or if it just was so Valve could use it in Steam for Linux.

Also pretty much required to get applications sdl to ios/android store.

The Play Store is pretty much license-agnostic. At least there is no policy preventing GPL works that I know of.

While the FSF discourages use of the Android marketplace, they do say there's no specific GPL conflict. Compliance is potentially a bit more of a pain for the developer, of course; strictly speaking they have to make sure the LGPL-covered code is available for download for three years after distribution ends. They also strictly speaking have to provide a mechanism to re-assemble the app; example here: http://sparrowmailapp.com/lgpl.php (though note that a lot of people just don't bother).

Given that Starcraft 2 have LGPL code in it, I sincerely doubt that games stores had any part in the decision.

I doubt it would be a huge issue for Valve; they already use LGPL code. However, it's often a big deal for small developers; simpler licenses mean simpler due diligence on investment and such, and a lot of companies are cautious of LGPL in anything that they'll be distributing.

>The really big news is the license change: SDL2 is now covered by the zlib license, whereas previous versions were/are using the GPL/LGPL license.

>This means that it's okay to statically link SDL2 into your game, instead of needing to ship a folder full of shared libraries! xD

source: [1]: http://www.reddit.com/r/gamedev/comments/1k9ila/sdl_20_has_b...

From the About:

"Simple DirectMedia Layer is a cross-platform development library designed to provide low level access to audio, keyboard, mouse, joystick, and graphics hardware via OpenGL and Direct3D. It is used by video playback software, emulators, and popular games including Valve's award winning catalog and many Humble Bundle games."

http://www.libsdl.org/index.php

Oh, yes. New website!

I remember using SDL more than a decade ago and in general it was a pleasant experience. My only gripe was that it needs to hijacked the main loop.

Nevertheless, I will give it a shot again.

Good work Sam!

SDL_main is no longer mandatory (though it is still there); #define-ing SDL_MAIN_HANDLED and calling SDL_SetMainReady once before SDL_Init is sufficient now.

Edit: Ah, if the main loop you refer is SDL_Event loop, as exDM69 said, SDL always supported passive event functions that can be called at your original idle function. SDL 2.0 adds an active event watcher (SDL_AddEventWatch etc.) as an alternative though.

That's great news, I always felt the whole SDL_main thing to be quite evil.

> That's great news, I always felt the whole SDL_main thing to be quite evil.

Evil or not, it solves a practical problem that you would have to work around if SDL did not. And AFAIK, you have always had the option of not using SDL_main if you wish to solve the problem on your own.

On desktop platforms the program entry point is pretty easy to solve (main vs. WinMain) with an SDL_main-style macro or command line args on win32 compilers. But when you start working with iOS and Android, it gets more hairy.

On OS X main was wrapped in a function that made it work with the Finder (manipulating an argv containing --psn).

It was annoying to me because I worked on a application that did the same thing internally and where SDL was not a hard dependency. But well, it's not that bad as I make it sound.

It did make writing bindings for other languages rather interesting

> My only gripe was that it needs to hijacked the main loop.

SDL has never hijacked the main loop, unlike e.g. GLUT. SDL has SDL_WaitEvent and SDL_PollEvent and leaves the main loop to you.

I wrote a silly (unfinished) game about 10 years ago, and SDL portability never ceases to amaze me. The game has been ported to devices I didn't even know they existed.

It's amazing because I did it for fun and I used some data structures I would have never expect to be so portable (ie. using a double linked list of objects in static memory instead of alloc/free). I wonder if that's why it works even in very limited hardware.

My favourite, the game running on a TI-Nspire calculator: http://www.youtube.com/watch?&v=acdAqxiwG7I&t=15

I never understood SDL vs OpenGL. As somebody who does OpenGL why should I use SDL?

OpenGL is a platform-independent API for graphics. SDL is a platform-independent API for everything else relevant to the game development, and also provides an initialization procedure for OpenGL (which OpenGL itself does not provide, so you needed to use platform-specific APIs like WGL and AGL or later standards like EGL).

Isn't SDL the simplest, most portable way to use OpenGL?

OpenGL by itself is useless, it just does 3D graphics, and its GLUT library is too bare-bones to be of much use. SDL is a good, portable chassis for OpenGL application that don't need native GUI integration. An SDL OpenGL app will compile and run almost anywhere, with minimal fuss. Compare that to using OpenGL contexts inside platform-specific toolkits.

GLFW is an excellent library:

http://www.glfw.org/

It's very, very barebones (just enough to GL up to do a thing), but it's quite good in that role.

SDL exists, is tiny, modular and efficient. Not to mention has loads of extensions.

  #include <GLFW/glfw3.h>

  int main(void)
  {
    GLFWwindow* window;

    if (!glfwInit())
        return -1;

    window = glfwCreateWindow(640, 480, "Hello World", NULL, NULL);
    if (!window) {
        glfwTerminate();
        return -1;
    }

    glfwMakeContextCurrent(window);

    while (!glfwWindowShouldClose(window)) {
        /* Render here */


        glfwSwapBuffers(window);
        glfwPollEvents();
    }

    glfwTerminate();
    return 0;
  }

   #include <GL3/gl3.h>
   #include <SDL.h>

  /* Our program's entry point */
  int main(int argc, char *argv[])
  {
    SDL_Window *mainwindow;
    SDL_GLContext maincontext;
    SDL_Event event;
    int running = 1;

    if (SDL_Init(SDL_INIT_VIDEO) < 0)
        exit(1);

    SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 3);
    SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 2);
    SDL_GL_SetAttribute(SDL_GL_DOUBLEBUFFER, 1);
    SDL_GL_SetAttribute(SDL_GL_DEPTH_SIZE, 24);
 
    mainwindow = SDL_CreateWindow(PROGRAM_NAME, SDL_WINDOWPOS_CENTERED, SDL_WINDOWPOS_CENTERED,
        512, 512, SDL_WINDOW_OPENGL | SDL_WINDOW_SHOWN);
    if (!mainwindow)
      exit(1);
 
    maincontext = SDL_GL_CreateContext(mainwindow); 
 
    SDL_GL_SetSwapInterval(1);
 
    
    while (running) {
        while (SDL_PollEvent(&event) {
            if ( event == SDL_WINDOWEVENT_CLOSE ) {
                running = 0;
                break;
            }

            /* render */

        }
        SDL_GL_SwapWindow(mainwindow);
    }
  
    SDL_GL_DeleteContext(maincontext);
    SDL_DestroyWindow(mainwindow);
    SDL_Quit();
 
    return 0;
  }

It's got SDL beat a bit in simplicity for OpenGL, sorry dude.

Yep, because main-loop boilerplate is all one ever does with graphics programming.

Hey, no reason to get snippy--you asked "Isn't SDL the simplest, most portable way to use OpenGL?", and asserted that it's a smaller library. I showed you a still-smaller alternative, and even dug up code to substantiate that point.

There's nothing wrong with using SDL for making a game (well, maybe a couple of things, but that's not relevant here), but it simply isn't the smallest GL scaffolding library out there.

Heh, you're right, I got a little snarky. Sorry :-P

But I got bit by half-assed "GL" ways of doing things before. SDL has everything, in layers, so you can grow into it. Unlike "portable GL" libraries which are discrete, isolate dead-ends.

Calling GLFW a "dead end" is misleading and unfair.

GLFW does not attempt to handle OpenGL for you, it handles windowing and input for you. I personally really don't want SDL anywhere near my projects because it imposes its own structure upon me. (I don't use Allegro, even for 2D code, for similar reasons.) I am simply not all that fussed by writing up a VBO handler and some pretty simple OpenAL code myself--it isn't difficult enough for me to warrant the huge blob of extraneous SDL stuff.

As someone who's used neither, I'd call that a draw. Neither of that boilerplate looks particularly scary or insane.

That doesn't show that GLFW is simpler than SDL. It just shows that GLFW has some simple defaults. How much complexity is added to the GLFW code if you want to require a minimum GL version and depth buffer size? Or a fulllscreen window?

Sure. Fullscreen mode:

      window = glfwCreateWindow(640, 480, "Hello World", glfwGetPrimaryMonitor(), NULL);

Requesting a specific version with a particular depth:

  glfwOpenWindowHint(GLFW_OPENGL_VERSION_MAJOR, 3);
  glfwOpenWindowHint(GLFW_OPENGL_VERSION_MINOR, 2);
  glfwOpenWindowHint(GLFW_DEPTH_BIT, 24);

There you go.

Unfortunately, it is not yet available on Android and iOS. Also http://www.glfw.org/faq.html#12__what_is_glfw_not

The amount of code necessary to wire up a well-written application into iOS and Android is pretty minor. I'd rather do that where I can't use GLFW (I mean, GLEW does most of the hard work anyway, and that is portable). GLFW epitomizes a good library for this stuff, in that it's minimal and minimizes the amount of stuff you have to wrestle with when writing C++; on the other hand, SDL forces you to come to grips with its weight and its own dubious design decisions (and a lot of plumbing code to make it sane in C++).

When wrapping OpenGL code myself, at least the dubious design decisions are my own and I understand them intuitively.

SDL is a decent cross-platform layer for handling things like window creation, event handling, joystick and other devices, and things like this.

However, if you're using OpenGL, there are at least two libraries you'll probably want to make heavy use of (because SDL doesn't do anything worth mentioning in those regards):

FreeImage for image loading ( http://freeimage.sourceforge.net/ )

AssImp for model loading ( http://assimp.sourceforge.net/ )

Both are amazingly handy, have good licenses, and have excellent documentation (FreeImage is one of my favorite tech writing examples of all time).

I used SDL 2 after Sam's "please use SDL 2 and report problems" email about 2 or 3 years ago and it was a pleasant experience and a much needed upgrade over SDL 1 (though most of the docs were still incomplete). So this announcement makes me happy.

I have been using SDL2 for awhile now and it is a great library. It was definitely not ready until now though. I still need to rewrite my game engine to work with the current version. I am happy to hear this will be the last rewrite though!

How does android and ios support work? What is the process for compiling and using it from an objective C (ios) or java (android)?

Woo! I have been using SDL for years to build all sorts of projects (games, touch screen interfaces, etc.).

But as others here have noted I migrated over to use SFML, mainly because of its nice object-oriented implementation as well as the additional convenience features such as rotation and better alpha support.

Great library. Simple to use and efficient. I have been using it for some time. I have created a little TMX file reader aiming at game development. C is hard but fun:

https://github.com/batiste/sdl2-game-loop

Thought I'd share this comprehensive 36 chapter SDL game programming tutorial series, though it is for SDL 1. http://lazyfoo.net/SDL_tutorials/

I wonder how SDL 2D rendering capabilities compare to SFML, now that they both are OpenGL accelerated.

Awesome work, I'm looking forward to use it! I always liked the combination of SDL+OpenGL. Clipboard support is also very exciting because using X for that in Linux is a nightmare :)

If I start a new multimedia project today and aim to support the widest range of devices should I use this version of SDL or 1.x?

Use SDL2, much better and official support for mobile platforms. The only platforms that were killed in SDL2 are old ones like MacOS9 etc.

What about OpenGL 4.x support? OpenGL 3.x is not enough already.

Let me guess: it's still impossible to minimize a full screen game on Linux or alt-tab etc., and the joystick will still not be recognized if you plug it in after the game starts.

> Let me guess: it's still impossible to minimize a full screen game on Linux or alt-tab etc.

You can hardly blame SDL for this, games are not really what X11 was designed for. Setting up full screen and asking for exclusive access to the keyboard will prevent the window manager from doing anything to it.

My solution for this problem: use a window manager that can full screen any window and switch back.

> and the joystick will still not be recognized if you plug it in after the game starts.

To be fair, 99% of AAA games don't support joystick hotplugging either. It's really annoying.

Since you have not checked whether this is actually the situation and do not properly understand the other components in the equation, I find your attitude offensive.

> You can hardly blame SDL for this, games are not really what X11 was designed for.

It's funny how the Windows version of the game usually works just fine in Wine, minimization and window switching included.

> Setting up full screen and asking for exclusive access to the keyboard will prevent the window manager from doing anything to it.

Then why are they asking for exclusive access to the keyboard in the first place? X has rich input protocols (XInput2 was recently designed).

> Since you have not checked whether this is actually the situation

True, but I have read the changelog, and it doesn't mention any of these two annoying problems to be fixed. Part of the reason I made this comment is to see if someone else knows whether they were fixed.

IIRC, there was a presentation by Valve where they complained that even if you don't do a keyboard grab, some window managers do it for you when you request a fullscreen window.

For an SDL2-using game, I tried BrütalLegend and alt-tab works as you'd expect when using OpenBox. I usually just run games in a separate X server with just OpenBox to isolate them from messing with my main desktop. Plus, they can't block ctrl+alt+F7.

> and do not properly understand the other components in the equation

Even though I believe I do, this is irrelevant, all the end user sees is that it doesn't work, he doesn't care about the architectural problems of the window system. It's extremely annoying when you have to exit the game to look something up (probably related to the game itself), or do anything else, especially considering how long modern games take to load.

SDL2 supports hot plugging input devices!

> it's still impossible to minimize a full screen game on Linux or alt-tab

I'm not sure how it handles it, but kerbal space program doesn't have this problem in linux.

I know it works, and I'm very happy for it. Would have taken me a lot more time to land on the Mun otherwise ;)

Pretty sure kerbal space program is using Unity3D

Reply on news.ycombinator.com