Five code samples per article. In the words of fnord...mmmmkay. void, int, char, static, auto. Heh heh heh.


[size="5"]How does Linux fit in as a gaming platform?

Right now, Linux is really a systems operating system. There are not many applications available for Linux that appeal to the typical end-user. Bonafide UNIX is and always will be a programmer's operating system, developed by programmers, for programmers. But end-users can get a piece of the action in Linux, because it's a bit different.

The very idea of running a flavor of UNIX on a PC is something different, really, from what Thompson had in mind when he ran the first build of UNIX developed on a multi-user mini (a PDP-7). When UNIX was first seeing the light of day in '69 as a pet project, the first commercial microprocessor was still 2 years away--NO ONE could have foreseen UNIX as an operating system for the masses.

But, that's the prospect we're dealing with today. And it's a pretty new one. Will Linux--and UNIX in general--be able to function as a mainstream platform?

Look at the history of the PC industry. Old timers say, "been there, done that. Linux is just another contender. It'll be brushed under the rug soon enough." Unfortunately what many people still don't get is that Linux is NOT just another contender. Microsoft screwed CP/M, OS/2, DR-DOS, PC-DOS, etc--but those were commercial platforms. They were developed and advertised AS commercial platforms. The rules of business applied--and wherever that is the case, MS wins, because Gates is really something of a grandmaster of business. The rules of business do not apply per se with Linux, and everybody is waiting--including Microsoft--for something to give.

Distributors push Linux and advertise it as some act of God, but the developers do not. Do you see the distinction?

If they chose to, Linux kernel developers could walk away from the project any time they wanted to and go divert themselves back into their jobs in the industry. Linux could become dead in an iota. Aside from ethics and a few copyrights [and copylefts], developers are free to do what they want with Linux--it's for fun.

Conversely, even if all the Linux distributors are monopolized, the developers are essentially free to continue. Therefore the Linux project will remain active, despite any business tactics, for precisely as long as developers remain involved with it. Open source in general is no magic wand, and neither is Linux--but the development model poses a nice, sweet Catch-22 for the business geniuses that have ruled the industry this far. Ultimately the developers determine how long Linux lives, what it becomes, and what it doesn't--not the distributors or the industry at large.

Given this, we are back to the central question. Is Linux or will it become a viable platform for users en masse? Is it or will it become a viable gaming platform? That depends. Distributors have to handle part of the battle in getting it out there, granted--but what it boils down to is that it will be more or less what the developers want it to be.

So what do you want Linux to be?


[size="5"]Graphics with Linux.

It used to be that you had very few options when you wanted to do graphics under Linux. Today, that is not the case. You have so many options that I don't even know where to begin talking about them. So, bear with me as we go through them all. I will list them as we go.

[size="3"]1. svgalib

Prior to the 2.1.x pack of development kernels, Linux was pretty ignorant of graphics hardware. That is, kernel drivers didn't know or care about anything but text modes (for console I/O). To get around the problem, a library and driverset called svgalib was developed. svgalib was poorly documented and not something that an end-user would enjoy configuring, but it worked [usually]. Several respectable console games were even written under/ported to svgalib, among them DOOM and Quake. The other option was X, which has its own graphics adapter driver hierarchy in place. (xdoom and xquake are also available. ;)

[size="3"]2. X

Let me cover X a bit. X, developed at MIT many moons ago, is a distributed, client-server-based windowing system and protocol that usually runs locally or over TCP/IP. It is not "just" a windowing system, contrary to popular opinion, and it really has a purpose altogether different from Win32--comparisons between the two are not worth-while. When X is started on a server by root or a person with appropriate privileges, an X server is launched. Users can log on and run client applications by communicating with the X server. When the client makes an X protocol request for display resources, the X server transparently communicates with remote users to allocate them. Even the most typical X applications are distributed--and they don't even have to know about it. The most commonly available X server for Linux is XFree86, and a loads of cool X stuff is packaged with most non-specialized Linux distributions today.

As great as this all sounds, there are two problems with games under X. Foremost, both windowing systems and protocols involve hierarchies, and hierarchies involve overhead. X is a huge, old, nasty hierarchy, with LOTS of complexity. So, it's not that great for games. Less obviously, at least until you try to get started, is that learning how to program X when all you want to do is write games feels like a huge waste of time.

Here's a crash course in X programming. Stop me when it starts to sound not-fun. Xlib is the universal library that abstracts the X protocol. On top of Xlib is the toolkit layer, not universal...on Linux, Xt-intrinsics is the most commonly available toolkit. Toolkits are designed to make life easier. On top of toolkits are WMs or window managers that further make life easier. The standard in WMs (and hence in books about X programming) is Motif, but that costs beaucoup d'argent so on Linux the most common is fvwm. Code is not portable across WMs or toolkits. Client applications sit on top of WMs, which are in themselves clients. Enjoy!

