Slashdot Mirror

← Back to Stories (view on slashdot.org)

OpenGL Programming Guide 6th Ed.

Posted by samzenpus on from the write-it-again dept.

Martin Ecker writes "The Red Book, also known as the OpenGL Programming Guide published by Addison-Wesley Professional, returns in its sixth edition with additions covering OpenGL 2.1. The Red Book, so called because of its nice, red cover, is probably the most-well known, standard introduction to the OpenGL graphics API. Let me take you on a tour through the pages of this book to see what it has to offer." Read on for the rest of Martin's review. OpenGL Programming Guide (Sixth Edition) - The Official Guide to Learning OpenGL, Version 2.1 author Dave Shreiner, Mason Woo, Jackie Neider, Tom Davis pages 862 publisher Addison-Wesley Professional rating 8/10 reviewer Martin Ecker ISBN 0-321-48100-3 summary The Red Book is the authoritative guide to OpenGL. Just as the previous, fifth edition of the book, the sixth edition is incredibly complete and thorough. It contains explanations of pretty much every feature of OpenGL, even the rarely used ones. You want to know about the fairly new occlusion query support of OpenGL? It's in this book. You want to know about the accumulation buffer and its uses? It's in this book. You want to know about the (mostly deprecated) use of indexed color buffers? It's in this book. The sixth edition also covers vertex and fragment shaders and recent additions to the GLSL, the OpenGL Shading Language, such as the preprocessor. Even though the coverage was expanded, the authoritative guide to shader programming in OpenGL still remains the Orange Book aka The OpenGL Shading Language (see my previous Slashdot review).

The Red Book is aimed at the beginning to intermediate graphics programmer that is not yet familiar with OpenGL. It assumes a basic background in computer graphics theory and working knowledge of the C programming language. The book consists of 15 chapters and 9 appendices that together span approximately 860 pages.

The first chapter gives a brief introduction to the basic concepts of OpenGL and describes the rendering pipeline model used in the API. GLUT, a cross-platform library that allows easily creating OpenGL applications, is also shortly discussed together with a program that shows GLUT in action. The following chapters proceed to explain the basic geometric primitives, such as lines and polygons, supported by OpenGL and how to render them in different positions and from different viewpoints using the various OpenGL matrix stacks. Also the basics of using colors, fixed-function lighting, framebuffer blending, and fog are discussed.

Chapter seven contains a description of display lists, a unique feature of OpenGL that allows to store OpenGL API calls for efficient multiple uses later on in a program. Chapter eight then moves on to discuss what an image is for OpenGL. Most notably this chapter now covers pixel buffer objects, a fairly recent addition to OpenGL, which the fifth edition of the book did not mention. The discussion of images in chapter eight bring us straight to chapter nine on texture mapping, one of the largest chapters in the book. This chapter discusses everything you need to know about textures, from specifying texture images in uncompressed and compressed form to applying textures to triangles using the various kinds of supported texture filters. Also depth textures and their application in the form of shadow maps and — new in the sixth edition — sRGB format textures added in OpenGL 2.1 are presented.

In chapter ten the authors discuss the buffers that make up the framebuffer, such as the color buffer, depth buffer, and stencil buffer. This chapter summarizes some of the things already presented in the earlier chapters and then describes the various framebuffer operations in more detail. Also the accumulation buffer and its uses, such as motion blur and depth of field effects, are discussed. Chapter eleven and twelve are on the tools provided by GLU, the GL utility library, in particular tesselators, quadrics, evaluators, and NURBs. GLU is nowadays rarely ever used in production code, so these chapters mostly demonstrate just how complete the Red Book is in its coverage of OpenGL. This also applies to chapter thirteen on selection and feedback, which are rarely used features, mostly because of the lack of hardware acceleration in today's GPUs (Graphics Processing Units).

Finally, chapter fourteen is a collection of topics that didn't fit into the other chapters, such as error handling and the OpenGL extension mechanism. Additionally, this chapter presents various higher level techniques and tricks, for example how to implement a simple fade effect, how to render antialiased text, and some examples of using the stencil buffer. The final chapter of the book is a discussion of the OpenGL Shading Language (GLSL, for short). In the sixth edition this chapter has been updated to version 1.20 of GLSL as required by OpenGL 2.1. Even though the OpenGL API functions required to use GLSL are presented, this is only a rough overview of how programmable shaders are used in OpenGL. For a more detailed description of GLSL the reader is referred to the Orange Book.

The book closes with quite a few appendices on the order of operations in the OpenGL rendering pipeline, the state variables that can be queried, the interaction of OpenGL with the operating system-specific windowing systems, a brief discussion of homogeneous coordinates as used in OpenGL, and some programming tips. Also a reference of the built-in GLSL variables and functions is included.

The book contains a large number of images and diagrams, all of them in black and white except for 32 color plates in the middle of the book. The illustrations are of high quality and generally help make the explained concepts and techniques easier to understand. Most of the color plates depict spheres, teapots, and other simple geometric objects, so they aren't overly eye-catching but do serve their purpose of showing what can be achieved with OpenGL.

All in all, the Red Book remains the definitive guide to OpenGL. Apart from being a good introduction, it also contains many interesting tips and tricks that make the experienced OpenGL programmer come back to it often. If you've read through the Red Book and the Orange Book in their entirety you pretty much know everything there is to know about OpenGL.

Martin has been involved in real-time graphics programming for more than 10 years and works as a professional game developer for High Moon Studios in sunny California.

You can purchase OpenGL Programming Guide (Sixth Edition) - The Official Guide to Learning OpenGL, Version 2.1 from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

