Slashdot Mirror

Of course we have a Linux port! The development machine I use at home (and yes, there is a lot of that kind of development going on) is a Linux box using Mesa and GLUT. Still, I must say that the Onyx2 does push the polygons a tad bit faster...

(Of course, we have yet to release any code, but I'm hoping that will change quite soon...)

XFree86 4.0 will have Precision Insight's Direct Rendering Interface which will bring Linux 3D framerates on par with Windows. Precision Insight has even hired Mesa's Brian Paul to bring his experience to the project. The day is coming when Linux will achieve gaming parity with Windows...

My nominations are:
Brian Paul for the excellent crossplatform OpenGL compatible graphics library MESA. It provides a real alternative to commercial OpenGL and gives Linux a competitive 3D language.

The Olivetti Research Laboratory (now at AT&T UK) for a program I use every day - VNC. This program is used for remote control much like PC Anywhere or even X-Windows and it runs on Unix and Windows. Clients for Unix, Win, Mac and Java.

Well during AWGUA 99, they said (Mark Sylvester) that depending on the user response, they may port their apps to Linux. So if you Alias Wavefront licenses are current, bug them about it. There was a loud cheer just when they announced the availability of the Maya and Composer batch renderers. Though, I think realistically there won't be any serious consideration until Xfree 4.0 and DRI are included in the distros. These apps need some serious hardware OpenGL accelaration.

Still the apps are coming. Houdini 4.0 will run on Linux (using the Xi OpenGL I believe). There is Blender which could me called a mid-level package, and there is the roto and ras_track from Hammerhead. So it might just be a matter of time. Hopefully by next SIGGRAPH will get some real good news. Here is a link to the OpenGL BOF for reference:

The beautiful thing about OpenGL is that it is mostly platform independent. So you could start by adapting existing code, reuse the OS interfacing parts, and put in your own OpenGL code. Such code and lots of tutorials can be found at www.opengl.org and in the example directories of a Mesa distribution. (We owe Brian!)

Side note:
Interestingly enough the Win32 world seems to stay closed as it always have been, while there are many OpenGL demos for Win32 out there, few of those authors disclose their source.

Ultimately get the new Woo book for OpenGL 1.2 and the Kilgard book for the interaction with the X environment.

If you are interested in 3d graphics for FreeBSD watch the announcement for the upcoming 3d section on www.freebsd.org

I have been compiling the tnt drivers from the CVS server, and even with MesaCVS, it is slower than the drivers that came with the rpms pointed to on mesa3d. About 15% slower with q2. They however do fix one bug: xscreensaver gl screensavers don't flicker.

Go to Mesa's site, they have links to the open source 3d drivers. RPMS available, debs probably are to.

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

A little research goes a long way (I've actually been looking into this topic a lot recently). On the Mesa3D Homepage at the bottom, there's a thing on the 3D acceleration status report. If you go to it, you'll learn about all the fun happy things going into exactly what you talk about. The most promising one IMO is the GLX XFree extension; it's already got the hooks for hardware-assisted rendering with complete software fallback, it just needs support and drivers. They've already got an early-alpha Permedia driver for it, though I don't have a Permedia card (I have a 3Dfx and will soon be getting a TNT of some sort, probably the Asus 3400, to replace my failing S3 ViRGE).

The GLX implementation with XFree is currently rather sluggish, due to some design issues within XFree (not really XFree's fault), but apparently it's only a latency issue. The nice thing about GLX is that, aside from being how SGI themselves implement it, it is network-transparent (it is technically an X protocol wrapper for OpenGL commands); it even apparently allows an SGI to display on a PC or vice-versa (of course, without hardware rendering, you would probably want the PC displaying on the SGI and not the other way around).

Of course, there's other developments going on (also referenced from the status report), but the GLX one seems most promising, at least for serious rendering. I think the latency issues would impact its usefulness for gaming. :/ It's also the one which is closest to viability; the GGI3D stuff, for example, is still in early design phases, and looks like it's going to be more of a Direct3D-ish thing (that is, a low-level API which OpenGL etc. would sit on top of), which means more APIs for the vendors to support. It's hard enough to get vendors to support both D3D and OGL under Windows, much less Linux.

Given nVidia's Linux-friendly history, though, I wouldn't be surprised if as soon as one of the APIs matures that they make a driver. Since the GLX scheme is the functionally-closest to the Windows ICD mechanism, I have a feeling that the vendors will adopt that first. And why not? It's robust, allows progressive implementation, and network-transparent. Can we say "thin clients?"
---