Slashdot Mirror

Why bother porting or emulating when you can write for both platforms natively at the same time? This is what the SDL library is for. It allows you to write a program once and be able to compile it natively for each platform (Linux/Windows/Mac/etc). If developers started writing games to be cross platform they could release the game on all platforms simultaniously. Here is a research project on designing cross platform software: http://www.wpi.edu/~mongoose/mqp/latex_doc/mqp.pdf

Designing and writing a cross platform application is not difficult. Actually the main problem that the research found was the companies didn't want to write applications for Linux because they didn't want to have to support Linux. Linux was too hard for companies to support do to all the various distros, writing the code though was the easy part.

OpenGL can't assure multiplay. Games don't pass polygons to each other during play, they send data about actions and unit positions. How different platforms render that data on screen is irrelevant, as long as the results are consistent.

For compatible play you need a compatible API such as OpenPlay or SDL_Net (personally, I'd like to see those two efforts merge in some way).

What network multiplay API did Loki use? Are their games compatible with either DirectPlay (Win) or NetSprockets (Mac)?

There's already SDL, which has been getting some nice, positive feedback as a good, cross-platform multimedia API. Note that Win32 is one of those platforms. Oh, and the API has nothing to do with the install. If you've ever tried a Loki game installation, they're really smooth and easy. Unreal Tournament installed just fine on my system.

3)Get some bloody normal people to use the OS.

And one of the best ways to lure users is to get some games for it. Loki porting some Windows games to Linux is a step in that direction. Face it, the general public is not even going to consider Linux as their OS until there's a good selection of games for it.

It alkso needs new games, not 12 month old crap like what is being touted here.

Neither game is crap, and only one of them is as old as you say. Tribes 2 has only been out for Windows for what, 1-2 weeks, tops?

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

Q: Does it work?

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

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

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

Q: Does it work?

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

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

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

Q: Does it work?

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

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

I'm just wondering if RedHat has any plans for supporting a standard game engine abstraction layer for GNU/Linux. The success of games under Windows seems to hinge on DirectX, and I'm wondering if we might see something like the Simple DirectMedia Layer distributed with future RedHat distributions?

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

A:

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

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

A:

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

redundant to Transgaming's work in porting the DirectX multimedia API for Wine?

SDL has been in the making for many many years. Transgaming, for all their promises, is a very new project and is still in its infancy.

Over the years, SDL has evolved into a very stable and powerful multimedia library with some very nice functionality (especially when all the add-on libraries are taken into account).

As far as platform support, SDL has it in spades... SDL runs quite nicely on BeOS, Win32, MacOS and pretty much every *nix variant.

I would wager that SDL is the most used Linux multimedia library. The games and applications listed on the SDL site are but a drop in the bucket compared to those that I have found listed on Freshmeat and even projects on SourceForge.

I, myself, have had quite a bit of experience with SDL. My educational typing game, Tux Typing is powered by SDL. I have also begun writing some little example apps in SDL (including a multi-windowed SDL app).

While I agree this was a pretty stupid question to be featured on the "Ask Slashdot" section... from the many inane and less-than-informed comments I can see that quite a few people really don't know what SDL is, what it is being used for, and where it is going.

So, to anyone interrested, I'd say take a look at the doc pages, code tutorials here, as well as checking out the latest stable release version 1.2.

redundant to Transgaming's work in porting the DirectX multimedia API for Wine?

SDL has been in the making for many many years. Transgaming, for all their promises, is a very new project and is still in its infancy.

Over the years, SDL has evolved into a very stable and powerful multimedia library with some very nice functionality (especially when all the add-on libraries are taken into account).

As far as platform support, SDL has it in spades... SDL runs quite nicely on BeOS, Win32, MacOS and pretty much every *nix variant.

I would wager that SDL is the most used Linux multimedia library. The games and applications listed on the SDL site are but a drop in the bucket compared to those that I have found listed on Freshmeat and even projects on SourceForge.

I, myself, have had quite a bit of experience with SDL. My educational typing game, Tux Typing is powered by SDL. I have also begun writing some little example apps in SDL (including a multi-windowed SDL app).

While I agree this was a pretty stupid question to be featured on the "Ask Slashdot" section... from the many inane and less-than-informed comments I can see that quite a few people really don't know what SDL is, what it is being used for, and where it is going.

So, to anyone interrested, I'd say take a look at the doc pages, code tutorials here, as well as checking out the latest stable release version 1.2.

But what other gamemaker has come out with decent games using SDL?

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

Hyperion used it for both Sin and Shogo.

Vicarious Visions used it for Terminus.

