I have just asked Brian Paul (thank you, Brian) to put into CVS for me a revised version of "freeglut_geometry.c" which supports the following changes:

                - The sphere, torus, cone, and cylinder functions no longer terminate on error if called with zero slices or stacks.

                - The octahedron now has proper winding on all eight sides.
                - The vertices for the tetrahedron are now static variables outside the functions.
                - The Sierpinski sponges now reuse the tetrahedron coordinates.  This makes the code a trifle shorter but does change the size and orientation of the Sierpinski sponge.

        I made the last set of changes because they shorten the code and reduces the size of the library a smidgen.  If anybody needs the Sierpinski sponge to return to its previous size and orientation please let me know and I'll back the changes out.  As it is with the changes, however, the sponge reuses the tetrahedron coordinates.

John F. Fay
-----Original Message-----
From: Fay John F Contr AAC/WMG
Sent: Monday, September 13, 2004 2:55 PM
To: ''
Subject: More proposed "freeglut" changes


        In the quest for an improved "freeglut", I would like to propose the following.  I got a lot of this from comparing "freeglut" with OpenGLUT a few weeks ago.

(a) In the "freeglut_geometry.c" file, I suggest that we check for zero "slices" and "stacks" arguments before dividing by them.  This would prevent the application from terminating on error.  GLUT calls "gluSphere" and "gluCylinder" for the appropriate shapes; with MSVC at least these do not terminate on error with zeroes for the number of slices and stacks.  For the torus GLUT does not check for division by zero and so does terminate on error; thus the suggested change would bring "freeglut" more in line with GLUT in the case of spheres, cones, and cylinders and would make its behavior diverge from that of GLUT in the case of the torus.

(b) Also in "freeglut_geometry.c", I propose to move the tetrahedron corner coordinates out of their respective functions and make them static in the file.  This will allow us to avoid defining them in two places.  We already do this with other shapes.