Updates
Latest Tweet
What's New?
Check out for latest innovation, a computer based training video collection
Like this Page
OpenGL SuperBible (3rd Edition) Review by Skayen
It wastes space by covering irrelevent detail
My problem with this book can be surmised as
- it assumes the reader knows nothing about programming;
- it tediously explains the obvious;
- it is laced with irrelevent code that is over-documented to waste space;
- it wastes space with reference material that would be better suited on the CD (if the authors wanted to include it);
- and it ultimately doesn't _TEACH_ very much
"OpenGL Programming Guide: The Official Guide to Learning OpenGL"is by far a much better book to read. It has code examples, certainly, but there is only one very succinct example per chapter to demonstrate what the chatper taught.
This book is like many computer books that assumes the reader knows next to nothing about programming. I think this is a poor way to write books on a particular subject. I believe that a book on computer graphics should be ABOUT computer graphics and should therefore assume the reader is already a competant programmer. You have to learn how to walk before you can run; and you have to have some idea of how to program before you can begin to think about programming graphics. Surely, then, the book should be aimed at people who can already program; and if someone can't program, they should buy a book on programming first.
For example, page 51 says:
"Listing 2.1 contains only one include file:
#include
This file includes the gl.h and glut.h headers, whcih bring in the function prototypes used by the program."
Surely a potential reader should be expected to know why include files are included? (This section also raises the question; why not just #include GL/gl.h and GL/glut.h and be done with it? But I digress.) It continues;
"Next, we skip down to the entry of all C programs:
void main(void)
{"
Are the authors serious? If they are, then perhaps the next version of the book will begin with a tutorial on what a computer is and how to read English. (Incidentially, a discussion on "constructors to initialise variables" is on page 992; so it doesn't just stop at chapter 1)
I believe a graphics book should talk only about graphics priciples and use code only at a bare minimum. Code is just a vehicle for implementation; using it to replace or augment discussion only demonstrates an inability to express ideas. The book is heavily laced with irrelevent examples. For example, pages 550-554 tediously transcribe the code to draw a bold head, which is ultimately an extruded hexagon. What does the source code prove or demonstrate? Do the authors believe the reader's heads are completely full of dead insects and can figure out the code to draw an extruded hexagon for themselves? If you want to include code, anyway, why pad it with irrelevent space, like
// Done drawing the fan that covers the bottom
glEnd();
you could collapse the comment (which is largely irrelevent, anyway) and call to glEnd() to one line and save space. Sure, it's only one line; but this is ONE example from a book that wastes pages and pages with useless code examples. I guess it is aimed for readers who feel happy buying big, expensive books.
Heh, another example of the insane levels of over commenting:
float CubeRotation[3] /* rotation of cube */
cheers for that, Mr Authors Sir! I could never have guessed the purpose of the variable CUBE ROTATION represented the CUBE'S ROTATION. I'm so glad you're there to tell us these things.
The book also dedicates a LOT of space to detailing the manual pages of OpenGL which they've just grabbed from an online man(ual) page. So, this book is an expensive way of getting specification stuff that doesn't actually TEACH you anything. However, if the authors want to include man pages, why do they insist on expanding out the definitions? Other books on OpenGL that I have seen conveniently use well understood regular expressions to represent the vast range of OpenGL prototypes rather than tediously enumerating EVERY variant of the function. glVertex*(), for example, has 12 versions divided into 3 groups. Each group represents a different number of parameters (2, 3 or 4); and each member of that group has a different type (double, float, int, short). Most books write that explosion of types as glVertex~n~type(type v1, type v2, ...)... and that's it. Instead, the authors spend half a page listing each prototype... not just for glVertex, but for the MYRIAD of OpenGL prototypes that have a SIMILAR state-explosion. Great.
The book is certainly designed to be big and hefy and look important. It does that by uselessly padding space, including too many code examples without any point, and including reference material that the athors didn't write. Very little space is actually dedicated to TEACHING the reader about OpenGL.