Slashdot Mirror
Gaming on Linux
LinuxWorld's Nick Petrely latest column is about
Linux and gaming. Excellent arguements as to why this is an important market-and it's one of the weakest areas for Linux right now. I think recent moves have been good-but, darnit, I don't wanna sit down in front of the Playstation anymore. And I still haven't gotten my beta test copy of Civ: Call To Power. Harumph.
We're looking for artists, musicians, coders!
Check us out at www.golgotha.org
Posted by ^Malt^:
How about creating something like M$'s DirectX? One can say a lot about M$ but DirectX's still fast! Is there any really fast graphics libraries for Linux? Is it possible to run X while not waiting for the Word Perfect screen update for a second or more during a normal scroll? After a diskchrash, I installed Linux instead of Windoze and the graphics speed really sucks (IBM ThinkPad 380ED P166MMX 48MB RAM)
Direct-X and Direct-3D are build around Microsoft's COM object model, so creating a Linux equivalent would be a non-trivial task. I haven't used Direct-X since version 3, but back then it was a bitch to program for. It might be better now, I don't know.
In any case, OpenGL/Mesa is the way to go for Linux IMO. We already have it, it's an industry standard, and it's easy to use and powerful.
Now what to do about sound...
TedC
But while IP gaming is getting more compelling than ever, there is one thing that makes the gaming experience frustrating: system crashes.
Nick, you hit the nail on the head that time.
I usually have 3 or 4 system crashes a night playing Quake 2, and after 30 or 40 of these windows is so corrupted that it will no longer run. I have reinstalled Windows so many times that I can do complete sections of the installation with the monitor turned off by counting key presses. I finally gave up about 3 or 4 months ago; I decided that it wasn't worth the hassle anymore. Since I wasn't using Windows for anything but games, I just formatted the partition, and things have worked fine ever since. :-)
TedC
PS. I'm waiting for Quake 3 for Linux with much anticipation.
I'd just like to say that if you are interested in Linux games, you ought to check out happypenguin.org. I discovered it 2-3 months ago, and it has some excellent coverage.
-Eric
Professional Wild-Eyed Visionary
A few months ago, a games company approached me and asked me if i could do a linux port of their upcoming game. I agreed, not knowing which trouble I got myself into :). Lucky for me, the game release date is November 1999 (for both the win32 and the Linux version). So I created a project which defines a standard linux base (both hardware and software) for games in Linux, in the hope some distributions someday will comply to this.
xer.xes -- 4181
Ignore DirectX
DirectX is pretty much an unmitigated disaster from an implementation standpoint. Direct3D is especially egregious.
If you look at DirectX, look at it only as a vague source of the kinds of features you'd like to implement in a well-designed API.
Schwab
Editor, A1-AAA AmeriCaptions
Oh dear, you've gotten me started. As an occasional game author myself, I have some perspective on this (with lots of lessons learned the hard way from both sides), and it just happens that I've been thinking about this issue lately. Here are some things I believe Linux needs to improve its appeal to gamers and game developers.
Transparent Access to Full Screen Display Modes
SVGAlib has been an excellent tool for a long time, but it's starting to show its age, and it supports considerably fewer cards than the current release of XFree86. Further, it's silly to have to write a driver for the same card two or more times (once inside XFree86, once inside SVGAlib, etc.). I've read the work of The GGI Project, and I suggest interested techies do, too. There are no glaring flaws in the design (though it has odd warts here and there), and with work it could become an excellent foundation for high-performance graphics device control and configuration. SVGAlib and XFree86 could both be built on top of this structure. Thus, drivers would need to be written only once. I've love to see this move forward.
Unlike Windoze display modes (which all come out of a fixed table), Linux should be able to generate any resolution and scan rate the card can physically generate. Multi-monitor support would also be nice, but this is much harder (trust me on this one). Also, you should be able to launch a full-screen app from inside XFree86, and neither XFree nor the app should care (being able to switch back and forth would be nice, too). Ambitious souls may care to emulate BeOS's "Workspaces", where each virtual desktop can be a different resolution, scan rate, and pixel depth.
There also needs to be work done on supporting VESA DDC (Display Data Channel) which allows the system to identify the attached monitor and determine its scanning limits (thus alleviating the need for the dreaded mode table in XFree86config; just ask the monitor what it can do). We may also need to beat up on VESA to make its standards more readily available.
Expansion of OpenGL Efforts
OpenGL is the future of 3D gaming (just ask John Carmack). While Mesa is an excellent first step (and very complete), its performance is poor compared to OpenGL ICDs available for Windoze. Basically, we need to get the triangle counts up. Part of this can be done by optimizing Mesa. However, a significant portion of the rest has to be done by or in cooperation with the 3D card manufacturers.
A standard interface needs to be established between Mesa (or whatever OpenGL implementation ends up dominating) and the graphics cards. This will allow for Mesa and the hardware drivers to be evolved and optimized independently of each other. It also allows users to plug in any compliant card and expect it to work. This GL/hardware interface can be established at the driver level; the GGI people probably have suggestions on this.
Finally, everyone reading this article needs to beat up on the 3D card vendors to support Linux. Roughly half of all Quake servers are running on Linux. 3D card vendors live or die based on their Quake frame rates. Why should a server operator have to crash back into Windoze just to test out the latest RA/TF/CTF/LMCTF release? This alone is compelling enough reason for the 3D vendors to formally support Linux.
New Sound Architecture
OSS is functional (it works well for Quake and MikMod), but modern gaming requires much more. Sound has always been my weak point, so I don't have a lot of concrete ideas here. ALSA (Advanced Linux Sound Architecture) looks interesting, but I lack the knowledge to evaluate it properly.
Basically, the goals of the sound API need to include extremely low latency and low overhead. The system shouldn't be eaten alive just mixing and playing back sounds. Also, for applications that do buffer sounds ahead of time, there should be an event system built in such that the application can be informed when a particular sample or sample segment has started playing. This allows the client to synchonize other events (explosion visuals?) with the audio.
Networking
In my view, very little needs to be done here. Linux's socket API is one of the most reliable and complete implementations anywhere. There's no reason a game can't directly use network sockets.
Input Devices
Again, the keynote here is low latency and high sample rate. Most PS/2 mice will run at higher baud rates (if you're running Windoze at the moment, grab a copy of PS/2 Mouse Rate and see for yourself), so the mouse drivers should have the ability to tweak this.
I'm not as convinced that USB is important, but in order to get that to work, you better start beating up on Intel for the specs now. Intel's documentation department can be slow to respond (I'd use the term "glacial," but that conveys an unwarranted sense of haste). USB is a non-trivial beast. Getting all the device types, hubs, and hot-plugging issues down is going to take time.
Anyway, that's pretty much what's on my laundry list. I also have specific ideas on how some of this might get implemented. If I wasn't so darned employed, I'd probably be working on some aspect of this stuff.
Thanks for reading.
Schwab
Editor, A1-AAA AmeriCaptions
I almost submitted this as a separate story, but it seems to be very appropriate here.
Do y'all remember, back when Sony announced that Playstation 2 development was going to be on Linux? There was rampant speculation about whether a Linux emulator for the Playstation was going to come out. Most people concluded: Well, probably not.
It is here! Cygnus has a complete software emulation of the Playstation 2 that they developed for Sony. Now, I don't know if they are going to release it, and you would probably need a quad Xeon to get good performance, but man, that is exciting.
Here's the quote from Forbes:
Nevertheless, there is a lot of speculation about Sony's ability to
deliver enough games to make this videogame console a
must-have electronics gizmo. But such doubts are mostly
unfounded. Thanks to Cygnus Software, a Sunnyvale,
Calif.-based startup, which developed a software simulation
environment that allows game developers to create and test game
titles prior to the availability of the next generation PlayStation.
The simulation software runs on a Linux-operating system and
basically duplicates the hardware specifications of PlayStation2.
Even though the hardware is unlikely to be delivered until later this
year, it seems that many developers are busy cranking out games
for PlayStation2. The delivery of this simulator will dramatically
accelerate the delivery of titles in what is a hyper-competitive
marketplace.
Sony asked Cygnus to develop the simulator software two years
ago. What Cygnus has delivered is a software replica of
PlayStation2. The virtual hardware platform represents a complete
architectural simulation environment, including 128-bit CPU core,
floating-point coprocessors and DMA channels. This provides a
complete environment that allows a developer to create, test and
debug gaming titles.
See the rest of the article here. I hope this give Linux a gaming boost.
Free Trek is a space battle simulator game project. We need people to code and send me patches.
freetrek.linuxgames.com
If tits were wings it'd be flying around.
The author (why not a link?) claims that we just need a good development kit. Those things are in the works. At the low-level side is GGI. Have you guys ever used this stuff? It's incredible. A program written for GGI can run on SVGAlib or X or FB console without recompiling all as fast as it would have been if it had just been written for SVGAlib.
There's also ClanLib, which is an LGPL'd SDK, just like DirectX. True, it's not quite ready yet, but we need more people to put effort into these things rather than creating a new "standard". It's unfortunate that Loki has resorted to using SciTech's libraries to make their games, but nothing else is ready. Don't make it happen for their next game!
On another note, I saw a message on linuxgames.com that was saying that there are 10m Linux users, 1% of whom would buy a game, so that's 100,000 copies that a developer could sell if they made a Linux game. That's making a lot of assumptions, though, the most important being that all 10m of those machines have monitors and aren't 386s!
People keeps telling me that I need to get away from my computers sometimes. Unfortunately, they are completely right. I need to get away from the computer to eat, go to the bathroom, and sometimes when I'm tired and don't want to wake up with a face looking even more like a chessboard than it did this morning. It could be worse, though. If the keyboard had been designed so I actually woke up with QUERTY on my face, it would be far more difficult to lie to people, telling them that my face looks so weird because I had a shaving accident.
All this is of course due to major design flaws:
First of all, "tired" is implemented in such a way that it is sometimes impossible to compute the correct time to consume the complete collection of energy drinks. What I want is a hose from the computer right into my weins, so that it can fill me up with caffeine when I stop typing for a long period.
Second, the complete approach of eating is wrong. We go away from the computer, find some food which we insert through a large opening. Some totally inpredictable time later, we just have to move to a unit called the bathroom to get rid of all the unneccesary stuff we accidently pushed in through the hole in our face in the first place. Why do we push unneccesary stuff through that hole? Why do we at all let the body, which is our network connection and firewall, do such work as separating useful stuff from garbage? What we need is a separate external unit, which processes food collected in ways we, as end users, don't want to know about, then inserting the resulting pure fuel into us through some secure channel.
Taking care of that, we don't really need to get away from the computer. Now that that's sorted out, we can work further on the sleeping problem. The problem is that, while the computer can detect sleep and wake us up, it will still not prevent us from spending the time required for this process pressing our faces into the keyboard.
The solution to this problem is quite obvious. To prevent us from pressing our faces into the keyboards, we just need to put something soft between the face and the keyboard. Normally, objects matching the "soft enough" criteria already is there already; Our hands. If we just could prevent them from slipping away when we fall asleep, all our problems would be solved. Those of you that didn't instantly thought "use a binary key system requiring only ten keys, and stapple the fingers to they keys" need to upgrade your brains to at least version 2.14.122.
Wow. When someone fixes that food processing unit, then the most urgent problem in the world is actually solved! Now I just have to convince the university not to force me to move down there and sit in a room in 8 hours several times each year, and convince my cand scient cooperators to meet using IRC or news instead of RL.
About Linux gamesWhat we need is not linux games. What we need is Unix/X11/GLX games. Fixing hardware and GLX support in XFree86 would be the most important step towards linux gaming.
And to you Playstation junkies; I have a computer capable of running games. Why should I use a lot of money getting another unit doing that work, when I could buy some MIT Press books and an Communications of the ACM subscribtion for those money instead?
-segfault