I don't like SDL very much. I think it doesn't do what it does terribly well - it's not very useful either for newbies (who it just confuses), or experienced game programmers (who it just annoys)
SDL can be used in the following ways:
1. To create a software rendering engine
Well, at least, it could be, if it actually had any software rendering functions. It can't even draw a (diagonal) line on its own, so you'd need SDL_gfx or something. It can't even say "Hello, World" on its own, so you'd need SDL_ttf or something similar.
What they've done, is put a wrapper around the functions that they know are hardware-accelerated under DirectDraw - and nothing else.
So unlike Allegro, you can't actually make a useful software rendering engine unless
- You are prepared to write your own line, circle, sprite, text, blending, etc routines
- OR you are prepared to use a number of third party libraries - which would be fine, except these libraries are not usually bundled with SDL and aren't necessarily trivial to build.
I was making a SDL game for a competition. A 48 hour competition. I thought "Great, I'll develop this on Linux, and it will be a cinch to build on win32".
I was wrong. SDL itself works fine on win32, but I *HAD* to use a text library - SDL_ttf - which, it turns out, didn't build trivially (although I did get it to build eventually, even though it did involve linking its .c files with my code in my own Makefile (yuk))
2. As a platform-independent way to get a GL context
Well, this is at least slightly more usable. With GL, you don't actually need a line drawing routine etc, because you can use opengl calls to do that sort of thing.
Great - EXCEPT, this confuses newbies, who are constantly asking "Why does XXX software rendering function in SDL, not work in GL mode properly" ?
Because the core of the library was made for doing software rendering (although not actually providing a wide selection of primitives), those functions are not necessarily going to work entirely correctly (or quickly) in GL mode.
Other things
What about input and sound, you might ask? Well, I can't fault the input handling really. But the sound handling has the same problem as the graphics - it's implemented at TOO low a level to really be useful - hence why many SDL games use SDL_mixer or something.
Alternatives
For software rendering, of course, you can bolt on the numerous extra software-rendering libraries (SDL_gfx and its friends) - provided you can get them to work on the range of platforms you intend to develop on.
You could also just use Allegro instead - I know the API is somewhat idiosynchratic - I know that *some* of its functions are somewhat obsolete (fixed point maths) - but the software rendering functions are solid, and pretty much WORK. It's all one lump. You don't need anything else.
If you just want an OpenGL context, why not use one of the libraries that just does that instead? Like GLFW, which is nearly as portable as SDL, and much more straightforward to use, opengl-wise (it doesn't pretend to do software rendering).
Mark
