OpenGL on OS/2 - An Introduction

From EDM2
Revision as of 21:14, 3 September 2018 by Ak120 (Talk | contribs)

Jump to: navigation, search

Written by Perry Newhook

Introduction

One of the most impressive demonstrations that can be performed on a computer is one involving the display of 3D graphics. From modelling CAD parts to scientific visualization to the latest games, 3D graphics have become a standard part of today's advanced applications. With the introduction of OpenGL as a standard 3D graphics library, most every platform now has an environment to create high quality, professional graphics.

OpenGL has emerged as the de facto standard for creating graphics on multiple platforms. Originally created by Silicon Graphics as IrisGL for their graphics workstations, it was later released as an open architecture for all platforms. A software interface to video hardware, OpenGL contains over 120 commands that allow the programmer to draw objects, and perform operations on them to create a 3D environment.

Every object in OpenGL consists of a combination of three simple primitives: points, lines and polygons. These, together with translation and rotation commands allow you to draw most any scene. Colouring and lighting commands add the illusion of solidity and realism to the scene. While OpenGL gives you everything you need to build your scene, it does not give you windowing commands, user input commands, or commands that actually draw what you have created onto the computer screen. This was done on purpose to create a hardware independent interface that can be implemented on a wide variety of platforms. To actually draw what was created on the screen, OpenGL relies on a set of platform specific interface commands that allow the user to setup and draw to the rendering window. These commands can be differentiated from regular OpenGL commands by their prefix. OpenGL commands are prefixed by the letters 'gl'. The OS/2 interface commands are identified by 'pgl'. With X-Windows it is 'glX' and with Windows it is 'wgl'. In addition to the platform specific commands, there are two sets of toolkits that contain functions that insulate the programmer from any platform specific commands. These toolkits are called the AUX and GLUT toolkits. Each provides commands that are common throughout all platforms that implement them, and allow programs written using them to run unmodified from one platform to another. The program 'Atlantis' that shows whales and sharks swimming around is an example of a program written using GLUT that was ported to OS/2 from the SGI with little modification. Although the thought of writing an application under one of these toolkits and having it compile to multiple platforms is alluring, it is still recommended that professional applications write to the PGL interface. This provides the writer with far more control over the application as well as a speed boost and is the approach we will take in this column.

OpenGL is extremely easy to program once you get used to it. The most important thing to remember is that OpenGL acts like a state machine. Once an item, such as a colour, is set, it remains in use until it is changed. Taking advantage of this fact influences the way you create the scene. For example you can group all of the objects drawn from the same position together so you only need to command a translation and rotation once, and you can group parts of an object of the same colour together to reduce the total number of change colour commands. Grouping objects together in this way not only makes rendering quicker, but it usually makes editing the object easier because the commands that make up the object are logically laid out. Logically thinking out what you want to display before you jump in and start coding, is the most important aspect of OpenGL development. A few minutes of planning beforehand can save hours of coding later.

The other aspect of OpenGL that you must be aware of is that all manipulations of an object are performed using matrices, and multiple matrix operations use a stack of matrices. Each matrix is a 4x4 array that describes translation, rotation, shear and scaling. I will not go into the actual composition of the matrix at this time but this can be easily obtained from any book on graphics or robotics. Combinations of individual rotations and translations are accomplished by multiplying two or more matrices together. A special matrix often used is called the identity matrix. It is a matrix representing a rotation of zero, a translation of zero, no shearing and a scaling of one. This matrix is used at the start of any operation to clear out any previous rotations and translations. Matrix operations are performed on a matrix stack. Any new operations are applied to the top matrix on the stack, and you have the ability to push and pop matrices off the stack to store and retrieve previously composed matrices. In OpenGL there are two stacks, one holds the projection matrix and the other a modelview matrix. The projection matrix describes the viewing volume while the modelview matrix contains the cumulative effect of viewing and modelling transformations. Luckily you do not have to compose these matrices yourself (although you can if you want to); OpenGL provides functions that encapsulate matrix compositions into easy to use functions that for the most part hide what is really going on underneath.

If you have OS/2 Warp 4, and a compiler, you have everything you need to start developing in OpenGL. OpenGL comes free with Warp 4, and can be downloaded for Warp 3.0. Most any compiler that can compile OS/2 programs can compile OpenGL apps, although you may need to get os2.h and its associated header files from the Developers Connection CD. If you are using VisualAge C++, you already have everything you need. More detailed instructions on setting up your compiler for OpenGL can be found in opengl-os2 help file found in \opengl\docs directory.

Currently, OpenGL and OS/2 has been implemented entirely in software. The good part of this is that no special graphics card is required to display the 3D applications that you write; they should look and act identically on every machine. The bad news is that without taking advantage of hardware acceleration, a $3500 state of the art 3D enhanced graphics acceleration card will probably give the same frame rate as an $80 dollar card that can be picked up at any computer store. Currently what matters the most is the efficiency of the video drivers of a particular video card rather than any special 3D features the card has itself. This will hopefully change soon, however, as it is rumoured that IBM is working on a toolkit that allows people to write hardware accelerated drivers. Keep in mind that this is entirely rumour and is not based on any fact that I know of. Even without hardware acceleration, the OpenGL for OS/2 is very fast and efficient. I have benchmarked applications that I have written against similar applications under Windows OpenGL, and have found the OS/2 version to be up to 2-10 times faster, depending on what was attempted to be rendered. The tests were done on identical hardware using non-accelerated video cards and drivers. Hopefully when hardware support becomes available, it will be as well done as the current software implementation.

There are many sources of information on OpenGL programming on the Internet. The main newsgroup conference is comp.graphics.api.opengl and is an excellent way to get quick answers to questions as well as general information by reading other peoples questions and ideas. Another good group, although not directly relevant is comp.graphics.api.inventor. This group deals with Open Inventor, an object-oriented language built on top of OpenGL. While OpenGL is C based, Open Inventor is meant to be used with C++. While Open Inventor commands cannot be used directly with OpenGL, there usually is an equivalent command or group of commands that do a similar thing. What is most important is the concept and the method of creating a scene or an effect. Many other newsgroups contain useful information, especially those on graphics, animation and game design. There is also a mailing list specifically aimed at OS/2 programmers of OpenGL. Here programmers can ask questions, post ideas and get information about OpenGL and programming for it. This mailing list is very useful as the IBMers that wrote OpenGL for OS/2 monitor it and are always helpful with suggestions or answers to questions. Information about joining the mailing list as well as the OpenGL FAQ can be found at http://www.utsi.com/~kgl/os2-opengl/.

Conclusions

Over the next few issues, I will introduce the PGL commands, and show how they can be used to merge an OpenGL program into an OS/2 C++ application. Basic OpenGL commands will be introduced including how to build up an object and eventually an entire scene from primitives. We will then colour and light our scene to add realism. In upcoming columns we will also discuss how to use OpenGL to display animation, and some tricks and guidelines to get the maximum speed out of your OpenGL application. Readers are welcome to e-mail me suggestions for future topics that you would like to see covered, and I will do my best to work them in. I hope this series will be useful to you and I hope you find the world of 3D graphics as exciting as I do.

Next month I will explain how to create a graphics context using PGL so we can use OpenGL to draw a simple object onto the screen.