Slashdot Mirror
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?"
Check out Loki, 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.. 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?
Don't think of it as a flame---it's more like an argument that does 3d6 fire damage
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.
If tits were wings it'd be flying around.
I wondering if there is any support for force-feedback devices under *nix. DirectInput is the layer under DirectX 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...
-- "I am disrespectful to dirt. Can you not see that I am serious!"
I presented a two-part talk on programming in SDL to my local Linux users group a bit over a year ago.
;)
Check out part1, and then part2.
Be warned.. it's a bit dated. But it should be useful for the SDL-hacker-wannabe's
Anyone have any cool ideas for an educational game? 3D Zoombeanies? A FPS Algebra tutorial?
SuperID
Free Database Hosting
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-- 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 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
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.
Sigs are awesome huh?
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 - at least a month into the actual coding of the thing.
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:
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:
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. 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.
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.
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".
The truth about Michael
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 "______"!