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:
Xinside's and Metrolink's OpenGL ports for Linux, each of which requires that you install its own X server to provide the GLX extension and generally higher performance.
Portable Graphics, whose product runs directly on XFree86.
Brian Paul's Mesa library, which is GPLed and available for free, but has no GLX extension. It's impressive and affordable.
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.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Hacking a Safe with Bash
- Django Models and Migrations
- Secure Server Deployments in Hostile Territory, Part II
- The Controversy Behind Canonical's Intellectual Property Policy
- Huge Package Overhaul for Debian and Ubuntu
- Shashlik - a Tasty New Android Simulator
- Home Automation with Raspberry Pi
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile
- diff -u: What's New in Kernel Development