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?"
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.
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...)
On the other hand, look at this: http://www.flightgear.org/Projects/RayChair/raycha 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).
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 use...like mixer, image-loading, and image primitive libraries.
Go to the www.khronos.org and see SGI/IBM & Co. developing the OpenML - incorporates OpenGL, audio and media - the cross-platform version of 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).
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 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: 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, 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
Improvise, adapt, and overcome.
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.
Improvise, adapt, and overcome.
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?
Improvise, adapt, and overcome.
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."
Improvise, adapt, and overcome.
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.
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.
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
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.
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.
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."
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.
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.
Cheers,
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
A quick hack (from Z) 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.
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
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?
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!"
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: newbreedsoftware.com/x
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..
Note the second line, it uses DirectX therefore it takes use of as much hardware acceleration as DirectX does.
I can't believe this question even made it to Ask Slashdot...
-zack
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)
This space for rent. All reasonable inquiries will be entertained at proprietors discretion.
When you develop games, cross-language means C/C++ with support for other *natural languages*. i.e. French, German, Spanish, etc.
-- Virtual Windows Project
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
Wow... insidiously cool! :-)
-elf
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.
Anyone have any cool ideas for an educational game? 3D Zoombeanies? A FPS Algebra tutorial?
SuperID
Free Database Hosting
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.
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.
Allegro was originally intended as a graphics library for the DOS port of gcc, DJGPP. It's slow, obselete, and leaks huge amounts of member under Linux. I was never designed with portability in mind, either.
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
Not to belittle the SDL developers, but SDL is really nothing more than a wrapper layer around existing APIs. For example, SDL/Win32 wraps around DirectX, and SDL on BeOS wraps around the standard BeWindow class. Thus, until Linux gets an API as good as DirectX (and no, OpenGL is only part of the equation, and even that isn't as good as D3D anymore) SDL/Linux won't be better/faster/more featureful than DirectX.
A deep unwavering belief is a sure sign you're missing something...
When you can link against a LGPL library, you don't have to release your source code.
Johan V.
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
There are of course, other benefits to multi-platform coding than market numbers. Cross platform code often has fewer bugs because the different run-time environments of the different platforms it runs on often flush out bugs that would've otherwise squeaked by on just the primary platform.
The question about SDL is whether it is as stable and high-performance on those other platforms as it is on Linux. Loki's experiences don't tell us anything at all about how well SDL performs on, say, MacOS.
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
hmm - I've ignored SDL for the most part because of its lack of 3D, but I may want to check it out now - I wrote a thread library that supported pthreads, Windows Native Threads, and Mac Threads and found it was a pain in the ass. I expected the mac to be the hardest to implement since it uses cooperative threads, but nope, Windows took the cake with two Handles (one for Windows and one for me). I had to write a macro to make my function pointers work. Mac and pthreads were actually quite similar, except that I had to add functions into the mac thread to give itself up from time to time (but that was in the thread itself, not a separate parameter to create the thread).
That being said, I would prefer to save the two weeks it took me to write it (during free time) for better things.
For ease of use and porting, SDL is about as perfect as I can imagine. Exult was originally written using Xlib (that's what the "Ex" represents). Switching to SDL took less than an afternoon, and the code became much simpler. Soon, contributors did ports to Win32 and BeOS. And more recently, others have ported to the Mac, BSD, and SGI. Yet, #ifdef's have been kept to a minimum, mostly for determining #include's.
Performance has also been great. For graphics (2d in our case), SDL provides the application with a frame buffer, just as I got with MITSHM/Xlib. So there's essentially no overhead in rendering. Event handling in SDL obviously means adding a level above the OS's, but it's not enough to notice. And audio performance seems fine, even using Timidity to create .wav data from Midi in realtime.
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.
Since I am a Java developer, I was curious about whether it could be used to shore up Javas weakpoints as a game platform. I discovered 2 sourceforge projects to create bindings for java.
http://sourceforge.net/projects/jsdl/
http://sourceforge.net/projects/sdl4j/
One of them seems to have made a fair amount of progress.
Please do not mistake this post for trolling, but could this development be redundant to Transgaming's work in porting the DirectX multimedia API for Wine?
Is it possible that Transgaming's DirectX for Wine port may be abstracted without the Wine component for easier game development between Linux and Window games?
Does the SDL have the benefit of more platform support (MacOS, etc)?
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.
Why didn't you post this question to any SDL mailing lists or forums? Or gamedev.net or flipcode.com?
:)
It's not Linux's answer to DirectX. It's MacOS' and BeOS' as well. Each version of the library will optimize to its specific platform, you just have to get the compiler for it, make the adjustments, and zerg's your daddy. Of course the abstraction will slow you down a bit, but for getting your game cross platform with ease that's an incredibly cheap price.
Of course, the tres nifty slashback would be for you to actually release the game cross platform across all four.
Peace,
Amit
ICQ 77863057
[o]_O
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've been searching the web for books about programming in SDL - But I havent been so lucky to find anything yet... So does someone know of a good book on this subject?
/watson
I enjoyed this tutorial.
Would this have support for > 2 joysticks? Right now it seems that the best bet for getting multiplayer on PCs (ala N64, not network) is with USB joysticks, which some versions of Windows support. Would I have access to them through this system?
--
SO YOU'RE GOING TO DIE: The Comic for Dealing with Death
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
Waldorf and Stadler
IIRC...
--- Can i borrow your Clue-Stick(tm)? I need to go beat a few people with it...
I'm currently messing with OpenGL.. I like it, and using glut, it can work on just as many platforms. The only drawback is that cards will need opengl acceleration to run anything decent, and the API is a bit more difficult, but still very easy. I dont want to tell you the horrors of Direct3d before DX8.
Otherwise they seem to follow the same pattern; the Allegro developers try to only put things that need access to the Allegro internals in the core library. Other things can be done as add on libraries.
For example, UTF-8 and I18N need to be supported by all the text functions, so they went into the core library, while things like MP3 and MOD support are in separate libraries.
pinkNoise
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.
Yup, you could have kept it to yourself. What do you think this is -- some kind of discussion forum or something?
No, your children are not the special ones. Nor are your pets.
i am currently writing a small 2d game (a clone of the classic dos game 'sopwith': here) and have decided to use SDL for it, mainly because of its portability. I have found that it is very simple to use. However, the main problem is that it provides only a very basic set of operations: for example, I had to write my own routines for flipping and rotating surfaces, which took time (and quite a bit of geometry). There are libraries which add features such as this but it seems tiresome to have to use a seperate library for basic flipping and rotating.
were you expecting to see a sig here? perhaps you'd rather see the inside of an ambulance!
Would anyone be able to explain to me exactly what the LGPL requires you to do? More specifically, does it require you to release source code as well as binaries.
As much as I think Open-source is a good thing, I don't like being forced into it especially since it is not ALWAYS the best way to go.
Thanks to anyone who takes the time to answer this question.
Does SDL rank well as an API? ;]
Are screens good for putting pixels on?
Of course its a G-G-GREAT API
Have a little to much time on your hands dont you? Well, i hope we can get some real responces, im curious about what people think of SDL.
Allegro has some sloppy coding. Pointers get lost in the maze of it. Bad things can happen. i.e. it's not really reliable
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
SVGAlib :)
samrolken
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.
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 "______"!
Tux Racer
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.
you're trying to drum up windows support on Slashdot. That's like recruiting for the US Navy in China right now.
Other than let you fiddle around with bits and copy rectangular regions back and forth, does SDL even give you 2D graphics? You know, like lines, rectangles, circles, gradients, colors, alpha transparency? I didn't see anything in the APIs last I looked.
What would be really cool is if someone were to write a driver layer for Linux capable of using the Win32 DirectX driver binaries.
:)
What makes DirectX cool isn't the APIs per-se (though they're fine, just very low-level). It's the fact that all audio/video hardware manufacturers write and optimize their drivers for DirectX.
It wouldn't necessarily even be all that hard -- the external interfaces for DirectX are very well documented (they have to be), and the internals of the drivers are just 16 and (some) 32-bit Intel code.
I'm sure there would be some licensing issues in using DirectX drivers on a non MS platform, but there should be no such issues in writing the emultation layer.
Then it's bye-bye unsupported a/v hardware on Linux. Plus porting existing games to (or from!) Linux would be a breeze.
Invisible Agent
Invisible Agent
This post is a mirror; when a monkey stares in, no hacker gazes out.
Well, I noticed that all the other SDL'ers got there plugs up here so here comes mine. I write libksd, a C++ game framework built on top of SDL. Its not finished yet but its mine. Yea.
-- David Snopek