Game Programming w/ the Simple Directmedia Layer?

wrinkledshirt asks: "I've just started programming with SDL for a game I've been wanting to make for a long time, and I've been making really quick work of it. The libraries and API are excellently designed and the project documentation is great. After banging my head against DirectX and even OpenGL for a while, this comes as a great relief, and I love the fact that my game will eventually run on Linux (and Windows, and FreeBSD, and Be, and MacOS, etc.). Still, I'm really early on in development, and even though I haven't had any problems yet, I'm wondering if I will, namely in performance. My question is this, how many programmers out there are tinkering or hacking or professionally coding with the SDL? How does it perform as the project gets bigger? How does it rank as a game programming library? Will it eventually be Linux's answer to DirectX?"

See Loki.

Check out Loki [lokigames.com], since they wrote (or at least have done heavy development) on SDL exactly for the purpose of porting "professional" games. Get some of their demos; buy some of their games. Just last week or so I got Descent 3, Terminus, and Soldier of Fortune (for about $10 each from ebgames [ebworld.com].. can't pass up a deal like that), and am highly impressed with the quality. Pop in the SoF CD, run the cute little graphical installer, and go. It works. Flawlessly. Terminus too. (Actually that's slightly inaccurate, there were some minor GL problems with the G400 drivers in 32bpp mode that came up later, but switching to 16bpp seemed to fix them.) D3 I have problems with, related again to the XFree86 4.x G400 drivers, but still.

I've played some of their demos as well, and they're equally solid and polished. The SDL stuff is where it's at. Loki has proven it works for "real" games. The API and related packages you can get are great. Easy to install, easy to code for, flexible, Free(tm), portable, proven. What more could you ask for?

Just look at the games ...

The answer to this question is pretty simple to find: Have a look at the existing games that use it on multiple platforms, check them out, try them, test them, watch their performance.

Your game will probably encounter the same set of parameters in its lifecycle as some of the games on this list:

http://www.libsdl.org/games_db/games.php3">>LibS DL Games

So, use them as a good yardstick for your own works...

j.

Re:What about force-feedback?

Unfortunately that's a driver problem, not an SDL problem. The manufacturers who make force-feedback devices haven't released any drivers, specs, or hints that would allow us as Linux users to experience force feedback. If they had, we'd have it already.

Re:It was developed for use in commercial games

Well, we certainly did a ton of work on SDL when we worked there. Almost all of the API decisions were driven by our work. I wrote the initial OpenGL code for HG2 specifically, etc., etc.

But, yes, as mentioned elsewhere, Sam owns most of the copyright.

m.

aalib.

Nah. aalib. Or that nifty SVGAlib-emulating version of aalib. Much more portable than svgalib, and easier to set up. And it supports multimedia [take a look at hasciicam]

--

Re:Now if I only had an idea.........

Make a little beehive simulation. Like a SimBeehive.

Bees need to be allocated to: gathering nectar, building the nest, taking care of larvae, taking care of the queen, sitting at the entrance of the hive fanning their wings to cool it, defend the hive, mating, dancing, doing John Belushi killer bee imitations.

Disasters can include: disease, famine, death of flowers, honey bears, kids throwing rocks, queen dies, pesticides.

Allocate the wrong bees in the wrong amounts to the wrong jobs, and the batch of honey goes bad and everyone dies. Figure out how to relate to kids that this complicated balance of things is handled with great skill by unintelligent insects coordinating instinct and movement, bringing us a delicious breakfast treat.

What about force-feedback?

I wondering if there is any support for force-feedback devices under *nix. DirectInput [microsoft.com] is the layer under DirectX [microsoft.com] that handles communicating with the control devices (including force-feedback signals), but I wonder if SDL (or anything on *nix for that matter) supports anything of the sort...

SDL Tutorial

I presented a two-part talk on programming in SDL to my local Linux users group [lugod.org] a bit over a year ago.

Check out part1 [lugod.org], and then part2 [lugod.org].

Be warned.. it's a bit dated. But it should be useful for the SDL-hacker-wannabe's ;)

I'm no SDL expert

but I meet Sam at LokiHack99 and I can testify that he is a game expert and knows what it should be like.

I would think that it would be the game programmer's API by game programmers. Loki uses if for their stuff and that's proof enough to me that it's good.

There are lot's of things that use it also.

Now if I only had an idea.........

So many tools, so little creativity :)

Anyone have any cool ideas for an educational game? 3D Zoombeanies? A FPS Algebra tutorial?

SuperID

Free Database Hosting [freesql.org]

Re:You're kidding, right?

Sam developed SDL *before* Loki existed. That's one of the reasons I recommended him to Scott back when Scott was forming Loki and looking to hire his first programmer.
-- Dan Kegel [kegel.com]

SDL+OpenGL+GTK+=Sweet set of APIs

I am currently developing a Linux app to draw 3D charts and other visualisation elements.

Using SDL, OpenGL and GTK let me get an app up and running, with hardware-accelerated 3D in no time at all.

In this case, the GTK parts of the system are in a separate window - a 'control panel' type thing, and SDL/OpenGL simply handle drawing the 3D window. I'm not sure how well GTK and SDL/OpenGL interoperate when used in the same window.

GTK quite happily interoperates with an SDL event loop, which i use for mouse/keyboard events in the 3D window.

I couldn't be happier with SDL, and i reccommend it highly.

Game Programming with SDL