It was used for Hopkins:FBI. (You remember, the first Linux commercial boxed game. 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.)

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

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

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

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.

http://www.libsdl.org/games_db/games.php3

(Are you sure you included a URL? Didja test them for typos?)

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

Yeah, I kinda agree with that. I think dev groups should have many clients on the same cd, and you just run the right install program. Also, depending on how you develop games, it isnt hard to make a Linux binary... like look at Loki and their interaction with the SDL and SMPEG projects (I mean besides the fact that Loki started them/still runs them)You could write a whole title that can be compiled on either system with little effort. But dont take what Im saying as Linux is easy to dev for. Youll probably have to include multiple binaries, depending on what you feel like supporting... but most likely imo it will be binaries for xfree 4/glibc2.1 and thats it. Console based graphics interaction basically is dead (for those who dont run linux, its like playing a dos game.... run it from a text console prompt, it switches to a graphic mode) even though alot of projects still try to support it. Same with Xfree 3.... Its kinda of a waste to support it, unless your doing only 2D stuff... But with 3D... X3 is behind alot... it really only has indirect/secondary rendering via Mesa, and not alot of 3d acceleration chipsets are supported by mesa either by mesa itself or xserver drivers.

Actually, I kinda wish somebody would implement something like DirectX for Linux

Have you ever tried coding in SDL? It's a cross-platform 2D game library with graphics, input, and sound support.

What about Allegro? It's another cross-platform 2D game library, used by scores of free games such as Tetanus On Drugs. It also has a 3D addon that uses your platform's existing OpenGL support.

DirectX is a MS Windows driver/library, and it is disgusting. Also, it's not cross-platform at all. About the closest thing you can get to Linux DirectX support is the Wine libraries. Do you have any idea what you are talking about?

Games should be written to be portable in the first place by using SDL / OpenGL.

-Justin

www.libsdl.org (BeOS, MacOS, Linux Win32 others?)

SDL is indeed worthy of praise, but I should point out that Linux, Win32 and BeOS are the only platforms that it _officially_ runs on. From their FAQs, MacOS "sort of" works (8-bit displays don't work properly, audio support is experimental). I mention this since the original questioner specifically asked about Mac support.

www.libsdl.org (BeOS, MacOS, Linux Win32 others?)

SDL is indeed worthy of praise, but I should point out that Linux, Win32 and BeOS are the only platforms that it _officially_ runs on. From their FAQs, MacOS "sort of" works (8-bit displays don't work properly, audio support is experimental). I mention this since the original questioner specifically asked about Mac support.

SDL is a cross-platform game devel library, that (off the top of my head) works on Linux (X and fb), MacOS, Windows, and probably a bunch of other targets too :) )

The API is quite nice, and the whole thing is.. it's just nice :). I love it.

SDL has sound support, and 2d video. If you need 3d, you can use GL for graphics with SDL for everything else, which is a big plus.

SDL is, BTW, what Loki uses to port games from Windows to Linux (Like Civilization:CTP, etc).

-----

I dunno. Loki seems to have done pretty well, as had ID (Marketing blunders aside). And if a game writer uses SDL that really eases the programmer's problems and handles most of the cross-platform headaches and compatibility issues for them. They can even include SDL in with their game if they want (It's less than 400k for the Linux library).

Getting games running on Linux is fscking easy. The tough part is getting people over the it-isn't-windows-it's-too-hard syndrome that holds so many of them back.

One would do very well to use them together in an application, and now that you've been so helpful as to tell me about SDL, I'll investigate how we might do a ZooLib/SDL integration.

ZooLib is for doing the following in a platform-independent way from C++:

