Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Games Entertainment

Game Programming w/ the Simple Directmedia Layer? 163

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?"
This discussion has been archived. No new comments can be posted.

Game Programming w/ the Simple Directmedia Layer?

Comments Filter:
  • by Anonymous Coward
    This is perhaps off the topic but I'll tell you where we use SDL. We're using it to design an OpenGL like library for embedded systems. We can simulate our graphic library on many different platforms, thanks to SDL.
  • by Anonymous Coward
    That sure would be a bummer if it only ran on Windows, since only 95% of the population could use it.
    Actually, one cool thing about SDL is that it runs on BOTH the latest DirectX versions and DirectX 3 or so.

    This means that you don't have to have WindowsXP2004 just to run the game, it also runs on a plain-jane NT 4, among others.

    And you get all that platform support, effectively, for free.

    Let me guess, you've never written DirectX code, have you? (Obviously not, if you think SDL is complicated and DirectX isn't...)

  • by Anonymous Coward
    AFAIK, the force-feedback mechanisms use proprietary protocols, and the manufacturers have refused to release information about those devices.

    On the other hand, look at this: ir.html []

    Now that's force-feedback.

    Oh, and it was 3 networked boxen (one per display), running Linux. The controls are as shown on the bottom of the page -- a flight yoke and rudder pedals (both USB).

  • by Anonymous Coward
    Bit more obscure facts: SDL lets you store pixmaps in either video or main memory, easily supports half of a program being "SDL-ized" (like just using SDL for video), can do threads, supports a lot of neat stuff through environment variables (my favs are YUV hardware overlays...hardware MPEG scaling!, and sending sound through esound). It's extremely thin, but there are libraries that sit on it. It's a very good library, but I can't vouch for the quality of the other "higher level" libraries that you might want to mixer, image-loading, and image primitive libraries.
  • Go to the and see SGI/IBM & Co. developing the OpenML - incorporates OpenGL, audio and media - the cross-platform version of DirectX.
  • by Anonymous Coward
    But what other gamemaker has come out with decent games using SDL?

    Loki has used it in every title except Quake 3, which (IMO) shows a great deal of scalability. CTP to Tribes 2? Oh, yeah!

    Hyperion used it for both Sin and Shogo.

    Vicarious Visions used it for Terminus.

    It was used for Hopkins:FBI. (You remember, the first Linux commercial boxed game. [])

    It was used for the Descent 1 and 2 ports of the old source.

    It's used for exult (which lets you play Ultima 7 and U7: Serpent Isle under Windows and Linux).

    It's used for Heretic 1 and Hexen under Linux.

    Doom has been ported using it.

    Maelstrom was ported using it (by Sam Lantinga, in fact).

    OpenUT uses it, and used it before Daniel Vogel was hired by Loki.

    QuakeForge uses it.

    The Linux release of Raptor uses it.

    Reel Deal Slots (another commercial game) uses it.

    In addition, it has been used to great effect in a large number of other games ( [] for one) as well.

    Just look at []

    Frankly, I'd say that's a hell of a lot more than the "primary sponsor" of the library using it. It can't be all bad.

    (BTW: did you notice the hold-out? TribSoft did not use it for Jagged Alliance 2. In fact, that's the only commercially-available separate Linux boxed game currently available which doesn't use it.)

  • by Anonymous Coward
    Of course it's a layer. That's the whole point. You don't need to get in to the details of every architecture and os layer, speeding up the implementation/porting considerably, leaving the ugly parts outside your own code and letting you focus on logic instead of making the fundamentals working each time. I personally don't think the SDL developers are having as a goal to replace DirectX with SDL/win32, but they are indeed making it less horrible to work with.
  • by oGMo ( 379 ) on Wednesday April 04, 2001 @03:01PM (#314276)

    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?

  • 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:">>LibS DL Games

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

  • Just because I'm a pedant, and one of the programmers of Terminus, I feel the need to point out that Terminus was made by Vicarious Visions. We did use the Loki installer for the Linux version, which probably led to your confusion, but you should have seen the big phat VV logo we put on there, anyway... ;)

    When we decided to go cross-platform we seriously considered using SDL. Unfortunately, at the time the Macintosh support was not all there. (I'm not sure if that's still the case. I hope someone replies to clarify.)

    But in order to stay on topic, I'll add my voice to the chorus that says Sam rocks, and SDL rocks! :)

  • There are other companies using it. For one, Vicarious Visions used it in the Linux version of Terminus (actually, I think they used it for all of the ports, but I'm not 100%), and it works very well for them.
    Hi! Terminus developer, here. I responded in another thread, but I've got karma to burn, so here's a redundant post. Terminus uses the Loki installer, but not SDL. (Because SDL support on the Macintosh wasn't so hot.) So all of the ports (Windows, Mac, Linux) were 100% VV koding.
  • The open source version of Marathon [] has been adapted to SDL. This has allowed Windows and Linux versions of the previously Macintosh-only game.

  • A bit rambling, but hang on...

    I originally started using SDL when I was seeking out a replacement for GLUT back in the SDL 1.0 days when I was starting to learn OpenGL. After a bit of playing around I found that that functionality was only available in the 1.1 dev series (1.2 as of last month!).

    I believe I stumbled on something truly great. I've made small toys that compile in Windows with Visual C++ (gotta pay the bills, game developers) and in a GNU/Linux environment.

    There is a lot of focus on the fact that SDL gives you low level access to a framebuffer. It's input handling routines should also be mentioned. Take a look af the port of Quake to SDL. The mouse and keyboard are handled quite well.

    I examined the SDLQuake source code, and figured out how Sam got Quake style movement with SDL. I then used that to create a basic "framework" for OpenGL scenes. SDL lets me write easily cross platform code for moving around a scene Quake-style, which you couldn't do with the limited input commands that Glut gives you. Not bad for small experiments.

    My only beef with this library so far is that major game companies don't use this tech in house as a replacement for DirectX (which it wraps around if it's available in Win32 anyway).

  • I have been watching the development of SDL since I first saw it mentioned on Freshmeat (at 0.7). I have been on the SDL mailing [mailto] list ever since, and I can tell you that SDL is probably your best bet for a fast, lightweight, cross-platform game programming library that's not going to get in your way. Right now it runs on (Source compatible) Linux, FreeBSD, Windows (Using Direct X), BeOS, and Mac. I can also tell you that there are tons of people on the SDL mailing lists, and they're not all Loki employees.

    I took a look at a lot of other game programming libraries when I was first investigating SDL, I didn't just jump blindly into it. SDL isn't the answer to all game writing woes, and it could even be too low level for what a lot of people want, but it is fast, light, and since it's written in C, it can be incorporated into most anything.

    If you want more information on SDL, I would recommend checking out their website: []. It lists quite a few of the projects (Both game and otherwise) that SDL is being used in. I counted more than a hundred. A few of the highlights:

    Most of the Loki games.
    Descent 1x [], 2x []
    Freecraft []
    OpenUT []
    Several DOOM and Quake projects

    Also, for those of you who want something a little higher-level, SDL has several game programming libraries [] built on top of it:
    BUILD Engine []
    GUIlib []
    PowerPak []
  • Not entirely true. Most of the Quake3 development was done by id Software, but after their Linux guru split to develop for the Dolphin/Game Cube (I forget his name) they turned control of the Linux port over to Loki, who has been maintaining it (Granted, with more involvement than they're used to from the original developer) ever since.
  • Another word-of-mouth rumor-mongering Slashdot post.

    Game programming is hard by nature. I have seen tons of programmers on the SDL mailing lists asking how to improve the performance of their games.

    And Loki is not the only professional development house using it, but how many here have taken the time and energy to look into some of the lesser known Linux development houses? And how many of those houses (For those who did look) advertise that they use(d) SDL on any of their projects?
  • This has already been said in this article, but most people don't bother to read replies unless those replies are to comments they posted, so I'll say it again.

    SDL was not started by Loki games. Sam Lantinga was working on SDL for over a year when he and Scott Draker founded the company with the other members of their team. Now SDL has prospered because of Loki's sponsorship, but it was not "developed by loki to simplify their own job."
  • by kwalker ( 1383 ) on Wednesday April 04, 2001 @03:55PM (#314286) Journal
    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.
  • Please remember that SDL development was done mostly by the lead programmer for Loki [].
    If you all want more work to be done on it, go buy Loki games (from Loki themselves or one of their resellers like everythinglinux [] or Tux Games []. Without Loki, there will be much slower development of SDL
  • David 'Zoid' Kirch. Now works at Retro Games, a 2nd party developer for Nintendo.

  • Yes, it's worth noting that Loki does not own SDL, Sam owns most of the copyright. He had started it before working at Loki.

    (who was the lead on SoF, thanks for the compliments ;) )
  • by MichaelKVance ( 1663 ) on Wednesday April 04, 2001 @05:02PM (#314290)
    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.

  • So SDL 2.0 will be ready before Alpha Centari?

  • SDL existed for quite a while prior to Loki coming into existance. I recall a FAQ item from prior to the website redesign that taked about whether or not Sam's job with Loki would interfere with continued development of SDL.
  • There are other companies using it. For one, Vicarious Visions used it in the Linux version of Terminus (actually, I think they used it for all of the ports, but I'm not 100%), and it works very well for them.

    And you're right, it was a fair question, so the first poster was a bit of a jerk. Then again, the question of whether SDL could be used to good effect in games is answered by Quake3 etc.
  • by don.g ( 6394 ) <don.dis@org@nz> on Wednesday April 04, 2001 @02:58PM (#314295) Homepage
    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]

  • You are mostly right but Quake 3 has no SDL in it whatsoever. ID software did the whole thing and Loki distributes it. Soldier of Fortune does have SDL though.... Leimy
  • The LGPL appears to state that if you link to a LGPL'd library it must be of dynamic linkage otherwise your work becomes a derivative work and must also be LGPL'd. All LGPL'd works must have source distributions available. Re-read the license about 10 times and you will have a chance at understanding it.

  • I looked at SDL, and it does really seem to be awesome at handling things that can otherwise be very difficult to handle yourself.

    Does anyone have any arguments agains using something like Qt with their OpenGL and they Canvas widgets? Lots of games don't need to be programmed at the very low level of "put this image here" and "draw this pixel here" particularly the user interface parts of games. The Qt canvas also has sprites that can be bitmaps, and can move by themselves. They can even do collision detection. Wouldn't this higher level library be a bit easier for people to get into game programming? I see a lot of people asking questions about how to program games, because they are baffled by the complexity of figuring out the details of their video card. These same programmers can certainly handle something higher level, like "put this image here, and move it in this direction, and let me know if it hits something."

  • GODDAMN! I thought the stupidest guy in the world wasn't on /.

    I guess I was wrong.

    Ever play a game? I once played one that simulated a nuclear reactor. It was fun. I bet you would have hated it. You would have bitched "but that's WAY different than reality. In reality, there would be all these men that look like Homer Simpson running the frickin reactor. A realistic simulation would be extremely boring because you would sit there and watch the Homers run the plant with some difficulty."

  • 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.

  • haha! so many tools, so little creativity sums up how ive been feeling about games for the last year. I'd like to bring back something along the lines C-Robots. Using a small easy to learn lanugage to interact with scripts written by others.
  • But what other gamemaker has come out with decent games using SDL? Maybe it's such a pain to wring good performance out of it that only its primary sponsor has had any success with it, while any newcomers are due for a rude awakening. I have no idea whether or not that's the case, but that's part of the reason why it was submitted to Ask Slashdot and why your grumbling was uncalled for. If a wide range of companies were succeeding with SDL, sure, but since there seems to be only one, it's a fair question.


  • I've got a pretty cool input device I'm trying to support. It's the Spaceball 4000 FLX [] - a 6 degrees of freedom motion controller. The software provided with it does not support Linux (just a few commercial unices and windows, and the apis are different in each case). There's a linux joystick driver for it but I have not been able to get it to work because it "couldn't set up serial line discipline" (which IS loaded).

    Anyone know if there is support for this in SDL? Or if not, what is the best way to support this device? I'm writing a program which I intend to be cross platform and right now I'm considering talking directly to the thing through the serial port and figuring out its protocol. (I haven't been able to find it published anywhere).


  • A quick hack (from Z []) that helps get the 4000 FLX running:

    [it] works wonderfully, iff you power-up the spaceball during the ~5 second timeout of the jsattach program. Try the following to make this easier:

    ( while ! jsattach --sball4 /dev/ttyS0 ; do : ; done ; ) &

    Note that /dev/js0 was the device being used to communicate with the driver - jsattach effectively binds /dev/js0 to /dev/ttyS0.

    jscal was useful, although even that didn't allow me to scale the Spaceball output to the insane levels Descent/Linux seems to expect. If Descent allowed higher sensitivity to be chosen, or the driver was a little more mature, it might work better.

  • Hah! That's clever, wish I had mod points.
    I'd tackle that myself if I didn't have three projects to work on already.

    "If ignorance is bliss, may I never be happy.
    • 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.

    Does SDL have a method to maintain backwards-compatibility with newer versions? For instance, DirectX has been re-architected several times, yet software written to earlier versions (even as far back as v1) will run just fine on the latest (DX8 as of now). Can SDL do this, or will each major version require either rewriting old code or keeping around old libs?

    How would one even go about doing something like this (without doing lib versioning. I know that's possible, but it's not always practical) in a unix environment? DirectX maintains interface coherency by using COM, but COM is much lighter than CORBA, so CORBA's probably not an option (performance issues). What other possibilities exist? Maybe using an object model from some other project like KDE's KOM, Mozilla's XPCOM, and what else?

  • []

    (Are you sure you included a URL? Didja test them for typos?)
  • I suppose this means that SDL would need to add support for pluggable joystick modules. At leat that way it would be a doorway for the games developers to add force feedback to SDL based games.
  • by leperjuice ( 18261 ) on Wednesday April 04, 2001 @02:57PM (#314309)
    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...
  • After toying around with Xlib for a few years, SDL emerged. I initially started using it because of it's sound support (it could play MOD music files!), and eventually, as I started writing more projects, I used it for everything.

    It's low-level enough for non-OPP-ing folks like myself... that's the most important part for me.

    You can see my games here: []
  • SDL provides support for mouse and joystick. It also supports MIDI, MOD, MP3, WAV and I think Ogg Vorbis sound formats. It also supports BMP, GIF, PNG, TIF, JPG and other graphics formats. Ditto for timers. Ditto for being cross-platform. :)

    As for 3D math, packed data, and other things, not everything is necessary for every game. In fact, SDL is not a game library... it's a multimedia library.

    Because of this, SDL keeps everything "clean and simple." Internally it supports BMP and has some raw sound effects. If you want to roll your own or build an add-on library, you can. You're not weighed down by, say, MIDI support for a soundless application. ;)

    So, when I say SDL "supports GIF, PNG, MOD, MP3, MPEG, JPEG, etc.", what I actually mean is there are libraries which support these which are meant to be add-ons to SDL.

    That's why most of my games [] require things like SDL_mixer and SDL_image.
  • by Bill Kendrick ( 19287 ) <> on Wednesday April 04, 2001 @04:23PM (#314312) Homepage
    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 ;)
  • by Mr T ( 21709 ) on Wednesday April 04, 2001 @02:48PM (#314313) Homepage
    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.

  • SDL supports both aalib and SVGAlib as graphics library.

    From the loki Linux FAQ []:

    Q: Will svaglib, fbcon, glide, GGI, MGL, as a back-end be supported? []


    • SVGAlib, GGI and AAlib are supported as of SDL version 1.1.
    • fbcon is supported as of SDL version 1.0.
    • SDL 1.1 has support for OpenGL, but you can not use the SDL 2D video functions like SDL_BlitSurface() with a display surface created for OpenGL use.
    • MGL may be supported, eventually.
    • If you want to add the backend support for a particular API, take a look at SDL_sysvideo.h, as it contains the internal functions you need to implement. Also take a look at the other functional back-ends to see how a working implementation could be written. I've designed it so adding a back-end should be relatively straight-forward, it just takes a little time.
  • Quote from the Loki Win32 FAQ []

    Note the second line, it uses DirectX therefore it takes use of as much hardware acceleration as DirectX does.

    Q: Does it work? []

    A: Yes. SDL supports VC++ 5.0 and Cygnus Mingw32 [] under Win95 ©, Win98 ©, and Windows NT ©.

    SDL takes advantage of DirectX hardware acceleration when it is available, but falls back to the standard Win32 services if DirectX is not installed.

  • Loki Games, the primary (only?) sponsor of SDL development, created the library for use in their porting work. If you want to see whether or not SDL has what it takes to make it in "professional" software, go down to your local software store and buy the Linux versions of Soldier of Fortune, Quake 3 Arena, Myth 2 and a ton of other great games.

    I can't believe this question even made it to Ask Slashdot...


  • Don't you mean OOP?
  • Interesting, and I'll have to check it out.

    Lately I've been looking at CrystalSpace [] for a cross platform game environment.

    Its a cross-platform GPL 3D Engine that rocks.

    Warning: The whole structure is a major state of flux right now, as the codebase is in the process of moving into a much more modular and extensible state, and its probably 6-12 months to the 1.0 release (although the 0.18 release is very nice to play with).

    The DirectX Redering library is undergoing a complete revision (from supporting DX6.0 to DX8.0, and cleaning up/speeding up the code).

    It also includes a cross platform GUI/Widget set which was really neat to me since it means that an application can look the same no matter where it runs, since everything is within the app. Don't let the fact that its billed as a 3D engine fool you, its alot more then just that :)

    (and it has a rather active/friendly/helpfull mailing list that you can join at SourceForge [http])
  • When you develop games, cross-language means C/C++ with support for other *natural languages*. i.e. French, German, Spanish, etc.
  • My GridSlammer game engine uses SDL, and it has worked wonderfully for me. The API is well thought out, the feature set is good and quickly expanding, and it seems to make good use of underlying graphics hardware and drivers (framebuffer, XFree86 4.0, ...). The OpenAL sound stuff rocks. I could go on, but why not check it out yourself. I've seen a bunch of projects using it, and if mailing list volume is any indication, it has taken the reigns away from GGI as the cross platform graphics library with the most momentum behind it.


  • I was under the impression that this engine'd been dead for a great while. Great way advocate SDL's superiority, there.

    The reports of GridSLammer's death have been greatly exaggerated. :) Though I am not too suprised you got that impression, considering the lack of development from November to February (my work schedule was a bit crazy during that time period). I am happy to say, however, that we recently released a 0.7a version, and 0.8a is not far away. I expect to hit 1.0 in August. GridSlammer currently has three primary developers, but we can certainly use more help.



  • Wow... insidiously cool! :-)


  • no serial line disciple = need to modprobe serio and serport.
    If you want to know the protocol just look at the Linux kernel source. And there is a generic unix driver floating around somewhere. The kernel driver should work fine though.
  • I thought that SGI were cool with Mesa - didn't they offically make some statment about it in the last year?
  • YUV overlays provide YUV scaling, not MPEG scaling - there's no MPEG specific support.

    There are a few graphics cards that do provide hardware/firmware IDCT, but AFAIK there's no API to access this functionality under Linux, yet alone SDL support.
  • SDL itself doesn't (except maybe alpha transparency?) - just bitmaps to draw into. There are a bunch of "3rd party" SDL libraries though that provide drawing primitives, font rendering, widgets, etc.
  • I know someone was doing a Ruby "port" of the library, although largely based off of pygame.
  • The most important question about SDL is its ease of porting from DirectX. Since, let's face it, most games are written for Windows, the ease of porting will be a major, major factor in developers' decisions of whether or not to port.

  • The LGPL allows you to link against libraries without releasing source to part you wrote. If you use the libraries unchanged then the program you write that is linked against it is yours to license differently. However, if you find it necessary to patch a LGPL library to get it to work with your project then you have to release the changes to the library. Even if you patch a library and release the source to the altered library, you can still license the code you're linking against it separately.

    It's just like the GPL in that any change to an LGPLed library obligates you to release source to it when binaries are distributed. It is unlike the GPL in that it allows linking SEPARATE modules under a different license.

    Like the other posters, I recommend that you thoroughly read and comprehend the license before you use it.
  • by superid ( 46543 ) on Wednesday April 04, 2001 @03:15PM (#314330) Homepage
    So many tools, so little creativity :)

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


    Free Database Hosting []

  • by Dan Kegel ( 49814 ) on Wednesday April 04, 2001 @05:01PM (#314331)
    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 []
  • An Ask Slashdot that would actually be wise to ask Slashdot...
    Genius dies of the same blow that destroys liberty.
  • KDE and GNOME _both_ suck. They're too fat, period.
    Genius dies of the same blow that destroys liberty.
  • ... but not by very much!

    Quakeforge [], the next-generation QuakeWorld engine has SDL and SGL targets, and they run almost as fast as the svgalib target. They're certainly playable.

    Also, check out New Breed Software [], as they use SDL in pretty much everything.
    Genius dies of the same blow that destroys liberty.

  • Yeah, SGI is so mean, opening all their specs to the public and not making a bit of complaint about Mesa. Defending a trademark is typical and not evil.

    Just one of my pet peeves... =)
    Genius dies of the same blow that destroys liberty.
  • You can. Move out of the US where these things aren't enforceable (read: not legal).
    Genius dies of the same blow that destroys liberty.
  • Of course, if you want to know *specifically*, you should <A HREF=""> read the license</A>.
    Genius dies of the same blow that destroys liberty.
  • Aack! Should have used preview!

    Of course, if you want to know *specifically*, you should read the license [].
    Genius dies of the same blow that destroys liberty.

  • The Magic SysRq Keys are your friends.
    Genius dies of the same blow that destroys liberty.
  • And why, pray tell, does a developer's machine need to be on the internet browsing their website (which is what you need in order to be counted)? Development machines are typically standalone, with a windoze box in the other room which is never really used except to test win32 builds of software being built.
    Genius dies of the same blow that destroys liberty.
  • Learn from the Amiga. Use mods. See this [].
    Genius dies of the same blow that destroys liberty.
  • This app has no real requirement for a 'single window' approach.

    Like the GIMP, the ability to have multiple control panels for various aspects and operations on 'output windows' is more of a feature than a limitation in this instance.

    I am looking into gtkglarea, and it may be that i end up dropping SDL, but i mainly just wanted to put in my 2c about how well SDL does its job.

  • by ikekrull ( 59661 ) on Wednesday April 04, 2001 @03:43PM (#314345) Homepage
    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.
  • define the functionality of your class in an abstract base class and implement it in your class : >>>>>> That *is* COM. All the stuff around it is interapplication communication stuff (which is best done with messages anyway, since IA stuff is inherently asynchronus), and object framekwork stuff.
  • I think you should clarify the function numbering thing. The interface methods are (and always have been) unnumbered. Its the interfaces themselves that are numbered (IDirectDraw7 for example), which makes sense since interfaces are immutable.
  • by Ted V ( 67691 ) on Wednesday April 04, 2001 @02:53PM (#314350) Homepage
    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.

  • > The goal was to find out why companies weren't creating games and applications to run on multiple platforms.

    Why didn't you just ask the game developers? ;-)

    Windows has 95% of the PC games market for OS's. It's not up to the developer what OS to support, but the publisher! That's why you don't see Win2K listed much as "officially supported" on the side of the game box, even though, most likely the developers are developping under it. (I love how I can use multimon via my AGP GeForce2 and a PCI video card under Win2K. :)

    I'd like to smack the publishers that say Win2k isn't a gaming OS... hello, DX8 & the SDK work just fine under it. But this is another rant...
  • SDL is a cool library. It is nice to not have to worry about a lot of the 'details' in game/demo/media/whatever programming. It does have some problems, but they are arguably not it's fault:

    Performance: SDL does take advantage of hardware accelleration where it can (ie bitblts), but it is limited by the OS/environment it is running on. My impression is that windows device drivers, for example, do a much better job of this, than say, FBDEV.

    Maturity: SDL is a relatively new library, and although it has been used in some large projects (by real companies [loki]), it still has a ways to go. Of course, this is where SDL is also making its greatest strides.

    Industry support: This is the killer. The break or be broken issue. Direct* is well supported by all kinds of hardware devices (not just video, also sound and input devices). Until we can get really good support from the industry behind SDL, it will be lacking in comparison.

    The one wonderful thing that is quite uncommon in the free software world is that there seems to be one defacto standard for games programming (SDL obviously). Although there are MANY MANY alternatives (having written a few myself), it is VERY good to have a standard that people/companies can rally around. (/me tries to avoid bringing up KDE/gnome foolishness :)

    So anyways, yes, SDL is a good thing. Who knows, maybe Linux (and the other platforms SDL supports) will start getting more games out on them as primary platforms some day?

    -Chris []

  • No. I'm talking about the bugs you don't even know about. The tools/runtime environment of a single platform may not manifest them right out.

    Lots (and lots, unfortunately) of products ship a dot-oh version that must immediately be patched because unknown bugs turned up. In my experience cross-platform code will ship with fewer unknown bugs because the different runtime environments provide more stress on the code.

    Just my 2 cents, YMMV, maybe you know something special that I don't.
  • by jidar ( 83795 ) on Wednesday April 04, 2001 @02:51PM (#314358)
    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.
  • by twivel ( 89696 ) on Wednesday April 04, 2001 @03:52PM (#314359)
    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 [].


  • by teg ( 97890 ) on Wednesday April 04, 2001 @02:51PM (#314363) Homepage

    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.

  • 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.
  • Unfortunately most force-feedback sticks/paddles use I-Logic's I-Force protocol.

    Which is patented, closed, and not for release.
  • You're both wrong. The best gaming API is ncurses.
  • by Patrick McCarthy ( 126209 ) on Wednesday April 04, 2001 @03:02PM (#314375)

    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. [] 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.

  • I did a large research project for my college on Cross Platform Software Design. The goal was to find out why companies weren't creating games and applications to run on multiple platforms. Developers were running into a lot of different code level problems and one of our conclusions was that the SDL library handled almost all of these coding problems in making a portable game. The project can be found online in .pdf format here [].

    As a side note, the biggest problem people had in creating a cross platform game is supporting non-Windows operating systems.
  • Actually we did ask the game developers. We did a survey that took results from developers and random programmers on the internet together. We also got emails from the developers themselves. Most developers believe the time/money put into creating and supporting an application for another os besides windows is not cost effective. One of the suggestions I had for the support problem was to only support the application on Windows, then release a non-supported version for other OS's. You get the extra market share and most Linux users can figure out how to install and setup their programs themselves like they have been doing for years.
  • As of now there isn't any support implemented for it.

    Sam Lantinga answered that question in this [] post.

  • Allegro [] is another good game programming library.

    It is a bit more high level than SDL, providing functions from mouse & joystick access to MIDI and sound output, many different hardware accelerated blitting and drawing operations, interrupt driven timers, support for packed data, 3D math routines, and more. It is also ported to a lot of different platforms, and there are a number of add on libraries (including OpenGL rendering).

    It's been around for a number of years, but developement is still going strong.

    The [] site is a good resource for add on libraries and community news.

  • by shredwheat ( 199954 ) on Wednesday April 04, 2001 @03:11PM (#314392) Homepage
    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 [].
  • What kind of game are you working on?

    I've been playing with SDL on and off for about a year and a half now. Long ago, I wrote a VisualC-SDL intro, and submitted a bug fix. I've worked on BumpRace [], and am working on a game [] that I plan to port from ClanLib [] to SDL soon, just to chop the dependencies down and ditch C++.

    It sounds like you are talking about a home game programming project. If that's the case, then SDL should more than meet your need. In my experience, home game programmers tend to dramatically over-estimate their performance needs. Focus more on making your game do something interesting first.

    I don't meant to say SDL doesn't perform well; Hyperion ported Shogo to Linux using SDL [] (so, yes, companies other than Loki commercially using it), and Loki ported Tribes 2 and a zillion other games to Linux with SDL []...

    As for the user community for SDL; it's huge, and quite friendly. There are a lot of projects out there that build on SDL, and there are bindings for Python, Perl, and many other languages. (For casual readers: SDL itself is in C.)

    I really don't know what more you could ask for, except for it to become the world standard and have a dedicated hotline for support (DirectX). Other than that, it's all pretty much there.

  • sorryfor beeing too dumb to use preview .. :( to slashdot: a <pre> would be _really_ helpfull...

    you do not need to use a component model like com or corba to maintain interface coherence. in c, all you need is to provide all functions with the same signature. if you do feature upgrades which require additional parameters to a function, dont modify the existing one, add a new function with this additional parameter.

    also don't modify existing data structures, provide a new data structure with the extended information...

    if you use c++, dont use classes! if you functionality to your classes, even if they are privat, you change the signature of your class. instead use interface based programming. define the functionality of your class in an abstract base class and implement it in your class :

    class AbstractBase
    virtual void function1()= 0;
    virtual void function2()= 0;

    class Implementing : AbstractBase
    void function1()
    // do it
    void function2()
    // do it

    now you need a factory function which returns the AbstractBase pointer to the Implementing class:

    AbstractBase* createImplementingAsAbstractBase()
    return static_cast(new Implementing());

    this preserves, that only functions with constant signature and function-tables (that is the abstract base class) with constant signature are exported over library bounds.

    if you want to extend the class in the library with a new function you do this by creating a new Interface and factory function:

    class AbstractBase
    virtual void function1()= 0;
    virtual void function2()= 0;

    class AbstractBase2: AbstractBase
    virtual void function3()= 0;

    class Implementing : AbstractBase2
    void function1()
    // do it
    void function2()
    // do it
    void function3()
    // do it

    AbstractBase* createImplementingAsAbstractBase()
    return static_cast(new Implementing());

    AbstractBase2* createImplementingAsAbstractBase2()
    return static_cast(new Implementing());

    the signatures of the exported functions and function-tables are still constant, only a new function and a new function-table is added. now the old application can use the old factory and Interface (that is, what a abstract base class defines) and the new application aware of the newer library can use the new factory to get a new version of the interface, thus is able to use the new functionality.

    this should give you both source _and_ binary compatibility so that you just need to make softlinks for the files.

    but said all that.. i dont think, that the sdl 2.0 will be binary compatible.. it looks like a major redesign, so i even dont think it will be source compatible... in the first version of a library you typically play around, try things out and make quick hacks. at some point you think: "hey, that is weired and should be totally different... lets rewrite it from scratch" =)

  • by Pheersum ( 243554 ) on Wednesday April 04, 2001 @03:01PM (#314409) Homepage
    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".

  • SDL itself is what you suggested the original question asker to do. 95% of SDL is a simple abstraction layer over lower level system dependent APIs like DirectX, DGA, etc.

    There's some custom code in there for doing alpha blits and such on platforms where its not supported in hardware, but you dont have to use those, you can write your own.

    But by and large you're suggesting everyone should redo all the work SDL (and ClanLib for that matter) have already done.

    Oh and one other thing..There's a bunch of cool support libraries for SDL, including an MPEG player (including MP3), an image loaded library etc that can save you a lot of work from having to write your own.

  • Quake3 does not use SDL. In fact, Loki has nothing to do with the Linux version of Quake3. It was all developed in-house at Id.
  • by screwballicus ( 313964 ) on Wednesday April 04, 2001 @03:39PM (#314417)
    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 "______"!
  • Maturity: SDL is a relatively new library, and although it has been used in some large projects (by real companies [loki]), it still has a ways to go. Of course, this is where SDL is also making its greatest strides.

    Relatively new library? No offense, but me thinks thou art a "dumbass" ;-)

    SDL has been in the works for something like four years now. Any computer project that thrives and experiences pretty intense development/contributions/support/success for that long is not "relatively new". ;-)

    And as far as hardware support... uhm.... SDL supports much more hardware than DirectX. SDL runs on a very ride variety of systems and OSes. It runs on PowerPC, Alphas, Sparc, etc. etc. and so forth. It has an excellent support of joysticks (perhaps not as many as DirectX does on the Intel class hardware, but when you consider the other hardware and OSes, it certainly has more support.)

    And besides... DirectX is very very very crufty and kludge filled. It's API changes so often that it makes project maintenance a nightmare. This same API is always underdocumented. As someone with experience with both DirectX and SDL (as well as a dozen other multimedia libs) I can honestly say that SDL has a great deal more potential and promise for future projects than DirectX.

Real Programmers don't write in PL/I. PL/I is for programmers who can't decide whether to write in COBOL or FORTRAN.