First, let me preface this by saying I haven't actually written code that used SDL before, although I have spent time writing Quake Mods [planetquake.com]-- I'm mostly distanced from the graphics APIs.

One of the best judges of an API's efficiency is the success of programs using it. Looking over the list [libsdl.org] is somewhat impressive. But most of the popular games are Loki Ports, and they've had a lot of experience with SDL already. I see very few popular non-Loki games on the list.

I think you can conlude two things from this. First, it's possible to get reasonable performance from SDL, and it's definitly a reasonable API. Second, SDL just doesn't have the same support community size as OpenGL or DirectX. I suspect that the biggest barrier to graphics programming is *not* how often you run into trouble with the API, but how many other people can help you out when trouble occurs. No matter what API you use, you *will* have issues to deal with. So the smaller community size is probably the biggest obstical that SDL has to overcome.

-Ted

SDL 1.3 is coming

Firstly I heartily agree that SDL is a dream to program in, I love it.

I haven't done any large projects in SDL, but I've heard the performance is quite good as Loki uses it for their porting efforts. Hey if it's good enough for commercial games.. er.. :)

One thing you should keep in mind is that SDL is currently undergoing a complete rewrite and architecture change for SDL version 1.3 which will include the SDL 2.0 API. It's currently a year and a half from stable release (says cheif SDL ninja Sam Lantinga), so it's a long time to wait but you might want to keep that in mind as you are designing your project.

SDL Is excellent...

I have done extensive programming with the SDL library. It is an excellent (and fast) choice for programming 2D graphics under linux (I haven't used it for 3D graphics yet, I am using PLIB for 3D graphics now).

The limiting factors of SDL performance are not really SDL itself, because it is a very light API, but rather the limitations of X itself. My experience with SDL is that it provides at most a 2% performance degredation.

Furthermore, SDL is a wonderful cross-platform library that I have used extensively under both Windows and Linux. They also provide a cross compiler that lets you compile a windows executable under linux!

If you are considering SDL for 2D programming, I can say it is probably the best out there for speed, portability and ease of use. If you want to do 3D programming, you can either use SDL or some of the others out there, like plib [sourceforge.net].

--
Twivel

It was developed for use in commercial games

SDL was developed by Loki to simplify their own job - porting standard commercial games from Windows to Linux. Thus, it's already being used for "professional" project with cutting-edge, commercial games and is proven technology - at least on the Linux platform.

cross-platform compiling

I have been writing a game using SDL (with opengl) for the last month or two. As it as been growing, we havent seen any noticeable performance problems with using SDL (infact, the only problems have been with bad coding on our part sometimes - oops). What I was most impressed with was how easy it was to get something originally designed to run in sparc-solaris to work in win32 just by cross compiling and following a few simple instructions from this page [libsdl.org] - at least a month into the actual coding of the thing.

SDL is just a buffer.

It's a buffering layer with access to acceleration when necessary. There are other libraries that assist it for the actual, well, game stuff.

SDL pretty much does all this:

• Handles the video buffer, as well as GL contexts
• Image blitting, with alpha (this does not include loading/saving)
• Keyboard, mouse, and joystick input
• A threaded audio buffer ('pull' model)
• Limited CD access
• Timers
• File i/o handlers
• Accelerates any of the above when applicable.
• Probably a few I've forgotten.

This really isn't a game development library by itself: There are no image loaders, nor are there any image rotation/flip code, nor are there.. well, alot of things you'd need for a 2D game. There are other, supplemental libraries for this:

• SDL_image - A wide assortment of image loaders. Nothing to save with, though.
• SDL_mixer - Libmikmod, smpeg, ogg vorbis, and timidity. In other words, plays every sound file known to man, links into the audio buffer.
• SDL_net - Portable networking library (haven't tested it myself)

There are also a few rendering and UI libraries in the works. There may even be a few finished, I'm really not sure. But, if you're going to use SDL for game development, don't expect it to do _everything._

But if you're developing one, it's probably better to get your hands dirty and learn how to do the rendering stuff yourself anyway. It's not really all that hard: I've got a bunch in mine. [sandwich.net] Digging out Abrash's book, which was recently posted here, should help with some of the other renderers (polygonal, bresenham, etc.) that are fairly interesting.

Cross Language Too

While thinking about the cross-platform abilities of the SDL library, don't also forget the cross-development-language options that are available. Currently there are bindings (at various levels of progress) for Ada, Eiffel, Euphoria, ML, OCaml, Perl, and Python.

As the maintainer of pygame, the python binding, I believe it is one of the furthest along. This week will mark the release of pygame-1.0, and there is already a good community forming, (and projects being released).

Check out pygame at http://pygame.seul.org [seul.org].

sdl info

SDL has very good performance. On Linux, it uses the framebuffer or X depending on how it's compiled. In X it uses DGA, a 2D graphics acceleration mechanism. Note that SDL does not do 3D graphics, but has hooks for OpenGL in it, which does do 3D. In Win32, it looks first for the DirectX libs when compiling. If it finds them, all it's blitting operations are performed through DirectDraw. In all x86 platforms which support it, MMX instructions are used for optimization.
You could have found this out too, if you had simply looked at the code instead of "Asking Slashdot".

Did you say OpenGL?

Watch what you say, before SGI declares message threads using the term "OpenGL" their intellectual property. Perhaps we should call it "Open__". No, that contains "Open", so they'll probably start a lawsuit. Maybe "____GL". No, that contains "GL" and that'll piss them off. Alright, "Open__" and "____GL" might be SGI's, but we can always use "______"!