Game Development with SDL2

[N36fSL3A]

I meant to actually post this here a while ago (a few days after it was uploaded), but I never got around to it. I'm extremely interested in this talk, and I felt I needed to share it.

Straight to the point (Warning, this video is long):
https://www.youtube.com/watch?v=MeMPCSqQ-34

So after you're done, I'd like you to post why this is BS, or why you like another library better (SFML, Allegro), or just to bash the crap out of SDL.

[ultifinitus]

I got bored after about 5 minutes of the video, not that he doesn't know what he's talking about, there is a lot of back end stuff to talk about to get to the meat.

However SDL2 is awesome! I needed to test out some experimental rendering techniques last week and it was super quick to get up and running with a framebuffer. Not only that but man was it fast.

Most of the stuff that held SDL 1.2 onward back have been fixed in 2.0 (at least all of my annoyances, like the single window thing, have been fixed)

I don't know, but in my opinion a graphics library is meant to support development, and I think it does a great job!

[Ceset]

I watched 10 minutes of it and got bored.

My opinion about SDL is it is awesome. But not at every condition.
SDL:

--Pros of using SDL:
*Powerfull
*Simple
*Multi-Platform
*Easy to Learn
*Works great with OpenGL.

--Cons of using SDL:
*Low Level
*Requires Time before Starting Making Games.

--Not a good Choice if the followings are true:
     ->Less than Five guys working to make a game.
     ->The group will be dismissed after finishing the game
     ->The classes the group made wont be used again.
     ->You are a beginner.

SFML:

--Pros of using SFML:
*High Level
*Multi-Platform
*OpenGL Support.
*Good for beginners.

--Cons of using SFML:
*Not as flexible as SDL
*Requires Time to Learn Features.

--Not a good Choice if the followings are true:
     ->You are a company.
     ->Your group is big.
     ->The classes you made will be used later.

Okay these are my opinion. Sorry i know nothing about Allegro.

I also want to indicate that even though i am an SDL fun, in the project i am currently working on we use SFML because not everyone likes SDL cause it is low-level which means "takes time before starting making games". Also thinking that we have just three programmer it would not be a good choice.

And i am trying to write a library that will make the use of SDL easier. An SDL2 based framework.

As a side note thinking what features SDL2 brought, it became a lot better.

[N36fSL3A]

->Less than Five guys working to make a game.
->The group will be dismissed after finishing the game
->The classes the group made wont be used again.
->You are a beginner.

I don't see how any of these cons are actually related to SDL. The first con is not even remotely true, because many indie developers (working alone) have released games that used SDL.

The cons for SFML aren't relevant at all either.

[helios]

I haven't given SDL2 a real stress test, but I found 1.2 to be disastrous when doing cross-platform work with 32-bit surfaces. I don't know if the software routines were broken, or if the hardware drivers were broken, but I just couldn't find a blend configuration that worked on both Linux and Windows. It was so bad I ended up writing my own alpha blending routines at a great man-hours expense.
Also, some of the threading facilities were terrible. In particular, I remember SDL_Mutex locked with a maximum granularity of 10 ms (!). I didn't check the code, but it seems like a Sleep()-assisted spinlock. Just awful.

The sister libraries were less than stellar, as well. SDL_ttf, for example, would choose a different auto-hinting setting for each platform, with no way of changing it at API level.
SDL_mixer gave me issues, too, but I can't remember what they were, ATM.
The only part I don't really have any complaints about is SDL_image, although as my project matured and I got sick of fixing memory leaks and race conditions, the responsibilities of SDL_Surface progressively shrank until SDL_image functioned solely as a thin wrapper around various image libraries.

Overall score: SDL 1.2 is great if you think 32-bit pixels are too hip for you, or if you just want a simple-to-use window handler for OpenGL.