86 comments

  1. I'd wait! by Grisha · · Score: 5, Informative

    OpenGL 3.0 is due to be released in short order, and it's pretty much a complete redesign of the API.

    Out with state machines and in with OO abstractions.

    1. Re:I'd wait! by krgallagher · · Score: 3, Interesting
      "OpenGL 3.0 is due to be released in short order, and it's pretty much a complete redesign of the API."

      I am not a programmer but I play one on TV.

      So help out a N00b. Is Open GL strictly for graphics, or does it cover other system calls like sound and user IO? What I am getting at here is that most of the times when I see a windows game that also runs on Linux, it uses Open GL. Those that do not use Direct X. Is the problem that the Open GL standard does not include sufficient API's to deliver all the standard calls need to write a game? Is it that other standards like ALSA (I am guessing that is a sound API) do not have windows ports? Why oh why is there nothing out there that allows programmers to write some kind of ANSI coded games that will compile on mutiple operating systems without error or modification?

      OK I admit I am ignorant in this area, so please don't call me ignorant, I have already done so myself. It just seems to me that if Microsoft can do it with Direct X, the rest of the world should be able to do it better, more cross compliant, and portable.

      --

      Insert Generic Sig Here:

    2. Re:I'd wait! by Anonymous Coward · · Score: 0

      Unless, of course, you want to learn how to program graphics with a cross-platform API that is actually supported by current hardware and drivers? I'm sure OGL 3.0 will be great. . . but some people may rather want to learn OGL 2 first, then worry about OGL 3 when it is actually commonly deployed.

    3. Re:I'd wait! by Abcd1234 · · Score: 4, Informative

      So help out a N00b. Is Open GL strictly for graphics, or does it cover other system calls like sound and user IO?

      Graphics only.

      Why oh why is there nothing out there that allows programmers to write some kind of ANSI coded games that will compile on mutiple operating systems without error or modification?

      I take it you've never heard of SDL? Just use an OpenGL-enabled surface for graphics, and the standard SDL APIs for sound and input.

    4. Re:I'd wait! by Anonymous Coward · · Score: 0

      OpenGL only does graphics. However, the SDL is a decent cross-platform library for graphics, sound, input, etc.

    5. Re:I'd wait! by Wm_K · · Score: 1

      As far as I know only the specs will be finished soon. Will there actually be a full implementation of these specs shortly or will that still take months/years?

    6. Re:I'd wait! by Anonymous Coward · · Score: 0

      Out with state machines and in with OO abstractions.
      Oh god, OpenGL is doomed.
    7. Re:I'd wait! by clem · · Score: 1

      Also consider OpenAL for 3D sound support.

      --
      Your courageous and selfless spelling corrections have made me a better person.
    8. Re:I'd wait! by everphilski · · Score: 1

      You can't compare OpenGL and DirectX. You can compare OpenGL and Direct3D, Microsoft's graphics interface. DirectX also includes stuff that handles keyboards/mice/joysticks, sound, and other nifty things.

      So if you want to do game programming that is cross platform, OpenGL only handles graphics. And just the low level bits - you need to write code to do higher level management of game object, like for example if you have a model of a pirate you need to know the position of each body part relative to the next part, states of things, etc. You'll have to write a class to handle that and structs to manage the data. And then you need the rest for devices, sound, etc. SDL is fine, I guess, or that is what people tell me. Another product I'd recommend is Irrlicht, it is open-source, cross-platform, and can target either OpenGL or DirectX for a rendering target. It is pretty nifty and uses a scene graph type hierarchy which can be useful in 3D games.

      It just seems to me that if Microsoft can do it with Direct X, the rest of the world should be able to do it better, more cross compliant, and portable.

      As another poster pointed out, if you take OpenGL and SDL you have a good chunk of DirectX but I'd argue it still isn't as good. The newer Managed DirectX is pretty polished once you dig down into it, to the point where bigger studios that used to make glaring statements of "DirectX sucks, OpenGL for the win" are abandoning OpenGL for DirectX. Of course, being able to target XBOX with very few code changes might help that argument. But you can find or make tools to work with open source if linux needs to be a target for your development.

    9. Re:I'd wait! by niteice · · Score: 1

      OpenGL 3 (formerly Longs Peak) is supported on current hardware. It's basically a redesign of the OpenGL 2 API. The next revision (codenamed Mount Evans), however, will add a whole lot of new features (at least DX10 level).

      --
      ROMANES EUNT DOMUS
    10. Re:I'd wait! by Surt · · Score: 0

      The problem is basically that DirectX has a big money backer.
      Microsoft puts a lot of money into research on the DX apis, and also works with the graphics vendors to make sure that DX will be able to take advantage of all the whiz bang features on every new generation of graphics cards.
      If you want to write a cutting edge game, it leaves you with no choice. You can't get the same to the metal speed on OGL that you can on DX. As a result, a lot of developers choose to go with DX as their API. Since a lot of developers have chosen DX as their API, MS is able to get away with making OGL an api with very limited support under windows. Since OGL has few windows apps as a result, OGL drivers for windows from the major card makers suck. Because the drivers for OGL suck, no one wants to use it to make games, and now you have a vicious cycle where OGL gets more and more unusable on the windows platform.
      MS has used their windows platform dominance with tremendous success in this area. OGL would likely have died and been forgotten were it not for Id software choosing to make a stand with the quake engine.

      --
      "Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
    11. Re:I'd wait! by ILongForDarkness · · Score: 1

      OpenGL is at a more fundamental level than DirectX. DirectX (or at least as it is commonly bundled) has a lot of added features. OpenGL systems are mostly comparable, they have a library called glu (graphics library utility) and glut(graphics library utility toolkit) that include higher level functions like draw a sphere. Very few people use just OpenGl, just like very few people use just DirectX, they build engines on top of them and call those things. DirectX is a MS product and so Windows only, some graphics cards handle DirectX or OpenGL better than others. It was more of a game studio deciding they are going to code in DirectX that forces their game to only run on Windows, whereas if they use OpenGL it could be ported to Linux.

    12. Re:I'd wait! by ultranova · · Score: 1

      Out with state machines and in with OO abstractions.

      An object is a state machine. The whole idea of OO is to couple the state with the functions which manipulate it. So instead of having drawCircle(context, vertex[] VertexArray), you'd have context.drawPolygon(vertex[] vertexArray) or even context.draw(new Polygon(vertex[] vertexArray)). These all do the exact same thing (and the last does it inefficiently since it allocates memory), and manipulate the underlaying state machine (physical hardware) in the same way. They simply express it differently.

      --

      Forget magic. Any technology distinguishable from divine power is insufficiently advanced.

    13. Re:I'd wait! by UnknownSoldier · · Score: 1

      > Out with state machines and in with OO abstractions.

      Having implemented OpenGL on the Wii, there is no reason why you can't do both. (oo abstractions under the hood.)

      Not every GPU is a stream processor. At some point you have to manage rendering states (blending,fog,etc.)

    14. Re:I'd wait! by mikael · · Score: 1

      When they mean object orientation abstractions, they mean that every entity (eg. texture, display list, fragment, geometry, or vertex shader) registered on the graphics card will be created with a functions that returns a reference token, and all operations will operate on that token (including the removable of that object).

      This is more in line with the design of scene-graph API's.

      --
      Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
    15. Re:I'd wait! by Nasarius · · Score: 1

      I'd also recommend OGRE for graphics, which now includes OIS for I/O. It's great stuff, even if you only care about a single platform. There's really very little reason for most people to use DirectX or OpenGL directly. Steve Streeting and co. have packaged all that rendery goodness into one damn good engine.

      --
      LOAD "SIG",8,1
    16. Re:I'd wait! by Anonymous Coward · · Score: 0

      I'll bet there are plenty of C++ wrappers around OpenGL 2.x that already associate states with objects. It doesn't seem like a hard problem.

      One question is, will OpenGL 2.x remain in common use for another few years, or will it be abandoned forthwith in favor of the newer API? If it's the latter, then OP's point is well taken... $70 is a lot to pay for a book that will be largely useless within 6-8 months.

  2. You mean 'ho-hum' edition? by xxxJonBoyxxx · · Score: 1

    The Red Book...returns in its meanwhile sixth edition with additions...


    By "meanwhile", do you mean "ho-hum"? (e.g.,, nothing new to see here?)
  3. For those not wanting to RTFS... by thatskinnyguy · · Score: 1
    Here it is in 252 words thanks to Word's AutoSummarize feature.

    The Red Book, also known as the OpenGL Programming Guide published by Addison-Wesley Professional, returns in its meanwhile sixth edition with additions covering OpenGL 2.1. It's in this book. It's in this book. It's in this book. Even though the coverage was expanded, the authoritative guide to shader programming in OpenGL still remains the Orange Book aka The OpenGL Shading Language

    The Red Book is aimed at the beginning to intermediate graphics programmer that is not yet familiar with OpenGL. The book consists of 15 chapters and 9 appendices that together span approximately 860 pages.

    The first chapter gives a brief introduction to the basic concepts of OpenGL and describes the rendering pipeline model used in the API. Chapter seven contains a description of display lists, a unique feature of OpenGL that allows to store OpenGL API calls for efficient multiple uses later on in a program. Chapter eight then moves on to discuss what an image is for OpenGL. Most notably this chapter now covers pixel buffer objects, a fairly recent addition to OpenGL, which the fifth edition of the book did not mention. The discussion of images in chapter eight bring us straight to chapter nine on texture mapping, one of the largest chapters in the book. The final chapter of the book is a discussion of the OpenGL Shading Language (GLSL, for short). In the sixth edition this chapter has been updated to version 1.20 of GLSL as required by OpenGL 2.1. All in all, the Red Book remains the definitive guide to OpenGL.
    --
    The game.
    1. Re:For those not wanting to RTFS... by An+ominous+Cow+art · · Score: 2, Funny

      It's in this book. It's in this book. It's in this book. Is it really in this book?
    2. Re:For those not wanting to RTFS... by thatskinnyguy · · Score: 1

      I didn't write it. I just copy/pasted it with no regard for spelling, grammar or sanity. Kinda like the editors here sometimes with their brain farts.

      --
      The game.
    3. Re:For those not wanting to RTFS... by Anonymous Coward · · Score: 0

      Computer says no...

  4. Gah. by cromar · · Score: 0, Troll

    Please, please, please stop chapter by chapter summarizing of books in reviews. A summary of the book and notable points is much better. The reader doesn't care what is in the *chapters* until they have decided to read the *book!* Please. Everyone. Stop doing this. It's pedantic.

    Incidentally, I didn't realize my copy was three editions behind... Sophomore year seems so long ago.

    1. Re:Gah. by pilgrim23 · · Score: 2, Funny

      only 3 Editions?
      http://www.digibarn.com/stories/dankottke/Image03.jpg

      --
      - Minutus cantorum, minutus balorum, minutus carborata descendum pantorum.
    2. Re:Gah. by Anonymous Coward · · Score: 0

      NO, I WANT detailed information on what is in the chapters *before* I buy the book!

      And this damn world needs to be more pedantic!

    3. Re:Gah. by Abcd1234 · · Score: 1

      NO, I WANT detailed information on what is in the chapters *before* I buy the book!

      Umm... isn't that what the table of contents is for?

    4. Re:Gah. by Intruger · · Score: 2, Informative

      I don't know about the latest edition. But you can take a look at an older edition here:
      http://www.glprogramming.com/red/
      I learned OGL mostly from this book (along with NeHe's tutorial on gamedev.net).

    5. Re:Gah. by tehcyder · · Score: 1

      It's pedantic.
      I'm deeply disappointed that you didn't make a spelling or grammatical error there...

      BTW, why was parent modded as troll? I thought it was an entirely valid to criticise "reviews" that mostly just list chapter contents as a way of padding out a couple of lines comment into an "article".

      --
      To have a right to do a thing is not at all the same as to be right in doing it
  5. Half-life: The book. by Anonymous Coward · · Score: 0

    "Just as the previous, fifth edition of the book, the sixth edition is incredibly complete and thorough. "'

    860 pages and it'll collapse your spine and your bookshelf. Plus technical books lose their value quicker than stale donuts.

    1. Re:Half-life: The book. by denison · · Score: 1

      How quickly do stale donuts lose their value? Haven't stale donuts lost most of their value already?

  6. Which Red Book? by AJWM · · Score: 1

    Funny, I always though of the Red Book as the PostScript prgramming guide (er, Language Reference). Either that or the standard for audio CDs (CDDA).

    Then there's the old O'Reilly "Rainbow Books", the eight or nine volumes on X Windows specs and programming -- but glancing over at my bookshelf, none of them are red, exactly.

    --
    -- Alastair
    1. Re:Which Red Book? by FranTaylor · · Score: 1

      I'm looking at Volume 3, X Windows System User's Guide, on my bookshelf, right now, and it's most certainly red.

    2. Re:Which Red Book? by Anonymous Coward · · Score: 0

      Funny, I always though of the Red Book as the PostScript prgramming guide

      Whereas I'm from China!

    3. Re:Which Red Book? by morgan_greywolf · · Score: 1

      Red boxes on a off-white background, but much of the cover is red, yes.

      --
      My blog
    4. Re:Which Red Book? by AJWM · · Score: 1

      Aarrgh, somebody's swiped me volume 3 then!

      Seriously, (looking more closely at shelf) the Volume 3 X Windows System User's Guide OSF/Motif 1.2 Edition is more of a dark reddish brown. But (digs around a bit) yeah, you're right, the straight Vol 3 is indeed (mostly) red.

      Sorry about that.

      --
      -- Alastair
    5. Re:Which Red Book? by rucs_hack · · Score: 1

      I'm still using volume 2...

      Got it cheap a few years back. I had no idea it was so out of date.

    6. Re:Which Red Book? by AJWM · · Score: 1

      Assuming you're serious, Volume 2 (Xlib Reference Manual) probably isn't very much out of date; Xlib hasn't changed very much. I have the 3rd edition (1992) with minor corrections (1993) that covers X11 R4/R5. We were on R6 for the longest time, R7 is less than two years old

      Most people use a toolkit (GTK, Qt, Motif, etc) on top of Xlib these days anyway.

      --
      -- Alastair
    7. Re:Which Red Book? by rucs_hack · · Score: 1

      yup,serious. I should probably put in my 'collection' books though, and get a modern copy.

    8. Re:Which Red Book? by g-san · · Score: 1

      Nothing funny about it. I second the thought.

      showpage

    9. Re:Which Red Book? by AJWM · · Score: 1

      That's the Little Red Book. I've got one of those around somewhere, too (from my high school days).

      --
      -- Alastair
  7. Re:ya right. by Anonymous Coward · · Score: 0

    Open sorcerers?

    * puts on his pointy hat.

  8. Re:ya right. by Anonymous Coward · · Score: 0

    directx 10 until Microsoft need a new version that will be bundled only with its new Windows version forcing everyone to upgrade, suck it up people who use an open standard, who don't have to worry about vendor lockin.

    There, fixed it for you.
  9. Comparison to DirectX by Andrei+D · · Score: 1

    Maybe this is a FAQ, but could someone point us why most game developers prefer DirectX, even if, by choosing OpenGL, they'd have the possibility to develop games for other operating systems as well? Yeah, I know, Windows has over 90% of the desktop market, but why don't develop for the whole market if something like OpenGL exist?

    --
    We often refuse to accept an idea merely because the tone of voice in which it has been expressed is unsympathetic to us
    1. Re:Comparison to DirectX by nate+nice · · Score: 5, Informative

      DirectX has had an "easier" and "more pleasant" API for years. OpenGL is a state machine, programmed in good 'ol C. DirectX has an OO API and what some would argue a more complete library.

      OpenGL 3.0 will move to a an OO API. It should make programming in OpenGL a lot more attractive. I've heard from people they feel it's easier to do a lot more things in DirectX than OpenGL. It's all opinion, of course.

      I'm not a graphics programmer but I have played one on TV.

      --
      "If you are a dreamer, a wisher, a liar, A hope-er, a pray-er, a magic bean buyer ..."
    2. Re:Comparison to DirectX by Xiph · · Score: 4, Interesting

      MicroSoft subsidizes training.
      DirectX is the native API to the OS on most peoples computers.
      Microsoft has experienced technical writers publish books about DirectX the day it comes out.
      OpenGL books are being written mostly by developers, which aren't always good technical writers.
      Microsoft managed to mastermind OpenGL standard development to halt to a freeze for several years, they no longer hold the same influence.

      My opinion:
      OpenGL is a more logical language, with a few features that are far better.
      OpenGL makes me happy, no clue why, but I enjoy coding up against it, DirectX makes me concentrate and for some reason, I never manage to dispose properly of all my "managed" objects in DirectX. That being said, one thing i like about directX is DirectView.
      OpenGL + Cg makes me happy

      My captcha was porters, proving that there is not necessarily a direct link between what you write and what captcha you get :P (to me a porter is a beer)

      --
      Blah blah sig blah blah blah irony blah blah
    3. Re:Comparison to DirectX by edwdig · · Score: 4, Insightful

      DirectX has had an "easier" and "more pleasant" API for years.

      DirectX is a nightmare of ActiveX/COM objects. It's anything but pretty to look at it. It takes a lot of code to get started before you can do anything. There's a very steep learning curve to fight through before you can do anything at all with it. It gets easier once you've managed to get it going, but it still isn't pretty.

      OpenGL is a state machine, programmed in good 'ol C.

      Which makes it very straightforward to work with. You don't find yourself wondering how something will work. If you have any background in 3D graphics theory, things work in OpenGL exactly as you'd expect.

      DirectX has an OO API and what some would argue a more complete library.

      The OO API doesn't make things easier, as it's COM based. It's advantage is integration with Windows.

      The library is where DirectX has an advantage. It's got some higher level functionality built in that OpenGL doesn't have.

    4. Re:Comparison to DirectX by everphilski · · Score: 1

      I'd argue the hobbyist community for DirectX is bigger and better (more current, anyways). Besides NeHe, there are a few tutorials here and there for OpenGL (most of them rehashes of the same thing), but the communities for Managed DirectX recently have been popping up all over. Check out Riemers XNA Tutorial, The Hazy Mind, Coding4Fun, the ZBuffer, and those are just the ones I remember off the top of my head from a year ago when I was dabbling with it. Each of those sites will take you from square one to the creation of a simple game (or toolkit). I used to use OpenGL for simulation visualization (both directly and indirectly through OpenSceneGraph, an open-source scene graph toolkit) as well. My personal opinion is that DirectX is more polished and consistent, but I grew up on c++ and object-oriented programming methods.

    5. Re:Comparison to DirectX by Jerry+Coffin · · Score: 1

      Maybe this is a FAQ, but could someone point us why most game developers prefer DirectX, even if, by choosing OpenGL, they'd have the possibility to develop games for other operating systems as well? Yeah, I know, Windows has over 90% of the desktop market, but why don't develop for the whole market if something like OpenGL exist?

      There are a couple of reasons. First of all, Microsoft tailors the API to the latest graphics hardware much more quickly. This allows the developer to take better advantage of the latest and greatest hardware (although the hardware to support the latest spec is often quite rare, such as DirectX 10.1 hardware right now).

      Second, partly as a consequence of that, you can usually do things faster under DirectX than under OpenGL, with a 2:1 speed ratio being fairly common, on identical hardware.

      Third as far as portability goes: obviously you can run either under Windows. OpenGL also gives you Linux, OS/X, and a few other markets like HP/UX and Solaris mostly mean nothing from a viewpoint of selling games. DirectX gives you the XBox, which means a lot from a viewpoint of selling games.

      As far as differences in the API, I can only guess that those who've gone on about how much better the DirectX API has gotten haven't really used it. DirectX started out about 10 times worse than OpenGL. It has improved, so it's now only about 5 times worse than OpenGL, but from a viewpoint of writing code, there's still no contest -- from this viewpoint, DirectX has never been close to as nice, and it still isn't.

      I suppose I should add that I'm not a games programmer -- I write OpenGL code on a regular basis, and have ported some to DirectX as well, but it's all visualization software, not games.

      --
      The universe is a figment of its own imagination.
    6. Re:Comparison to DirectX by WilyCoder · · Score: 1

      "Which makes it very straightforward to work with. You don't find yourself wondering how something will work. If you have any background in 3D graphics theory, things work in OpenGL exactly as you'd expect."

      Except that you have to apply matrix transformations in exactly the opposite order as you would if computing by hand ;)

    7. Re:Comparison to DirectX by Anonymous Coward · · Score: 2, Interesting

      OpenGL is a state machine, programmed in good 'ol C.

      Or any other language you want. I've used it from Python, and it's great. It's portable, fast enough for me (though I'm not writing Doom3 here), close enough to the C API that I can use any C reference, but still Pythonic enough that it's pleasant to work with. Plus, if you can put something (or everything) into a display list, it *really* flies.

      It's trivial to wrap a state machine. It took me about 2 minutes to wrap glBegin/glEnd with a Python 2.5 context manager, so I never have to write glBegin/glEnd again, and my code is indented to show the structure of my graphics. Very nice.

      I guess if you're writing games at iD (or to compete with them), C is the way to go. For the rest of us, a higher-level language is much less painful. If my boss wants a new visualization of some data in 3D, I can whip it up really quick in Python, and he won't care that it's only N fps instead of 2N fps, as long as N > 50. Or if he decides he really wants it faster, I can probably port it to C without much trouble.

      From what I've seen, Direct3D is not simpler than OpenGL with a HLL.

    8. Re:Comparison to DirectX by Lord+Crc · · Score: 1

      I've heard from people they feel it's easier to do a lot more things in DirectX than OpenGL. It's all opinion, of course.

      While I strongly prefer OpenGL over DirectX, on some points you just can't deny that it's easier with DirectX, being a more extensive library. Sound and multi-media along with 3d and more in "one package". It also has functions for stuff which is complex to implement, ready to be used (for example the Precomputed Radiance Transfer API).

      Another reason is that it's easier to verify that you're getting hardware accelerated features, and features that work (ATI has, in my experience, rather spotty OpenGL support). OpenGL 3 will fix the hardware detection issues, and hopefully make it easier to make good OpenGL drivers.

      Again, I really like OpenGL, and OpenGL 3 looks very nice indeed, but if you're going for an xbox+pc game, I'd say it's almost a no-brainer to go with DirectX.

    9. Re:Comparison to DirectX by Black+Art · · Score: 1

      What kind of patent problems will OpenGL 3.0 have?

      The current version of OpenGL has a couple of patented bits that make a 100% open source implementation difficult. Is that going to be even worse in OpenGL 3.0 or are they avoiding such traps this time?

      --
      "Trademarks are the heraldry of the new feudalism."
    10. Re:Comparison to DirectX by Bipoha · · Score: 1

      Yeah, it's called a matrix STACK for a reason.

    11. Re:Comparison to DirectX by mike260 · · Score: 1

      There are a couple of reasons. First of all, Microsoft tailors the API to the latest graphics hardware much more quickly.

      Not really. Pretty much the first thing GPU companies do upon releasing fancy new hardware is to ship new drivers with OpenGL extensions letting developers get at the new functionality. D3D only exposes new functionality when Microsoft decide to rev the API.

      Second, partly as a consequence of that, you can usually do things faster under DirectX than under OpenGL, with a 2:1 speed ratio being fairly common, on identical hardware.

      OpenGL makes it much easier to write low-performance code, which is why there's a common speed difference. But it's not very hard at all to make up this difference if you want to. The nVidia website has a buttload of info on how to achieve this.

      Third as far as portability goes: obviously you can run either under Windows. OpenGL also gives you Linux, OS/X, and a few other markets like HP/UX and Solaris mostly mean nothing from a viewpoint of selling games. DirectX gives you the XBox, which means a lot from a viewpoint of selling games.

      OpenGL's also the native API of the PS3, and the majority of 3D-capable phones. Plus, every other recent console has an API very closely modelled on OpenGL.

    12. Re:Comparison to DirectX by Mortlath · · Score: 1
      DirectX is a nightmare of ActiveX/COM objects.

      When was the last time you've used DirectX? COM is nicely hidden (See the code below).

      // initialize DirectX

      m_D3D = Direct3DCreate9(D3D_SDK_VERSION);

      // uninitialize DirectX

      SAFE_RELEASE(m_D3D);

      It's anything but pretty to look at it. It takes a lot of code to get started before you can do anything. There's a very steep learning curve to fight through before you can do anything at all with it. It gets easier once you've managed to get it going, but it still isn't pretty.

      I don't know what code you've been looking at, but I've worked with both OpenGL and DirectX, and both allow for clean code. Both have a learning curve.

    13. Re:Comparison to DirectX by Jerry+Coffin · · Score: 1

      Not really. Pretty much the first thing GPU companies do upon releasing fancy new hardware is to ship new drivers with OpenGL extensions letting developers get at the new functionality. D3D only exposes new functionality when Microsoft decide to rev the API.

      This is true to only a minimal degree. nVidia does quite a few extensions, and they do give some access to new "stuff". In a lot of cases, it's rather minimal access though, and in other cases, it's basically nonexistent. Just for an obvious example right now, I don't know of any way to get at the geometry shader functionality via OpenGL. It simply doesn't fit well with the (current) OpenGL model. ATI does far fewer extensions than nVidia, though we'll have to see whether that changes with the AMD buyout.

      OpenGL makes it much easier to write low-performance code, which is why there's a common speed difference. But it's not very hard at all to make up this difference if you want to. The nVidia website has a buttload of info on how to achieve this.

      Yes and no -- they certainly have a lot of information, and in some cases it's quite helpful. OTOH, they still don't cover everything -- just for one obvious example, DirectX has supported instancing for quite a while. Under OpenGL, you could sort of imitate instancing, but that's about it -- and yes, nVidia has had an OpenGL "pseudo-instancing" demo for quite a while, but if you compare it to their real instancing demo that runs under DirectX, you'll quickly find that the DirectX version is still faster. I'll grant that instancing isn't the be-all and end-all of programming, but for some kinds of games, I'd bet it's quite useful (for those who aren't graphics programmers, instancing is a technique for for drawing a large number of identical or nearly identical objects more quickly than specifying each object separately).

      OpenGL's also the native API of the PS3, and the majority of 3D-capable phones. Plus, every other recent console has an API very closely modelled on OpenGL.

      It's true that OpenGL covers more of the market than I noted. It's also true, however, that of those, the only one that matters as a rule is probably the PS3. Getting a game to run decently on a phone (for example) involves a lot more than changing the way you display the graphics. I'm curious: when you say "every other recent console", do you have more in mind than the Wii (not to to slam the Wii -- I'm just curious what else you might have had in mind).

      Another point that had been noted elsethread is that DirectX is a more comprehensive API, so a great deal more of the game becomes portable by it's being implemented on the XBox. I guess for those people running Linux on PS3's, SDL would give much of the same, but I doubt that's a large enough market for many people to care a lot about.

      --
      The universe is a figment of its own imagination.
    14. Re:Comparison to DirectX by Anonymous Coward · · Score: 0

      My experience in game playing was that OGL often outperformed Dx in the games I played. Granted, this was in the earlier days of OGL 1.2 and Dx3, so things have changed (in the fact that games just stopped supporting OGL for Dx9).

    15. Re:Comparison to DirectX by mike260 · · Score: 1

      This is true to only a minimal degree. nVidia does quite a few extensions, and they do give some access to new "stuff". In a lot of cases, it's rather minimal access though, and in other cases, it's basically nonexistent. Just for an obvious example right now, I don't know of any way to get at the geometry shader functionality via OpenGL. It simply doesn't fit well with the (current) OpenGL model.

      EXT_geometry_shader4
      What other stuff do you feel there's 'minimal' access to? nVidia has a history of doing real kitchen-sink extensions that expose EXACTLY what their hardware support (eg. NV_register_combiners).

      ATI does far fewer extensions than nVidia, though we'll have to see whether that changes with the AMD buyout.

      So far, I've found that their hardware features are well exposed. Plus, they do a nice line in hidden experimental extensions, which are good fun to play with.

      It's true that OpenGL covers more of the market than I noted. It's also true, however, that of those, the only one that matters as a rule is probably the PS3. Getting a game to run decently on a phone (for example) involves a lot more than changing the way you display the graphics.

      Agree. Plus, any PC game that's source-compatible with a phone is going to look crappy on the PC side. It just makes development a bit easier.
      So yeah, PC360 is probably the only situation where I'd expect any low-level graphics code to be shared across platforms.

      Yes and no -- they certainly have a lot of information, and in some cases it's quite helpful. OTOH, they still don't cover everything -- just for one obvious example, DirectX has supported instancing for quite a while. Under OpenGL, you could sort of imitate instancing, but that's about it -- and yes, nVidia has had an OpenGL "pseudo-instancing" demo for quite a while, but if you compare it to their real instancing demo that runs under DirectX, you'll quickly find that the DirectX version is still faster.

      EXT_draw_instanced

      I'm curious: when you say "every other recent console", do you have more in mind than the Wii (not to to slam the Wii -- I'm just curious what else you might have had in mind).

      I was thinking of the NDS, PSP and NGC. I haven't gotten the chance to mess with a Wii, but I assume it's graphics API is just a revision of the NGC's.

    16. Re:Comparison to DirectX by PsychicX · · Score: 1

      >> MicroSoft subsidizes training.
      Not for DirectX.

      >> DirectX is the native API to the OS on most peoples computers.
      There's nothing "native" about DirectX on Windows. I know, I worked on graphics drivers for one of the three big GPU companies (those three are Intel, NVIDIA, and ATI, in that order).

      I won't contest the book points.

      >> Microsoft managed to mastermind OpenGL standard development to halt to a freeze for several years, they no longer hold the same influence.
      To misquote Obi-Wan, they have done that themselves. In-fighting on the ARB was always a serious problem, and Microsoft was no more (or less) guilty than ATI, NVIDIA, SGI, Sun, Intel, Dell, Apple, or anyone else I forgot. One can only hope that the turn over of control to the Khronos Group will be an improvement.

    17. Re:Comparison to DirectX by PsychicX · · Score: 1

      >> DirectX is a nightmare of ActiveX/COM objects. It's anything but pretty to look at it. It takes a lot of code to get started before you can do anything. There's a very steep learning curve to fight through before you can do anything at all with it. It gets easier once you've managed to get it going, but it still isn't pretty.

      This has been fixed up heavily in recent years. The only remaining headache is keeping track of reference counts; in C++, you can use the CComPtr smart pointer template class to do it for you. Don't get me wrong; DSound and DInput are still a miserably painful mess. D3D, however, is quite alright.

      >>>>OpenGL is a state machine, programmed in good 'ol C.

      >>Which makes it very straightforward to work with. You don't find yourself wondering how something will work. If you have any background in 3D graphics theory, things work in OpenGL exactly as you'd expect.

      This only works if the only background you have in 3D graphics is from when SGI was still relevant. Modern graphics pipelines do not resemble what SGI had when they created IrisGL and later OpenGL, and the API has not evolved well. (It HAS evolved, just in sort of a haphazard and uncomfortable fashion.) That's why we're getting OpenGL 3.0 over the next year; this whole state machine that OpenGL (and a good chunk of D3D 9 for that matter) model no longer exists. Besides that, there are inherent inefficiencies in the OpenGL model. Don't take my word for this -- read the OpenGL 3.0 proposals by ATI from some time back. They call out these problems quite well.

    18. Re:Comparison to DirectX by autophile · · Score: 1

      OpenGL is a state machine, programmed in good 'ol C.

      Which makes it very straightforward to work with.

      Linus, is that you?

      j/k :)

      --Rob

      --
      Towards the Singularity.
    19. Re:Comparison to DirectX by Anonymous Coward · · Score: 0

      so, just what are the axioms of "3D graphics theory"?

    20. Re:Comparison to DirectX by Anonymous Coward · · Score: 0

      Maybe this is a FAQ, but could someone point us why most game developers prefer DirectX, even if, by choosing OpenGL, they'd have the possibility to develop games for other operating systems as well? Yeah, I know, Windows has over 90% of the desktop market, but why don't develop for the whole market if something like OpenGL exist? That's mainly due to the fact that during Windows9x times, Microsoft decided to offer only DirectX, there was no OpenGL available. So if you wanted to support "that 90% of users", you had only one choice that Microsoft had made for you.

      Nowadays DirectX is way more "usable" than back then. But such things don't matter when you had only one option.
  10. I've been waiting for Perl 6 to come out... by krog · · Score: 3, Funny

    ...before I replace my Camel Book, 2nd Edition. It hasn't worked out as well as I thought it might, 5 or 6 years ago.

    --
    Cretin - a powerful and flexible CD reencoder
  11. Re:opengl is dead by TomorrowPlusX · · Score: 1

    I know you're trolling, but get out of your parents' basement. There's more to the 3d visualization world than video games.

    --

    lorem ipsum, dolor sit amet
  12. What's missing in the review by Anonymous Coward · · Score: 1, Funny

    The reviewer does a good job of describing chapter by chapter and also the color the book's cover, but forgot to tell us what's on the inside cover and outside back cover. Of course no description of a book would be complete without info about what font was used to typeset. Who cares about the book's content when you've got such exciting reviewers. Write on...

    1. Re:What's missing in the review by Anonymous Coward · · Score: 0

      Hopefully it'll be in Comic Sans MS! :) It'll make the difficult bits seem a bit more friendly! :)

      Thanks! :)

      Sharon in HR

  13. OpenGL-enabled surface for graphics by nurb432 · · Score: 1

    I believe this is how blender still does it, the entire interface is written in openGL.

    --
    ---- Booth was a patriot ----
  14. Questions by LM741N · · Score: 1

    In any Linux or BSD system there is GL this, GL that. Yet the package that installs this seems to be called Mesa. Mesa I guess is still in development. Some OS versions fail to install the /usr/X11R6/include/GL Motif widget headers. I always have to go in and manually move them from the build directory to their useful location. Otherwise I have programs that won't compile.

    1. Re:Questions by jd · · Score: 1
      OpenGL is the version produced by SGI (and now by the OpenGL consortium) and is also the name of the official reference implementation. (Nobody seriously believes that a commercial vendor would use a reference implementation of anything if they could possibly avoid doing so. Reference versions are necessarily highly generic, which usually means that the code can't be efficient anywhere.) Mesa is a third-party re-implementation of OpenGL and, as far as I know, is feature-complete to whatever version of OpenGL that version of Mesa is designed to replace. Because it's a re-implementation, there's no guarantee of it being ABI-compatible in all cases, only API-compatible. If anyone exploits undocumented quirks in the official reference version, this will obviously break on any clone.

      Because of the way libraries are installed in Linux and *BSD (in a very few directories), name clashes when using Mesa and OpenGL are almost inevitable. All I can suggest is compile them yourself with different prefixes, then use library paths to pick up the right library for a given application.

      --
      It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
  15. Plenty of FUD there.... by Joce640k · · Score: 1, Interesting

    Direct3D is no more advanced than OpenGL so your "lot of money into research" theory is busted. Direct3D is really no more innovative than any other Microsoft product, ie. it's a tiny bit behind everybody else but it has a lot more marketing with the words "innovation" in it.

    They do spend a lot of money on PR and taking games company bosses to lunch.

    You can definitely get the exact same speed from OpenGL as Direct3D on top end hardware - I do it every day.

    OpenGL drivers for major graphics cards (ATI/Nvidia/Intel) are about the same level of stability/etc. as Direct3D drivers - both are really just an abstraction of the graphics card's own internal API so that's not really surprising. For other manufacturers Direct3D may have a slight edge here but Direct3D isn't 100% on those cards either. Expect problems with both APIs if you push them beyond the core functionality (e.g. trying to do CAD instead of games).

    OpenGL doesn't have "few windows apps", it has "few windows games". Microsoft spends a lot of money to make sure this is so.

    DirectX has awful support unless you're a games company - it's and ugly API (COM), the documentation is awful, there's no decent support groups and ... every now and again Microsoft will change the API so you'll to go through and rewrite your program.

    Deployment of Direct3D programs is a nightmare. The SDK changes on a monthly basis and you basically have to include the 30Mb runtime with your program or it won't run - the DLLs don't match up. If you search c:\windows for "d3d*.dll" you'll see what I mean - a long list of files of the form "d3dx9_XX.dll" where XX is a number indicating the SDK release. With OpenGL I can just give you a single .exe file and it will run on any windows installation since Windows 95.

    Direct3D is good for throwaway projects with limited shelf life. I can still compile and run OpenGL programs I wrote ten years ago, no problem. No that I really have to - they still work and even took advantage of new graphics card features when they appeared (eg. hardware vertex tranform). If those programs were Direct3D they wouldn't be working now, they'd need a rewrite.

    For professional games Direct3D is probably better. For everything else, and definitely for hobby work, OpenGL is better.

    --
    No sig today...
  16. Ugh, no. by mike260 · · Score: 1

    ABI? Undocumented quirks? Clones? What are you on about?

    OpenGL is the name of an API. Various companies make implementations for their hardware / OS, and then they pay SGI for the right to call their implementations 'OpenGL' (after passing a load of conformance tests).
    Mesa is an implementation of the OpenGL, it just hasn't been officially blessed by SGI (although they do support it's existance in other ways) so it can't legally call itself OpenGL.

  17. Q about book by autophile · · Score: 1

    Is this one of those books where the 860 pages is mostly filled with API documentation? Or is this a genuine how-to book? I'm definitely interested in learning OpenGL so that I can write a nice GUI for simple games, but it's hard to know where to start.

    Thanks,

    --Rob

    --
    Towards the Singularity.
    1. Re:Q about book by mike260 · · Score: 2, Informative

      It's a genuine how-to book, and a pretty good one at that. That, plus NeHe, are excellent ways to get started.

    2. Re:Q about book by the_greywolf · · Score: 2, Informative

      Believe it or not, it's actually both. It is the official standard API documentation, but it's written for the benefit of both implementers and users. Because the standard describes very specific behavior (including side-effects) of implementations, it's the most important and useful resource for users of the API. That, and the book describes in very clear terms how to use the API. It's not a beginner's HOWTO manual, but it's very, very close.

      I own 5th edition, and it's the OpenGL reference I use the most.

      --
      grey wolf
      LET FORTRAN DIE!
    3. Re:Q about book by Anonymous Coward · · Score: 0

      The OpenGL Red Book is intended to be a how-to, of sorts. There aren't any big projects outlined, but there are lots of little examples showing how each feature works. IIRC, there was a separate complementary OpenGL "Blue Book" that was the official API reference, listing each OpenGL function in alphabetical order along with parameters, technical details, etc. This is my recollection from many versions ago, though, so maybe this has changed since then.

  18. Urgh, yes. (AKA: oss.sgi.com 101) by jd · · Score: 1

    OpenGL is the name of the API, which is what I said. I also said it was the name of the reference implementation provided by SGI (which it is). A reference implementation gives you an ABI and - invariably - quirks. SGI's OpenGL code provided in X11 and on their OSS pages are a reference implementation, not a commercial implementation. Even though OpenGL does not specify an ABI - it is an API specification - it is inherent in the process of having a reference implementation that people will code to the ABI provided by that reference version so that their code can just drop in.

    --
    It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
  19. this is why dx is better than opengl by HelloKitty · · Score: 1

    since version 8, directX has been far easier to program than opengl...
    it is easy to create a directx application,
    - you no longer have to deal with the crazy amounts of COM crap
    - the init calls are really streamlined now.
    - also nehe has tutorials for lots of dx apps
    directx mirrors the hardware more correctly (was more true back with DX8/9), meaning that your code will run faster. (however opengl is catching up fast)
    game developers really really care about performance.
    microsoft gives support, and hs a really really smart team who can help give great ideas on cutting edge usage (i've met them).
    opengl extensions are really annoying to sift through to find what you should be using... dx9 API is right there. so much fixed function clutter still in opengl.. :(
    PC drivers support directx better (usually).
    xbox 360 supports directx (mostly), so code will port to a significant paying market (unlike you free loadin linux hippies - just kidding).
    great documentation.

    this is why directx is preferred these days.
    (I was a huge a opengl advocate pre DX8, definitely not a fanboy).

    that said, it's not too hard to make a wrapper around both DX and opengl using the highest performance graphics driver calls. both APIs today have the features...

    --
    music - http://www.subatomicglue.com
  20. INTERFACE, not implementation. by lancelet · · Score: 1

    I think the confusion here is that you are stating that there are quirks in the ABI. ABI = Application Binary Interface. Two completely different binary implementations can have the same binary interface. Implementations usually have the quirks, not the interface itself, whether it's binary (ABI) or a programmer-friendly format (API).

  21. Re:Comparison to Direct3D by M0max · · Score: 1
    I found this post of Norbert of AutoDesk, developer of Autodesk Inventor - 3D MCAD software capable of using both DirectX AND OpenGL). I just quote most of it - this inside point of view:

    ...Direct3D is different. It is a separate 3D graphics API whose specification is controlled by Microsoft. As such, Microsoft can make the requirement that any graphics HW, consumer or workstation, that wishes to be WHQL (Windows Hardware Quality Lab) certified for Windows, must pass the WHQL testing and certification suite which tests for compliance with the Direct3D specification. This assures that if a graphics driver passes WHQL certification, there is a certain level of compliance and reliability associated with the graphics driver, both for 2D (e.g. GDI, GDI+) and 3D (meaning Direct3D but _not_ OpenGL).

    ... [snip] ...

    Specifically, regarding your question about working around developments in the gaming industry ... Autodesk is working very closely with Microsoft to incorporate support for CAD features and capabilities into Direct3D. We are working very closely with Microsoft to make sure that CAD usage is tested as part of WHQL testing and certification of Direct3D graphics drivers. This will apply to _all_ graphics HW on the Windows platform, meaning high end "workstation" graphics HW, consumer graphics HW, and low-cost graphics chipsets that come on-the-motherboard.

    I would like to take a slight digression just to give a bit of a historical perspective on the issue of 3D graphics HW. I have been around long enough to have worked with 3D graphics HW _before_ OpenGL existed. In that earlier time period, I worked with over seven different 3D graphics APIs. When SGI succeeded in imposing OpenGL as "the" 3D graphics API on the entire industry, this was not viewed as a "wonderful event" by everyone in the SW industry. The HW industry loved it, and they have been rather successful in ignoring any innovation or suggestions for 3D graphics development from the SW community during the entire time OpenGL has existed. Autodesk has attempted to work with the OpenGL HW community to enhance 3D graphics but has been met with a very deaf ear by the OpenGL HW community, similar to the experiences of many other SW vendors. Perhaps one exception to this situation has been the willingness of some OpenGL HW vendors to "adjust" their OpenGL implementations so some 3D games using OpenGL will run better ... but there has been little, if any, serious collaboration between graphics HW vendors and CAD SW vendors to incorporate features that seem reasonable from a SW perspective. Perhaps this is one reason why there are over _350_ documented OpenGL "extensions" that expose various "features" available on various generations of graphics HW from various HW vendors.

    Microsoft has had a long and interesting history with Direct3D and they have had some evolving to go through to reach the point where they are now with Direct3D 9 on WinXP (and Win2K) and Direct3D 10 on Windows Vista. However, the _most_ important aspect from a SW development (and computer user) perspective is that Microsoft has been willing to listen and incorporate suggestions from the SW community. The resulting Direct3D specifications (as well as SW development tools) that have come from Microsoft are at least a generation or more advanced beyond the rather obtuse, cryptic OpenGL specifications and stone age development environments that the graphics HW vendors push at SW developers to use with OpenGL.

    The bottom line is that competition is good and the fact that we have Direct3D as a professionally developed 3D standard instead of being forced to use OpenGL is very healthy. Without Direct3D, we are completely at the mercy of the graphics HW vendors in terms of what they believe the industry needs. For example, I continue to be amazed at how we as computer users seem willing to "accept" a blue screen crash or an application crash-to-the-desktop caused by an

  22. An arguably better summary, courtesy of ots by ccharles · · Score: 1

    The Red Book, also known as the OpenGL Programming Guide published by Addison-Wesley Professional, returns in its sixth edition with additions covering OpenGL 2.1. Even though the coverage was expanded, the authoritative guide to shader programming in OpenGL still remains the Orange Book aka The OpenGL Shading Language (see my previous Slashdot review). The following chapters proceed to explain the basic geometric primitives, such as lines and polygons, supported by OpenGL and how to render them in different positions and from different viewpoints using the various OpenGL matrix stacks. Most notably this chapter now covers pixel buffer objects, a fairly recent addition to OpenGL, which the fifth edition of the book did not mention. Even though the OpenGL API functions required to use GLSL are presented, this is only a rough overview of how programmable shaders are used in OpenGL.

    The book closes with quite a few appendices on the order of operations in the OpenGL rendering pipeline, the state variables that can be queried, the interaction of OpenGL with the operating system-specific windowing systems, a brief discussion of homogeneous coordinates as used in OpenGL, and some programming tips. If you've read through the Red Book and the Orange Book in their entirety you pretty much know everything there is to know about OpenGL.

  23. Re:ya right. by Anonymous Coward · · Score: 0

    directx 10 until Microsoft need a new version that will be bundled only with its new Windows version forcing everyone to upgrade, suck it up people who use an open standard, who don't have to worry about vendor lockin.

    There, fixed it for you. Yeah! You'll never have to worry about upgrading to a new version of Linux to play BioShock or F.E.A.R. because they won't ever run on Linux! Yay open standards! But I'm sure playing half-hearted ports of Quake and Unreal Tournament (a year after they're released on Windows, no less) more than makes up for it, right?

    Suck it, dweeb.
  24. What the?! by Anonymous Coward · · Score: 0

    Didn't opengl die with quake2? lol