• threads with various kinds of mutexes, reader/writer locks and so on
• thread-safe reference counted smart pointers
• Simple vector graphics
• fonts and text
• creating and using various kinds of windows (but not what the X folks refer to as "window management - dragging and so on)
• platform-appropriate graphical user interface widget creation, drawing, input and layout
• TCP networking
• single-file databases (the databases, being entirely contained in single files, can be used as user documents, so the user could double-click on on a desktop to open it in an editor after receiving it via email).
• streams and filters, conceptually like C++'s iostreams, but more appropriate for binary data formats
• Debugging memory allocator and debugging support through widespread use of assertions

Now don't fault me if I leave something out, because I only just now found out about SDL, but lets see what SDL says it has:

• Simple, portable direct access to the graphics framebuffer, audio device, mouse and keyboard
• Support for OpenGL (the actual GL support must come from a separate library, many of which are available)

What I'd suggest you do in writing a game is use ZooLib for the overall GUI and threading support, and have a pane in the middle of the screen where your main action takes place. In that pane you do direct-to-screen drawing with SDL and if you're doing fancy 3D, consider using OpenGL. Use SDL for your sound.

Again, thank you for bringing this to my attention.

Mike

Why ZooLib? SDL is out already, is under the LGPL, and has good support for Windows, Linux, Mac, and BeOS.

DirectX is an absolute piece of shit from a programmer's standpoint. The API could only be described as "grotty" on the inside (c.f. library versions and context pointers, or the gawdawfulisms that are inherent in win32 to begin with like the code needed to open the simplest window). By comparison OpenGL's api is incredibly well laid-out. The two offer a similar set of features (OpenGL works just was well with 2d or isomorphic setups, linear transformations being what they are), but DX puts you through a lot more pain to get at them. If you were a programmer and you just had to use a DirectX-like API to feel happy, see SDL, which provides many of the gruntwerk features of DX and is much cleaner (and is cross platform). (NB: SDL doesn't do 3d or drawing primitives itself but there are many, many addon modules to accomplish this stuff; OpenGl rendering contexts are provided, see the SDLization of the NeHe tutorials on the sdl site.)

WRT speed, well, OpenGL on linux is an interesting question. At best it's second fiddle to mature OpenGl platforms like SGI. But if you have an NVIDIA card or one of the DRI-supported cards you're probably set to play most games. True, many games are coded in DX, but OpenGL is far from dead (Q3 is native opengl, as are all the Q3-engine-using games; UT works very well in opengl mode, etc. (I like FPS games so that's where my examples are coming from.)).

Anyway, linux already has the beginnings of pretty good DirectX support in the form of the recent developments from the Wine camp. For me the litmus test is "can I play StarCraft on Linux?", and the answer is "yes." :-) (Now if I could just find my fscking StarCraft disk :-/ moving sucks.)

1) Write a library of good-looking, wickedly fast GUI widgets using the EVAS API (rip some code from Gtk to get this going quickly)

2) Invent a high-level network protocol for creating, manipulating, and responding to events on these widgets. Heck, write one on top of CORBA if you must. Now client applications will connect directly to Enlightenment and build GUI interfaces using its facilities.

3) Give Enlightenment direct access to input devices through a library like SDL

4) Finally, RM -RF THAT CRUFTY PIECE OF JUNK CALLED X11!

Please, Rasterman, realize that this technology won't just enable window managers to have fast eye-candy. It could form the basis for a completely independent, hardware-accelerated display server (not even OSX's Quartz is hardware-accelerated yet)! By managing and rendering widgets at the server, you will blow Windows, OSX, etc out of the water performance-wise, and keep X11-style network transparency!

Well, since the SegaOS and WindowsCE game development kits are expensive and scarce, it might make a nice Linux-based games platform. Could SDL be ported to it easily?

I'm actually not sure if I agree with your first assertion. We're not going to release the source to our gaming engine, but I think it probably wouldn't matter all that much if we did, because the important parts of what we're releasing is the data that runs the engine. If gamers wanted to modify the engine, it wouldn't give them access to the extra levels and game packs we're making. That's the meaty part of what we're selling, really, the creative part. The engine is just the playback routine for the data.

But we do expect to be paid, of course :)

The biggest issue that needs to be addressed in development is to design the games to be platform independant. You will not get any developers to create games specifically for linux, you will have to get them to create games for both linux and windows at the same time, or at least port their game from windows. The problem this leads to is that developers are not going to rewrite their game twice, hence the creation of companies like Loki, so the best thing developers need to do is to write their game for multiple platforms at the same time, using cross platform libraries(SDL is a very popular one) or better design techniques. There is alot of FUD about cross platform development (extreme performance loss, difficulty in designing...). Currently there is an interesting college research project going on that gives alot of good information about this topic. The server for research project goes up and down a lot so keep trying...

I really enjoyed Chromium B.S.U. (screenshot).
--

• SDL, or Simple Direct-media Layer - this is low-level games api
• Clan-Lib - this provides a higher-level API

http://libsdl.org/

Check out SDL, the Simple DirectMedia Layer. It is available for a bunch of platforms already (including Win32 and Linux, of course). I've played a couple games, Defendguin being my favorite, and was impressed. It probably has progress to make before being suitably robust for the really complex games, but I think it has definite potential.

Now, I haven't tried SDL on GNU/linux or Windows, but I got the SDL copy of The Black Lotus's iXalance demoloader and fired up Jizz - a demo that used to run just great from Windows on my old P133. Using libSDL under BeOS on my brand spankin' new P3/700, Jizz sucks up the whole damn processor and still wants more.

