My opinion about SDL is it is awesome. But not at every condition.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
--Pros of using SDL:
*Easy to Learn
*Works great with OpenGL.
--Cons of using SDL:
*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.
1 2 3 4 5 6 7 8 9 10 11 12 13 14
--Pros of using SFML:
*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.
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).
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.
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.
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...?
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.