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?"
SDL as designing tool (Score:1)
Re:multi-platform bliss (Score:1)
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...)
Re:What about force-feedback? (Score:1)
On the other hand, look at this: http://www.flightgear.org/Projects/RayChair/raycha ir.html [flightgear.org]
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).
Re:sdl info (Score:1)
OpenML - the cross-platform version of DirectX (Score:1)
Re:You're kidding, right? (Score:2)
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 [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/ [newbreedsoftware.com] for one) as well.
Just look at http://www.libsdl.org/games_db/games.php3 [libsdl.org]
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.)
Re:SDL *can't* be as good as DirectX. (Score:2)
See Loki. (Score:5)
Check out Loki [lokigames.com], since they wrote (or at least have done heavy development) on SDL exactly for the purpose of porting "professional" games. Get some of their demos; buy some of their games. Just last week or so I got Descent 3, Terminus, and Soldier of Fortune (for about $10 each from ebgames [ebworld.com].. can't pass up a deal like that), and am highly impressed with the quality. Pop in the SoF CD, run the cute little graphical installer, and go. It works. Flawlessly. Terminus too. (Actually that's slightly inaccurate, there were some minor GL problems with the G400 drivers in 32bpp mode that came up later, but switching to 16bpp seemed to fix them.) D3 I have problems with, related again to the XFree86 4.x G400 drivers, but still.
I've played some of their demos as well, and they're equally solid and polished. The SDL stuff is where it's at. Loki has proven it works for "real" games. The API and related packages you can get are great. Easy to install, easy to code for, flexible, Free(tm), portable, proven. What more could you ask for?
Just look at the games ... (Score:3)
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.
Terminus developer != Loki (Score:2)
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! :)
Re:To answer your question... (Score:2)
Aleph One SDL (Score:2)
My experiences with SDL (Score:2)
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).
Working in SDL (Score:1)
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: libsdl.org [libsdl.org]. 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 [warpcore.org], 2x [isa.net.au]
Freecraft [freecraft.org]
OpenUT [sourceforge.net]
Several DOOM and Quake projects
Also, for those of you who want something a little higher-level, SDL has several game programming libraries [libsdl.org] built on top of it:
BUILD Engine [lokigames.com]
GUIlib [libsdl.org]
PowerPak [imperialpenguin.com]
Re:You're kidding, right? (Score:1)
Re:You're kidding, right? (Score:1)
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?
Re:It was developed for use in commercial games (Score:1)
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."
Re:What about force-feedback? (Score:3)
Loki and SDL (Score:1)
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 [everythinglinux.com.au] or Tux Games [tuxgames.com]. Without Loki, there will be much slower development of SDL
Re:You're kidding, right? (Score:2)
m.
Re:See Loki. (Score:2)
m.
(who was the lead on SoF, thanks for the compliments
Re:It was developed for use in commercial games (Score:3)
But, yes, as mentioned elsewhere, Sam owns most of the copyright.
m.
Re:SDL 1.3 is coming (Score:1)
Re:You're kidding, right? (Score:2)
To answer your question... (Score:2)
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.
Re:To answer your question... (Score:2)
^_^
aalib. (Score:3)
--
Actually (Score:1)
Re:LGPL License? (Score:1)
What's wrong with something like Qt? (Score:2)
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."
Re:Now if I only had an idea......... (Score:2)
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."
Re:Now if I only had an idea......... (Score:5)
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.
Re:Now if I only had an idea......... (Score:1)
Re:You're kidding, right? (Score:1)
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.
Cheers,
Input devices (Score:2)
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).
--
Spaceball 4000 FLX [Re:Input devices] init (Score:1)
A quick hack (from Z [talisman.org]) that helps get the 4000 FLX running:
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.
Re:Now if I only had an idea......... (Score:2)
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.
Interface coherence between API versions (Score:1)
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?
Re:Just look at the games ... (bad link) (Score:2)
(Are you sure you included a URL? Didja test them for typos?)
Re:What about force-feedback? (Score:2)
What about force-feedback? (Score:5)
It's awesome (Score:1)
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: newbreedsoftware.com/x [newbreedsoftware.com]
Re:Allegro - an alternative game library. (Score:2)
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 [newbreedsoftware.com] require things like SDL_mixer and SDL_image.
SDL Tutorial (Score:4)
Check out part1 [lugod.org], and then part2 [lugod.org].
Be warned.. it's a bit dated. But it should be useful for the SDL-hacker-wannabe's
I'm no SDL expert (Score:3)
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.
Re:aalib. (Score:1)
From the loki Linux FAQ [libsdl.org]:
Re:Maybe? :) (Score:1)
Note the second line, it uses DirectX therefore it takes use of as much hardware acceleration as DirectX does.
You're kidding, right? (Score:1)
I can't believe this question even made it to Ask Slashdot...
-zack
OPP? (Score:1)
Crystal Space (Score:2)
Lately I've been looking at CrystalSpace [linuxgames.com] 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])
Re:Cross Language Too (Score:1)
SDL has workes great for me (Score:2)
Thad
Re: GridSlammer (Score:2)
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
Re:Now if I only had an idea......... (Score:1)
Wow... insidiously cool! :-)
-elf
Re:Input devices (Score:1)
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.
Re:Did you say OpenGL? (Score:1)
Re:sdl info (Score:1)
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.
Re:does it do even 2D graphics? (Score:1)
Ruby, too. (Score:1)
The important question... (Score:1)
Re:LGPL License? (Score:1)
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.
Now if I only had an idea......... (Score:5)
Anyone have any cool ideas for an educational game? 3D Zoombeanies? A FPS Algebra tutorial?
SuperID
Free Database Hosting [freesql.org]
Re:You're kidding, right? (Score:3)
-- Dan Kegel [kegel.com]
Ahh, yes... (Score:1)
--------
Genius dies of the same blow that destroys liberty.
Re:Maybe? :) (Score:1)
--------
Genius dies of the same blow that destroys liberty.
Performance is a little smaller, I think... (Score:2)
Quakeforge [quakeforge.net], 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 [newbreedsoftware.com], as they use SDL in pretty much everything.
--------
Genius dies of the same blow that destroys liberty.
Re:Did you say OpenGL? (Score:2)
Just one of my pet peeves... =)
--------
Genius dies of the same blow that destroys liberty.
Re:The thing about DirectX is the drivers (Score:2)
--------
Genius dies of the same blow that destroys liberty.
Re:LGPL License? (Score:2)
--------
Genius dies of the same blow that destroys liberty.
Re:LGPL License? (Score:2)
Aack! Should have used preview!
Of course, if you want to know *specifically*, you should read the license [fsf.org].
--------
Genius dies of the same blow that destroys liberty.
Re:multi-platform bliss (Score:2)
--------
Genius dies of the same blow that destroys liberty.
Re:65%? *Cough*Cough* Hold the smoke in a bit long (Score:2)
--------
Genius dies of the same blow that destroys liberty.
Re:No game devlibrary with no good OPL support (Score:2)
--------
Genius dies of the same blow that destroys liberty.
Re:SDL+OpenGL+GTK+=Sweet set of APIs (Score:2)
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.
SDL+OpenGL+GTK+=Sweet set of APIs (Score:3)
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.
Re:Interface coherence between API versions (Score:2)
Re:Interface coherence between API versions (Score:2)
Game Programming with SDL (Score:4)
One of the best judges of an API's efficiency is the success of programs using it. Looking over the list [libsdl.org] is somewhat impressive. But most of the popular games are Loki Ports, and they've had a lot of experience with SDL already. I see very few popular non-Loki games on the list.
I think you can conlude two things from this. First, it's possible to get reasonable performance from SDL, and it's definitly a reasonable API. Second, SDL just doesn't have the same support community size as OpenGL or DirectX. I suspect that the biggest barrier to graphics programming is *not* how often you run into trouble with the API, but how many other people can help you out when trouble occurs. No matter what API you use, you *will* have issues to deal with. So the smaller community size is probably the biggest obstical that SDL has to overcome.
-Ted
Re:SDL is great for native and cross platform apps (Score:2)
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...
Maybe? :) (Score:2)
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 [nondot.org]
Re:You have some big shoes to fill (Score:2)
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.
SDL 1.3 is coming (Score:5)
I haven't done any large projects in SDL, but I've heard the performance is quite good as Loki uses it for their porting efforts. Hey if it's good enough for commercial games.. er..
One thing you should keep in mind is that SDL is currently undergoing a complete rewrite and architecture change for SDL version 1.3 which will include the SDL 2.0 API. It's currently a year and a half from stable release (says cheif SDL ninja Sam Lantinga), so it's a long time to wait but you might want to keep that in mind as you are designing your project.
SDL Is excellent... (Score:3)
The limiting factors of SDL performance are not really SDL itself, because it is a very light API, but rather the limitations of X itself. My experience with SDL is that it provides at most a 2% performance degredation.
Furthermore, SDL is a wonderful cross-platform library that I have used extensively under both Windows and Linux. They also provide a cross compiler that lets you compile a windows executable under linux!
If you are considering SDL for 2D programming, I can say it is probably the best out there for speed, portability and ease of use. If you want to do 3D programming, you can either use SDL or some of the others out there, like plib [sourceforge.net].
--
Twivel
It was developed for use in commercial games (Score:3)
SDL was developed by Loki to simplify their own job - porting standard commercial games from Windows to Linux. Thus, it's already being used for "professional" project with cutting-edge, commercial games and is proven technology - at least on the Linux platform.
cross-platform compiling (Score:4)
Re:What about force-feedback? (Score:2)
Which is patented, closed, and not for release.
Re:aalib. (Score:2)
SDL is just a buffer. (Score:5)
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. [sandwich.net] Digging out Abrash's book, which was recently posted here, should help with some of the other renderers (polygonal, bresenham, etc.) that are fairly interesting.
SDL is great for native and cross platform apps. (Score:2)
As a side note, the biggest problem people had in creating a cross platform game is supporting non-Windows operating systems.
Re:SDL is great for native and cross platform apps (Score:2)
Re:What about force-feedback? (Score:2)
Sam Lantinga answered that question in this [lokigames.com] post.)
(http://www.lokigames.com/ml/sdl/8454.html
Allegro - an alternative game library. (Score:2)
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 [allegro.cc] site is a good resource for add on libraries and community news.
Cross Language Too (Score:5)
As the maintainer of pygame, the python binding, I believe it is one of the furthest along. This week will mark the release of pygame-1.0, and there is already a good community forming, (and projects being released).
Check out pygame at http://pygame.seul.org [seul.org].
What size/type game are you working on? (Score:2)
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 [linux-games.com], and am working on a game [taoriver.net] that I plan to port from ClanLib [clanlib.org] 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 [hyperion-software.com] (so, yes, companies other than Loki commercially using it), and Loki ported Tribes 2 and a zillion other games to Linux with SDL [lokigames.com]...
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.
Re:Interface coherence between API versions (Score:2)
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 info (Score:4)
You could have found this out too, if you had simply looked at the code instead of "Asking Slashdot".
Re:Useful for beginners (Score:2)
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.
Re:You're kidding, right? (Score:2)
Did you say OpenGL? (Score:4)
NEW?! was Re:Maybe? :) (Score:2)
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.