OpenGL Reference Manual v1.4

Tasha Jessup writes "The fourth edition of the OpenGL Reference Manual, edited by Dave Shreiner, provides an official command reference for the OpenGL graphics library version 1.4. Published by Addison Wesley, the text is approximately 760 pages and has a suggested retail price of $59.99." Read on for the rest of Jessup's brief review to see how well it justifies that pricetag, and for whom. OpenGL Reference Manual v1.4 author Dave Shreiner pages 760 publisher Addison-Wesley rating 8 reviewer Tasha Jessup ISBN 032117383X summary Handy desk reference

First introduced in 1992, OpenGL is an industry-standard graphical application programming interface (API) that supports 2D and 3D rendering across a host of platforms. The Architectural Review Board (ARB) governs the OpenGL API and oversees the adoption of new interface functions. Functions (or commands) within the API are usually simple and discrete. A developer calls a series of these small functions in sequence to specify rendering operations. To help utilize the library, the OpenGL Reference Manual supplies key functional documentation in a uniform manner.

The first two chapters provide an introduction to OpenGL, and an overview of the OpenGL architecture. The provided information is largely for reference rather than instruction. Generally, it is assumed the reader has a working knowledge of the pipeline already. The third and fourth chapters list different groupings of the functional commands to provide the reader with several methods to index and reference functions. The third chapter details all each official OpenGL command categorized by functionality. The fourth chapter lists the various OpenGL constants that are compatible with each command.

Beginning with the fifth chapter, 160 official OpenGL commands are described. Listed alphabetically, every command has the following sections: Name, Function Prototype, Parameters, Description, Notes, Errors, See Also, and (sometimes when appropriate) Associated Gets. The coverage of each command spans an average of 3 pages.

The last two chapters describe fifty-two of the OpenGL Utility Library (GLU) and thirty-five OpenGL X-Windows extension commands. The reference format is identical but slightly shorter (averaging about 2 pages per command).

Overall, the organization and consistency is excellent. Often, material is duplicated per command to save the reader cross-referencing other sections of the book. Throughout the text, the wording is clear and unambiguous (if a bit dry) -- exactly what you'd expect from a reference book of this nature.

The book does have a few shortcomings, however. There is only a small trace of sample source code. While the commands are presented alphabetically by class, the book contained no overall index. OpenGL Extensions (pixel and vertex shader commands, etc.) are not provided since they're not officially part of the Standard. Finally, having an electronic version of the text would have been a nice touch -- especially one that integrated with the common development environments to provide context sensitive help or electronic searching.

Overall, the latest edition of the OpenGL Reference Manual is a great companion for OpenGL developers. To get the most from this book, readers unfamiliar or interested in learning the API should first read the OpenGL Programming Guide, 4th Edition (ISBN 0-3-211-73491) also published by Addison Wesley.

You can purchase the OpenGL Reference Manual v1.4 from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, carefully read the book review guidelines, then visit the submission page.

Comments

good book!

[Gingko]

OpenGL has changed focus a good deal since the last edition, and as such it is particularly good to see this updated. Driven by concerns such as ATI, NVidia and Microsoft (I *think* they're still involved), a lot of work has been done on modernising, streamlining and orthoganalising (like that's a word!) the API and it is now a good deal more useful. We're now in a situation where OpenGL combines the modern feature set of Direct3D with the rigorous review process implied by the ARB, while the extension mechanism, for all its drawbacks, is an elegant way of staging expansion of functionality.

This book is really one of a pair - it's not the OpenGL Programming Guide (the Red Book) and as such is not supposed to educate a newcomer to OpenGL on how to make use of the API and accomplish simple tasks. This would explain much of the lack of tutorial code. This book really is supposed to be a dictionary, an expanded set of documentation and assuming it sticks to the format of the previous editions will become just as well-worn occupant of my shelf as its predecessor.

Henry

I'm torn

[magic]

I'm really glad the book has been updated to version 1.4. The problem is that the API is currently on version 1.5 and the useful functions are all in extension (GL_vertex_buffer_object, GL_shader_objects) that aren't covered at all by the main API.

The OpenGL consortium needs to get its act together. DirectX has an incredibly streamlined API with up-to-date documentation that includes all of the latest hardware features and runs identically on all cards. OpenGL is saddled with backward compatibility across 10 years and the latest features are all vendor-specific. The OpenGL 2.0 proposal doesn't go far enough; it basically brings OpenGL up to DirectX 9.0, while Microsoft is already releasing information about DirectX NEXT, which will be the new generation of graphics APIs.

Frankly, the only reason I put up with OpenGL is that it runs on Linux and Mac. Portability is ceasing to be a compelling argument when the common .NET runtime across all versions of windows (embedded, CE, Xbox, desktop, server) and new features of DirectX NEXT are available.

-m

opengl 2.0

[Anonymous Coward]

in it's current form opengl is still a great opensource (mesa) crossplatform alternative to directX (in terms of graphics). But it is currently flailing, the revision of opengl 2.0 is greatly needed Hopefully all of the commitee can get the spec decided upon and out there, before directX forces everyone to develop using c#.

DX vs OpenGL extensions

[Namarrgon]

The problem is that the API is currently on version 1.5 and the useful functions are all in extension (GL_vertex_buffer_object, GL_shader_objects) that aren't covered at all by the main API.

I'm with you here. I get better reference material on the net.

DirectX has an incredibly streamlined API...

Man, I so totally disagree (this is COM we're talking about), but perhaps that's just me :-)

...runs identically on all cards

Uh uh, it most certainly does not. DirectX runs very differently on a 9800XT vs a TNT2. Obviously.

OpenGL's ARB and vendor extensions are good and bad - good because you get the very latest hardware features immediately and you don't have to wait a year or two for the (admittedly slow) ARB to decide whether they like them or not. Bad because the vendor extensions at least aren't standardized, and if you want to use them, chances are you'll need multiple code paths for different vendor hardware. ARB extensions are standard, but of course not all hardware supports them (or indeed, older hardware may not support the newer versions of OpenGL).

Instead, DirectX uses capability bits to differentiate between hardware. If you want a new feature, you have to wait until MS gets around to supporting it (e.g. PS 3.0, even though that's already been defined, cannot be used until you get DX9.0c). MS do update DX more regularly than the ARB (they have to, without vendor extensions), but you could still be waiting a while. You still need multiple codepaths to cope with different hardware caps - no difference there, and you may still have to deal with cards that don't have drivers for the latest DX at all.

OpenGL is saddled with backward compatibility

OpenGL 2.0 reinvents the API to cope with programmable hardware, and mitigates that effect fairly well.

Microsoft is already releasing information about DirectX NEXT

Yeah, like what? Nothing exactly useful. You won't see much from MS for quite a while.

the only reason I put up with OpenGL is that it runs on Linux and Mac. Portability is ceasing to be a compelling argument when the common .NET runtime across all versions of windows (embedded, CE, Xbox, desktop, server)

That's hardly much portability - it doesn't run on Linux and Mac. OpenGL is available on many more platforms than .NET, let alone DirectX.

...and new features of DirectX NEXT are available.

That could still be some time. I don't think .NET is going to solve portability problems anytime soon, especially for games, professional apps etc, any more than Java did (and probably somewhat less).