[size="3"]3. OpenGL

HOWEVER! Never fear. OpenGL has been available for Linux since about 1996 (the free project is called Mesa), along with GLUT. Ah, GLUT. So, you don't need to know anything about X programming to do graphics under XFree86 if you understand OpenGL and GLUT. Now that is nice. Indeed, if your OGL+GLUT code is pretty clean, porting may be a simple matter of recompiling under Linux.

[size="3"]4. fbcon

With the release of the 2.2.x kernel, a module that implements framebuffer support on a hardware basis was officially added to the kernel, and along with it a console driver with support for graphics (fbcon) was finally added as well. I haven't SEEN any games for fbcon yet, but it is viable.

[size="3"]5. GGI

The General Graphics Interface (GGI) project, last but not least, started as a Linux kernel project for supporting graphics hardware, but has become a really awesome cross-platform effort. The GGI FAQ claims that GGI runs on even "sort of" POSIX-compliant OS's, which is quite a feat. (And, Nick, Solaris is coming up, so you have no excuse... ;)

The GGI team didn't wait for framebuffer support. They developed the Kernel Graphics Interface (KGI) in order to be able to develop the hardware drivers they needed to make their project work. Today, the KGI can either stand on its own or live peacefully with framebuffer support. All of the previously mentioned graphics options will run on GGI drivers. And, GGI drivers can be programmed directly with an API (LibGGI).

Not only will conventional svgalib and other applications run over LibGGI, but also GGI encapsulates graphics so that it essentially works anywhere. From the console, a game may output to the framebuffer driver as a default device. The same game will output to a window when run in X, without even realizing it. GGI lets you reduce graphics to a single task-- drawing. Tell me that's not cool. LibGGI is also incredibly lightweight and easy to program--it only took me about 5 minutes to build the libraries and check out some of the demos, and only a couple more to figure them out. In short, GGI is just so spiffy. Check out http://www.ggi-project.org/ for a head-start on my next article.


[size="5"]Issues I Left Out.

Well, in a word, security. Graphics means console hardware, and console hardware is owned by root. Period. svgalib programs, for instance, must be suid root or run by root. Hardware-accelerated X/GL apps must be suid root or have components suid root. That is a problem. Given classic PC gaming patterns, giving games full access doesn't seem to be a big problem--after all, we do it all the time in Windows.

On the other hand, the Win32/DOS gaming world and the UNIX gaming world are two different places. In Win32, we know that corporations spend loads of money to produce a single title and that it would be suicide for their game to cause a horrible crash. In Linux, you don't have that assurance, because games can come primarily from people you have never heard of and may come without source.

Also, while Linux can be configured to run in a single-user mode, UNIX at heart is architectured as a multi-user operating system. Developing applications under root on UNIX is sort of like developing applications under Administrator on an NTS fileserver--of course you can do it, but you'd better not screw up.


[size="5"]And what will we be covering?

In order to preserve my insanity, I will NOT be demonstrating how to use all five of the above technologies. Instead, I will choose one, and this one will be LibGGI.

svgalib used to be quite the common focus if not the only one, but I don't like it, and it is dead, and it has been legacy code for so long it's not even funny. X is and always will be viable but is just too complicated to discuss in such limited scope as an article. OpenGL/GLUT was my third choice, but I decided that you can find information on that elsewhere (for instance, check out Khawk's GL pong thingy). fbcon was my second choice, but I still find it a bit too new and a bit too Linux-specific. I ultimately chose GGI for portability, ease-of-use, and widespread availability.


[size="5"]Sound with Linux.

Sound is controlled by the kernel module aptly named "sound". Linux encapsulates this rather well and if you have any experience programming soundcards it isn't bad at all, but there is a sort of disadvantage for me--my soundcard is heavily Win32 reliant and doesn't yet work under Linux. ;)

So, oddly enough, we will not be covering much in the way of sound for the moment.


[size="5"]Input Devices.

LibGGI's sidekick is called LibGII, and oddly enough, it provides--you guessed it--input device functionality. It supports mice, joysticks, and of course, the keyboard. Force feedback under Linux? Uhm. No. But it'll get there someday.


[size="5"]End of Article 2.

No code this time, thought I'd get the general stuff out of the way. Next time I will expect you to have gotten LibGGI and LibGII so you can play with them. I will be developing a real, true, LARGER than life, Linux game.