Quote:Original post by Lazy Foo
despite being slow and lacking in features, SDL a sexcellent learning tool.
Its freakishly easy to use, and its a good stepping stone to OGL.

1) Slow and lacking in features, eh... could you give us some examples, please?
2) You're right, it's a great stepping stone to OpenGL, which is probably why so many beginners learn it, apart from the fact that it's easy to use.
3) What exactly does "sexcellent" mean? Does this have anything to do with "Direct Sex"?

SDL does what it does just fine. Once you get a hang of it, it is a breeze and 'dissapears' in your code. It is extremely cross platform and just works, very well.

I think the lack of graphics primitives in SDL (You get a rectangle-fill and a surface blit, with a set-pixel example in the docs) is a strength, and not a weakness.

SDL, it seems, was designed to reliably and cross-platformly get you a window you can draw on. (as well as similar basic stuff for audio and input.)

By making SDL as small and simple as possible, you get the most portability. (Go look through the SDL docs for "Only works on win32" or "Only works on unix". I can only think of two places you'll see that, now go and compare against Allegro or any major scripting language's default library)

For all the extra needs you may have, there are plenty of libraries that work with it.
Want graphics primitives? SDL_gfx or SDL_draw.
Easier handling of sound/lossy sound formats? SDL_mixer.
Image loading? SDL_image.
Font loading/drawing? SDL_ttf.

Having this all in extension libraries makes it a little more complex to build, but lets them evolve at different paces and helps with file size.

For example, say I wrote a DOS game a while back, and I want to make it cross-platform. SDL gets me the window up and running, but what do I need SDL_image for? I've already written an image loader. Same goes for SDL_ttf.

SDL_gfx/SDL_draw? If I'm porting from DOS, I've already written my own specialized blitting/draw routines, I just need to convert them to write to SDL_Surface->pixels instead of a framebuffer address.

An "all in one" version of SDL would be at least 5 times the size, and wouldn't help me at all for this kind of game.

An even better argument against SDL including a software drawing engine is OpenGL. SDL can get me a OpenGL window (on the three platforms I develop on... so "Do it yourself" would be a pain. And have you SEEN win32api? I much prefer the cleanness of SDL to what I'd have to do to get an OpenGL window up on win32), but why would I need a software renderer then?
I've got a (possibly hardware-accellerated) renderer that's much more powerful than anything SDL would include.

Hello, Beginner here.

I had been dying to get into graphics/game programming for a while but was always stuck on the "outside" knowing only about algorithms and programming in general but not knowing how to interact with video hardware.

I only wanted to develop on Linux but wanted my code to be fairly portable as one of my programming buddies will be working on a joint project with me using Windows.

After some hacking about with Kdevelop and anjuta IDE's (getting errors from hell) I finally decided to do it the hard way, get to the command line, use make and GCC along with SDL and learn a bit.

I hunted down tutorials fit for a newbie from non other than Sol the teaching god (http://sol.planet-d.net/gp/index.html) and in no time I was creating surfaces, changing modes and plotting pixels. Within a couple of hours I had flattened a C++ Bresenham line drawing algorithm from a 10 year old book into C and had some primitives on the go. after a few hours with SDL and Sol's help I had managed to get a foot in the door on very basic graphics programming at a fairly useful low level.

I must admit I was very confused by Sam Lantinga's typedefs such as Unit32 and stuff but once I had them sussed I was well on my way and am happlily progressing.

This is kids stuff to the advanced graphics and game programmers amongst you but to me SDL gave me a lifeline in a way I could understand without using too much abstraction. I am taking a beginners graphics module next academic year so hopefully I will have a head start having used GCC/SDL and some drawing algorithms.

SDL is alright by me.

Quote:Original post by DrSoCold
I must admit I was very confused by Sam Lantinga's typedefs such as Unit32 and stuff but once I had them sussed I was well on my way and am happlily progressing.

I believe SDL defines it's own data types so that they are the same size across the different platforms - so you know that by using Uint32 you are guaranteed to have a 32-bit unsigned integer regardless of platform specifics. They make be a little awkward to get used to but they are there for a purpose, not just for the sake of it.