OpenGL Programming on Linux

This article is not intended to be an OpenGL tutorial or introduction. There are people far more competent in this area than myself, and they have written a number of articles and even books about this subject. Also, even though the project discussed in this article was written and built mostly using Xinside's OpenGL, it is not my intention to discuss the superiority of any of the Linux OpenGL ports or implementations over another. This article tells a cool story about using Linux, and I thought it was worth contributing to the Linux community.

“And, thus,” the professor concluded, “Instead of working on perfecting our home-made ray-tracer—something we have been doing for years—this semester, we'll start something new. You will have to build a 3D, network-capable tank game using OpenGL. You'll be in teams of two or three students. For that, you'll use the RS/6000 workstations we have here, and we'll give you an introduction to OpenGL.”

My ears! They could not believe what I had just heard. As a student in Computer Engineering at the Polytechnical School of Montréal and a computer graphics fan with a good background in ray-tracing, I had been waiting for years to be advanced enough in my studies to be able to take that course in advanced computers graphics. That semester I had finally been able to take the difficult 4th year course, and I had just heard, to my immense disappointment, that instead of working with a ray-tracer and producing high-quality ray-traced pictures, I would have to work on OpenGL. My morale was not high, and fear was making its way along my stomach as I realized I knew a lot less about OpenGL than about ray-tracing. But as one LinuxDoom aficionado would put it: “Armed solely with my Linux Box and my OpenGL Beta product, I plunged into the hostile mass of GL intrinsics, prepared to fight with every last GLfloat variable I had.”

More seriously, OpenGL is a graphics library designed from the start as a hardware-independent interface to be implemented on many different platforms. It uses a client-server approach, similar to the X client-server approach, to provide display of graphics primitives on the chosen windowing system. The server sends commands to the client, and the client displays them.

On X-capable Unix workstations, OpenGL has an extension to the X server named GLX. You can run your OpenGL program on one computer and display it on another, but it requires that the server machine has the needed OpenGL libraries and that the client has the GLX extension. Since those two packages usually come together, this means that both the server and client must be “OpenGL-capable”.

In short, OpenGL is capable of displaying simple geometric objects, showing orthogonal and perspective projections, performing back face removal, doing shading and anti-aliasing, and applying textures to objects. If you want to do something complex—like display a car or a plane—you have to build those objects yourself, and use OpenGL to render them the way you like.

On Linux, to my knowledge, you have the choice of several commercial implementations and one free implementation:

My personal experience was that the product I was using (Xinside's OpenGL second beta, and later, the final product, which was even faster) was of very high quality. It was faster and more compatible than Mesa. Speaking about commercial applications running on a free operating system is a sensitive and slippery issue, especially when there are freely available equivalents (Mesa) and even more so when you happen to find yourself very (or at least more) satisfied by a commercial tool. I found Mesa to be an impressive piece of software, but Xinside's OpenGL beta was noticeably faster and more OpenGL-compatible, since it is a true OpenGL implementation.

So, here I was, a few days later, in front of an RS/6000 workstation, writing the first few lines of code of that soon-to-be tank game and wondering if it was going to run on my Linux box. You see, I had subscribed to Xinside's OpenGL beta program a few months before as a means to remotely run OpenInventor from my Linux box, and thus, I found myself with an OpenGL-capable Linux computer. Later that same day I went home—while my Linux box was retrieving the sample code by FTP—and got ready to compile it under Linux.

The project we were building was using a freely available auxiliary library named libaux. “Fine,” I thought, and I FTPed its source code from the RS/6000 lab and compiled it on my Linux box. It's also available from ftp.sgi.com under the OpenGL sub-directory, along with all the examples from the OpenGL programming guide. With a lot of hope and increasing excitment I got ready to start the sample code and...it crashed, generating a panic file and killing the X server.

The team later figured that this problem was caused by a small bug in the Beta OpenGL release I was using which caused it to misbehave when using a color-indexed color mode and single-buffering. The program, however, ran fine as soon as I switched to use RGBA (for Red, Green, Blue and Alpha) color mode—it even ran slightly faster than on the older RS/6000 workstations we were using!

Granted, those RS/6000 were basic entry-level workstations, and their age (about two years), combined with poor 3D hardware accelerated video cards, proved they were no real match for my P133 with its Matrox Millennium (although OpenGL on Linux only provided software 3D acceleration). For someone who has been used to “This hot stuff runs on workstations—W-o-r-k-S-t-a-t-i-o-n-s—don't even think about running it on your home PC!” this OpenGL on Linux experience was like a dream come true.