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?"
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. http://www.hopkinsfbi.com)
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 (http://www.newbreedsoftware.com/ for one) as well.
Just look at http://www.libsdl.org/games_db/games.php3
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.)
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.
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
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.
S DL Games
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">>Lib
So, use them as a good yardstick for your own works...
j.
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
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! :)
My Freakin Blog
My Freakin Blog
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).
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.
Improvise, adapt, and overcome.
David 'Zoid' Kirch. Now works at Retro Games, a 2nd party developer for Nintendo.
m.
"Sebastian you're in a mess. They called you King of all the Hipsters, is it true or are you still the Queen?" -- B
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.
"Sebastian you're in a mess. They called you King of all the Hipsters, is it true or are you still the Queen?" -- B
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.
James
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.
The enemies of Democracy are
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]
--
Pretend that something especially witty is here. Thanks.
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."
If tits were wings it'd be flying around.
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."
If tits were wings it'd be flying around.
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.
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).
--
Vidi, Vici, Veni
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.
-- Veni, vidi, dormivi
http://www.libsdl.org/games_db/games.php3
(Are you sure you included a URL? Didja test them for typos?)
Stupid job ads, weird spam, occasional insight at
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.
Jumpstart the tartan drive.
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!"
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.
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
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.
This is my signature. There are many signatures like it but this one is mine..
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)
This space for rent. All reasonable inquiries will be entertained at proprietors discretion.
Thad
The Bolachek Journals
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.
Cheers,
Thad
The Bolachek Journals
Anyone have any cool ideas for an educational game? 3D Zoombeanies? A FPS Algebra tutorial?
SuperID
Free Database Hosting
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
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 read the license.
--------
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.
I gots ta ding a ding dang my dang a long ling long
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.
I gots ta ding a ding dang my dang a long ling long
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.
A deep unwavering belief is a sure sign you're missing something...
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.
A deep unwavering belief is a sure sign you're missing something...
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
> 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...
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.
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?
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.
--
Twivel
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.
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.
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.
Outdoor digital photography, mostly in New Engl
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.
Outdoor digital photography, mostly in New Engl
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 allegro.cc site is a good resource for add on libraries and community news.
pinkNoise
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.
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.
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
// do it
// do it
{
virtual void function1()= 0;
virtual void function2()= 0;
};
class Implementing : AbstractBase
{
void function1()
{
}
void function2()
{
}
};
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()
{
}
void function2()
{
}
void function3()
{
}
};
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 libXXX.so.X.X 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" =)
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
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.
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.