Sign in to follow this  
markr

SDL and why I don't like it

Recommended Posts

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

Share this post


Link to post
Share on other sites
Quote:
Original post by markr
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.

This seems to be the bottom line of your first point: A lot of SDL functionality is available only through add-ons which are tricky to build.

This is obviously a problem, but I have trouble seeing it as any more than a minor one. How long did it take you to iron out the build process? 2 hours? That's 4% of the total contest time. And in a normal situation, of course, the percentage would be much less. In an ideal world, all libraries will install and build seamlessly... but when they don't, it's usually only a problem when starting out.

The moral of the story: If you're going to be doing a 48-hour development competition, get your ducks in a row BEFORE the contest begins. I mean, you didn't wait until the contest started to install GCC, right?

Quote:
Great - EXCEPT, this confuses newbies, who are constantly asking "Why does XXX software rendering function in SDL, not work in GL mode properly" ?

That's reasonable... I'd like to see the runtime spit out warnings when 2D SDL graphics calls are made while in GL mode.

Share this post


Link to post
Share on other sites
Mark, you bring up some very good points, but you miss the concept as a whole. SDL is not going to hold your hand, it isn't going to do anything but enable you. And that is something it does very well.

Allegro is a horible sloppy mess, and it makes me cringe when i look through sample code. all I have to say is, END_OF_MAIN(); Macro trickery is the devil. There is that, and allegro doesn't prefix any of their functions, so chances of namespace collisions are freaking huge.

I see no problem with the add on libraries. Most of them are fairly well documented, and all have similar syntax. Once you learn SDL_Mixer, you can learn SDL_ttf, or SDL_Image.

And why were you building all the libs from scratch? There are binaries for Windows...

Share this post


Link to post
Share on other sites
Works fine for me, and it's a hell of a lot easier to set up a quick application than Directx.

Granted, DirectX totally blows SDL away with it's power, but I'm not going to be doing any 3D WOW games any time soon.

Gardon

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by Gardon
Works fine for me, and it's a hell of a lot easier to set up a quick application than Directx.

Granted, DirectX totally blows SDL away with it's power, but I'm not going to be doing any 3D WOW games any time soon.

Gardon


???

with OpenGl (through SDL ) you can get 3D WOW games if you want.
&& on most platforms( practically ).

i like SDL && i ike the fact that it's segregated, that way i only include the stuff i need, and
i suppose it would make the library build times shorter. i've been using it for a few
months, and i never needed to build it or any of the "major" companion librarys.



Share this post


Link to post
Share on other sites
Not to jump TOO hard on the bandwagon...:)

I think the goal of SDL (originally) *was* to be used as an abstracted layer for software rendering.

A lot (a lot) of successfull indie projects have used SDL, and nobody has problems getting anything hooked up properly with OpenGL..

It takes what? 5-8 lines of code to find a pixelformat and create a surface for OpenGL?

SDL is a breath of fresh air.


Share this post


Link to post
Share on other sites
Recently, I've been developing a project using SDL. The conclusion I have is that there is no point in using SDL, if the only things you want it do with it is creating a window and OpenGL context. You can do that on your own as well - and it's not much difficult at all.

Further more, SDL_Timer is nothing you should think of when making a serious game. It's simply lacking precision. Instead, you should go for same platform-specific performance counters.

I don't use SDL_image or SDL_whatever at all, since they only complicate the stuff. There are plenty of other libraries offering a better support and more features.

SDL_Input is not that bad but I've noticed some delays when handling keyboard events.

Generally, I am not really a proponent of SDL but still - it's quite simple library which completly satisfies needs of an amatour's game. That's why I use it. ;)

Cheers'

Share this post


Link to post
Share on other sites
Quote:
Original post by clapton
Recently, I've been developing a project using SDL. The conclusion I have is that there is no point in using SDL, if the only things you want it do with it is creating a window and OpenGL context. You can do that on your own as well - and it's not much difficult at all.


Yes, you can do it yourself on Win32, Linux, MacOS X, BeOS, IRIX, Unix, FreeBSD, OpenBSD, Solaris, MacOS classic etc. - you can once again reinvent wheel.

Quote:

Further more, SDL_Timer is nothing you should think of when making a serious game. It's simply lacking precision. Instead, you should go for same platform-specific performance counters.


You can't have portable timer with resolution better than 1 milisecond on all comptuters - and that's what SDL gives.

Btw, if you are interested, developers are planning to use RTDSC on x86 platforms in next versions of SDL.

Quote:

I don't use SDL_image or SDL_whatever at all, since they only complicate the stuff. There are plenty of other libraries offering a better support and more features.


They complicate stuff???? Man, you must be blind.

With SDL_Image the only thing that you have to do, in order to load: PNG, GIF, JPEG, TIF, TGA, BMP, PCX, PNM, XCF or XPM is use this function:

SDL_Surface * IMG_Load(const char *file);