So I don't really many good memories with SDL, but if nothing else, writing an engine with it was great as a learning experience.
But, hey, maybe they fixed many of those issues (not SDL_Surface, because that's just broken without RTTI).

[NoXzema]

I've used SDL2 and SDL 1.2 as a GL context creation tool and as a window and input tool. 1.2 was less than great simply because it was old. SFML, GLFW, and various others had already established multiple-window support, multiple context creation, and explicitly support OpenGL. SDL 1.2 didn't really do any of these things.

SDL2 was vastly different. It added an entire GL API to create a context, manage it, set attributes, etc. in a cross-platform manner. It is truly cross-platform in this way... but there's still issues.

1) It doesn't /explicitly/ support DirectX. You can't have a DirectX renderer and an OpenGL renderer and have SDL support both. This doesn't matter to me, I think DirectX is the bane of the world, onto the next problem.

2) Half the API isn't really usable. It uses software-based blitting and the ones that do not still use blitting that is inefficient for that purpose. Using OpenGL directly or an engine that has scene management is way faster than using SDL texture blitting. It's just a poor unoptimized technique meant for games that have no graphical demands. Basically all of the video functions, outside of window and context creation, concern managing a texture (hardware-based), surface (software-based), and blitting.

3) It doesn't support foreign windows and hardware acceleration. Apparently, not a *single library* does this. It's supposedly coming but that was a few months ago. It's slightly allowed on Windows through a severe work around but meh.

4) It's default signal parachute is retarded.

5) The sister libraries aren't very usable in a real environment. Alternatives are always better and more featured, even if they don't have immediate integration with SDL.

6) Some of the functions are actually macros. This makes it impossible to wrap them into another language like Python or D. Specifically, the ones that deal with platform detection.

EDIT: 7)
The context management requires an SDL_Window which shouldn't be required but SDL_Window has platform-specific attributes unrelated to the actual native window that the context creation API needs. I count this as a downside as things like windowless contexts are impossible with this design.

[N36fSL3A]

5) The sister libraries aren't very usable in a real environment. Alternatives are always better and more featured, even if they don't have immediate integration with SDL.

I think I only use SDL_image, I have to admit the other ones are crap, especially SDL_mixer.

6) Some of the functions are actually macros. This makes it impossible to wrap them into another language like Python or D. Specifically, the ones that deal with platform detection.

Just wrap the macro into a function and bind that.

[NoXzema]

You'd then have to have a small C layer in between your other layer and SDL. Not ideal. You'd be better off looking for alternatives in the current language.

[helios]

Specifically, the ones that deal with platform detection.

That's for conditional compilation. You wouldn't be able to make use of that in a non C* language, anyway.

[N36fSL3A]

^

Plus, if your scripting language code relies on OS-Specific functions then you're doing it wrong in most cases.

[Ceset]

I don't see how any of these cons are actually related to SDL.

@Fredbill you are very right. None is related to SDL. This is why the title is "it is not a good choice if the followings are true". It is not "SDL cons".

Also i am not claiming my opinions are the ultimate truths.

@NoXzema
Maybe wait a little more and they will fix the problems.

[N36fSL3A]

Ceset wrote:

@Fredbill you are very right. None is related to SDL. This is why the title is "it is not a good choice if the followings are true". It is not "SDL cons".

Yea, realized my mistake there. I meant "it is not a good choice if the followings are true".

If none of those statements are related to SDL, then why even include them in your post? Those are problems with your source code design.

@NoXzema
Maybe you should give a shot to SDL2. They made hell lot of changes. And added many new features.

He's talking about SDL2.

[NoXzema]

I use SDL2 all the time. Some of them they don't consider problems which I can relate to.

Also, I take back what I said about macro usage. This has apparently changed since I last looked at it. SDL_HasSSE* and related functions are now.... well, functions. Maybe I was looking at something else...?

[BHX]

I've not watched it, but Gordon doesn't seem like the kind of person to BS.

http://en.wikipedia.org/wiki/Ryan_C._Gordon

[Ceset]

@Fredbill
Yes sorry i changed it quickly.

Also i want to explain my thoughts a little better. If one decides to use SDL he needs to create classes such as texture, sprite, noncopyable, drawable ...If one decides to use SFML, just need to learn how to use these features.

[N36fSL3A]

Yes, but SFML isn't the answer to everything, and if you decide to only use a few features you still pay the price for unnecessary executable bloat.

SDL is small and simple; it also runs on pretty much every platform since the mid 90s. You can write your code in a way that's extremely reusable (Valve uses SDL extensively for the steam client.)

[Ceset]

And that is why i like SDL very much.