Open GL Super Bible

Previous Table of Contents Next

Further Developments in OpenGL

An open standard is not really open if only one vendor controls it. Thus, all enhancements to OpenGL are decided by the OpenGL Architecture Review Board (ARB), whose founding members are SGI, Digital Equipment Corporation, IBM, Intel, and Microsoft. The OpenGL ARB meets twice a year.

These meetings are open to the public, and nonmember companies may participate in discussions (although they can’t vote). Permission to attend must be requested in advance, and meetings are kept small to improve productivity. Members of the ARB frequently participate in the Internet newsgroup Questions and recommendations can also be aired there.

In December 1995 the ARB ratified the final specification for Version 1.1 of OpenGL. Many of the additions and changes from Version 1.0 were for performance reasons and are summarized in Appendix A.

How OpenGL Works

OpenGL is a procedural rather than a descriptive graphics language. Instead of describing the scene and how it should appear, the programmer actually describes the steps necessary to achieve a certain appearance or effect. These “steps” involve calls to a highly portable API that includes approximately 120 commands and functions. These are used to draw graphics primitives such as points, lines, and polygons in three dimensions. In addition, OpenGL supports lighting and shading, texture mapping, animation, and other special effects.

OpenGL does not include any functions for window management, user interaction, or file I/O. Each host environment (such as Microsoft Windows) has its own functions for this purpose and is responsible for implementing some means of handing over to OpenGL the drawing control of a window or bitmap.

OpenGL under Windows

OpenGL made its debut in the release of Windows NT 3.5. A set of DLLs was also made available to add support for OpenGL to Windows 95 shortly after its release. This book, in fact, is specifically about Microsoft’s generic implementation of OpenGL. We will guide you, the developer, through the fundamentals of 3D graphics first, and then show you how to compile and link some OpenGL programs under Windows NT or Windows 95. Moving on, we’ll cover the “wiggle” functions provided by Microsoft—the glue that enables the OpenGL graphics API to work with Microsoft’s GDI. From there we will cover the entire OpenGL API, using the context of Microsoft Windows NT and/or Windows95.

Graphics Architecture: Software versus Hardware

Using OpenGL is not at all like using GDI for drawing in windows. In fact, the current selection of pens, brushes, fonts, and other GDI objects will have no effect on OpenGL. Just as GDI uses the device context to control drawing in a window, OpenGL uses a rendering context. A rendering context is associated with a device context, which in turn is associated with a window, and voila—OpenGL is rendering in a window. Chapter 4 discusses all the mechanics associated with this process.

As we said earlier, OpenGL was meant to run on systems with hardware acceleration. PC graphics vendors are adding OpenGL support for their cards. Properly written OpenGL applications should not know the difference between hardware accelerated rendering and the purely software rendering of the generic implementation. The user will notice, however, that performance is significantly enhanced when hardware acceleration is present.

Figure 1-1 illustrates hardware acceleration under Windows, including normal GDI acceleration and Direct Draw acceleration, as well as OpenGL acceleration. On the far left you can see how an application makes normal GDI calls that are routed down through WINSRV.DLL to the Win32 Device Driver Interface. The Win32 DDI then communicates directly with the graphics card device driver, where the GDI acceleration is performed.

Figure 1-1  Overview of how Windows graphics acceleration works

Direct Draw is optimized for direct access to graphics hardware. It bypasses the GDI completely and talks directly to the graphics hardware with perhaps only a thin hardware abstraction layer in between, and some software emulation for unsupported features. Direct Draw is typically used for games and allows direct manipulation of graphics memory for ultrafast 2D graphics and animation.

On the far right of Figure 1-1 you see OpenGL and other 3D API calls routed through a 3D device driver interface. 3DDI is specifically designed to allow hardware manufacturers to accelerate OpenGL and gaming 3D APIs such as the Reality Labs API. (For a discussion of OpenGL and the Reality Labs API, see Chapter 24. In addition, hardware vendors with specific hardware acceleration for OpenGL (such as the GLINT chipset) may install their own OpenGL client drivers along with specialized device-driver interfaces.

Limitations of the Generic Implementation

Unless specifically supported by hardware, Microsoft’s generic implementation of OpenGL has some limitations. There is no direct support for printing OpenGL graphics to a monochrome printer or to a color printer with less than 4-bit planes of color (16 colors). Hardware palettes for various windows are not supported. Instead, Windows has a single hardware palette that must be arbitrated among multiple running applications.

Finally, some OpenGL features are not implemented, including stereoscopic images, auxiliary buffers, and alpha bit planes. These features may or may not be implemented in hardware, however. Your application should check for their availability before making use of them (see Chapter 5).

Future Prospects for OpenGL in Windows

The introduction of OpenGL into the Windows family of operating systems opens up some exciting possibilities. As millions of PCs become OpenGL-enabled, Windows may well become the most popular platform for OpenGL-based applications. Initially this implementation may be for scientific and engineering modeling and visualization applications, but commonplace hardware will make high-performance games and other consumer applications possible before long.

Even for vendors producing OpenGL based applications on other platforms, Microsoft Windows implementations could prove to be a substantial source of secondary revenue. Windows-based workstations are an attractive alternative to high-cost specialty workstations, with the added bonus of being able to run some of today’s best business and productivity applications.

Previous Table of Contents Next