It spits out newly created SDL_Surface, or 0 when error occured. It's compatible with all 32, 24, 16 and 8 bits versions of aforementioned image formats. You call that complicated???

Ok, SDL_TTF is a little different story... but you said that SDL_Image is complicated, which simply isn't true.

Quote:

Generally, I am not really a proponent of SDL but still - it's quite simple library which completly satisfies needs of an amatour's game. That's why I use it. ;)

Cheers'


You call Neverwinter Nights amatour's game? ;-)

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by PnP Bios
Um, like almost all linux ports of windows games use SDL.


It's a damn sight easier than working with OpenGL, which takes longer. And also OpenGL's just a graphics library, SDL provides the keyboard inputs etc.

Share this post


Link to post
Share on other sites
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"?

Share this post


Link to post
Share on other sites
Quote:
Original post by Oberon_Command
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?
3) What exactly does "sexcellent" mean? Does this have anything to do with "Direct Sex"?


1) I'm solely talking about the rendering.

Lack of decent hardware accelleration is just ...ew, no built in rotation, shapes or stretch blitting is also a draw back.

Which doesn't really matter because SDL's rendering is game development's version of training wheels. SDL's true power is its easy and cross platform capabilities is OpenGL.

3) Its a pun combining "sex" and "excellent".

Share this post


Link to post
Share on other sites
Quote:
Original post by markr
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)

Quote:
sdl homepage
Simple DirectMedia Layer is a cross-platform multimedia library designed to provide low level access to audio, keyboard, mouse, joystick, 3D hardware via OpenGL, and 2D video framebuffer.

Quote:
Original post by markr
You could also just use Allegro instead...

Quote:
allegro homepage
Allegro is a game programming library...

sdl is meant to provide low level access while allegro is a full blown game library. i haven't used allegro, but i know sdl does what it's supposed to do just fine.

Share this post


Link to post
Share on other sites
I can honestly say I am somewhat of an OpenGL newbie (although I am continually reading up and learning). I find SDL as a great help, especially in the cross-platform area. SDL_Net, also, is absolutely gorgeous for network programming, otherwise you'd have to do alot of OS-dependant things (especially for Windows). SDL_ttf, though, is a bit troublesome (I'm having problems currently as a matter of fact) and SDL_image seems to be a great alternative to custom functions and DevIL.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
SDL is a great GFX API, I cant imagine life without it, and it hooks right into GL, doesn't get much better than that, I do admit that I dont like SDL_ttf, or SFont/BFont(do people still use those?), but everything else is great, never used SDL_gfx, or SDL_Input, and what is this about it being slow? I just could never learn directx because I couldn't stay awake past the PRESENTPARAMETERS. The DirectX API is HUGE and Windows Only, SDL is small and portable,
it wins anyday.

Share this post


Link to post
Share on other sites
I just wanted to say that I think SDL is a great base to work from. I don't think it is something for beginners but rather a great starting point when you wanna do a portable game. If you are newbie I think allegro is supperior considering it is a game-library and SDL is not...

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by TravisWells


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.



Um... No it wouldn't. libSDL_ttf = 50k, libSDL_image = 80k, libSDL_gfx = 70k, libSDL_net = 12k.

Share this post


Link to post
Share on other sites
1) Allegro DOES NOT support NETWORK or MULTI-THREADING and it never will as long as it compiles to DOS (well, unless they program a kernel and full ppp+tcpip+modem/ethernet drivers into it).

2) Allegro has some outdated techniques (RLE sprites? palette? Flic?).
If I am not mistaken, Allegro's polygon drawing is software rendered(!!!) so superslow compared to graphic card (hardware) rendering.

3) I dont plan to use lines/splines/circles etc in my game, but if i will then i can use sdl_gfx.

4) I want GUI in my game, but Allegro's built in GUI that is just the most aweful ugly lamest thing.

The *only* thing that Allegro got for it is that it is more noob-friendly (just unzip and you get all the features + tutorials and examples of how to use them). If you are a 14 year old trying to make your first pacman clone then maybe allegro is the place to start (thats where i got my allegro knowledge :) ).

I started my game (noname yet)a week ago and so far im happy with my choice to start from SDL. Without problems I got openGL quads for tiles and sprites and keyboard handling (and im a complete openGL noob).

I havent tried the sound/music/fonts/gui/joystick/network yet, so maybe ill be anti SDL in a few weeks...

Iftah.

[Edited by - Iftah on August 10, 2005 4:17:06 PM]

Share this post


Link to post
Share on other sites
Yuck to allegro. but, yes... I do like some GLFW better than SDL.
I guess if I was going to do a sprite game or something like that I could go for SDL, though. I don't agree that it's as bad as the OP described. I know I learned SDL easily and I trust SDL_gfx would be easy enough to learn. I even learned the SDL_net stuff once... before I even knew how to use sockets. heh.
I do think GLFW is underrated though. It is very comfortable to use and the documentation is sexcellent.

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.
Sign in to follow this