On the ohter hand, SVGAlib is SVGAlib, and as of today, I'm more inclined to trust an XFree86 X server running as root than whichever app running as root and messing around with SVGAlib. But your mileage may vary, of course.

Just to play devil's advocate, this doesn't sound like anything more than Capcom throwing out a buzz word to generate publicity... so they develop a midlayer that exports a generic API on several different platforms, and then code their games to that API. That's *NOT* emulation. That's what SDL does, that's what OpenGL and OpenSound do. It's basic tiered design, and it's a good idea. Hell, the point would be moot if all the game console manufacturers would get together and implement a unified API anyway, which they ought to do. But using the word 'emulation' just to stir up interest is pretty weak, IMHO.

Loki's SDL with Paragui may be a good start, perhaps.

How about Dreamcast? You can develop for Dreamcast without using any leaked or proprietary information at all -- just reverse-engineered stuff. Start here.

From a brief glance this looks interesting. I will dig in later, but for now it will have to go into book marks. Most of our current code is SDL based so we would need to port that first.

We are still faced with the problem of media. Is it possible, or even legal to create media that will run on a stock DreamCast? I expect that anyone who has not signed any kind of agreement cannot technically be stopped, but I don't think that will prevent SEGA from getting litigious.

Please don't use SVGAlib to write this sort of code. It is the wrong solution to almost any problem. Persuade someone to port SDL instead.

Sorry I barfed the link tag. I should be here.

--

All it probably* does is treat both CR and LF as line-ending whitespace (line-ending in order to recognize a trailing backslash character; otherwise the position of whitespace is not that important, as long as various tokens are properly separated), and compile normally.

* Of course, this is all just my best guess, since I haven't taken a real look at the actual code of GCC, nor talked with its designers or implementors. So maybe they actually use some magic formula with an all-powerful AI to recognize CR/LF combos, but I'm probably pretty close with the previous hypothesis. But for all I know, I certainly could be wrong, but I'm pretty sure that CR+LF is a horrible DOS-ism that hearkens back to TeleTYpe days.

Incidentally, interesting looking game(s) you've got there... gawdz I miss Allegro, although right now I'm in between game SDKs (leaning toward SDL, although also wishing that ClanLib would get their act together and "officially" update their docs and API. But I digress... :)

--
while ( !universe->perfect() ) {
hack (reality);

Two sources you can check out.... mpeg plugin for xmms and mpegtv's mtv player.

LGPL'd multi-platform framebuffer, OpenGL, window housekeeping, input, sound, networking, and multithreading. Embeds nicely as a static library optimized to include exactly what you need and no more instead of a big shared lib.

I've been using SDL lately for my own project and it has a very clean and easy-to-use API for game programming, so your students wouldn't be overwhelmed by API complexity.

Granted, the kids wouldn't write every last detail of the game. Much of the internal machinery of the aforementioned Pacman was given to us and that was a good thing. But having your kids write something as simple as an object that plays audio using a callback function could work well as an assignment.

This could also be used to teach object-oriented programming habits. For each assignment the kids would get an interface for an object of the game that they have to write the implementation for. The kids' work could be tested by switching their object implementations with the teacher's implementation and seeing if things go wrong. By the end of the class one could theoretically take any combination of object implementations and compile them together to yield the finished game.

If someone interested, it's in C/C++ using SDL, and it *is* really really alpha code ;)

http://sourceforge.net/projects/firemen

Be seeing you...

You may want to check out the Simple DirectMedia Layer at www.libsdl.org. Essentially, it is a wrapper for cross-platform development -- aside from having multiple language bindings, it currently supports Win32 (DirectX), Linux (OSS / DGA) and BeOS. Not only that, but it abstracts basic system-level functions to minimize porting requirements.

Try what Loki is using: SDL. It handles video, audio, and input, and has ports for Linux, Win32, MacOS, and BeOS.

As for only loading the parts you need to run... ahh, the wonders of demand paging. That is the job of the OS nowadays.

The only real problems with writing Linux games, IMO, are immature support for hardware-accelerated OpenGL, and lack of library support for weird media types.

The only missing glue is the input API. Perasonally, I wouldn't mind it if SDL became standard. It works on almost everything now.

I agree that SDL would be a nice solution to the common API problem. Why? IMHO because it is and it aims to be be cross-platform. I think that Linux (and other unices) need to have some common API with Windows to ease the development of games to many platform at once. We can't (yet) even dream of a situation where leading-edge games were developed primarily on Linux - now it helps to have some common API with Windows.

There are alternatives, too. I can recall Allegro and Clanlib right now.