Three-dimensional sprites The glshapes.* files in the Pop Framework provide some standard 'glut' methods for drawing three-dimensional shapes. 'Glut' stands for 'OpenGL Toolkit.' Although the glut library includes a lot of useful high-level OpenGL methods, we only incorporate this one single glut file into the Pop Framework at present, in part because glut is based on a non-Windows framework that makes parts of it incompatible with MFC

 The Gamestub3D showing OpenGL sphere, teapot, torus, and some polyhedra. The cog-like shapes are cPolyPolygon

The glshapes files implement the following function calls, where GLdouble means the same as double, and GLint means int.

'teapot,' by the way, is a standard test shape beloved of computer graphics programmers, and built up by using 'Bezier patches.' It's sometimes called the 'teapotahedron,' and is jokingly viewed as the sixth Platonic solid!

 The slices and stacks parameters used for the circular shapes can be thought of as the number of northsouth longitude and eastwest latitude lines, respectively. That is, a sphere is drawn as a vertical pile of stacks many slices-sided polygons. You need values of at least 12 or so to make these shapes smooth-looking.

 What you should do for this problem is to implement some or all of the classes cSpriteSphere , cSpriteTeapot , cSpriteTorus , cSpriteCube, and so on. First do one, and get it debugged, and then try a few more. You can try testing them out as sprites used by the critters in cGameDefender3D.

 Each of the classes should have a constructor that takes a Real radius argument with a default value of 1.0. The circular sprites have additional int slices and int stacks arguments with default values of, say 12, though these defaults ought to be statics. And the torus and cone each have an additional Real parameter: the torus should also have a Real inner radius argument and the cone also needs a Real height argument.

 To draw the sprites, you could go one of two ways: many classes or one class.

 Many classes

 You could have each class emulate the behavior of cPolygon and cSpriteIcon and define, say

, void cSpriteSphere::imagedraw(cGraphics *pgraphics, int drawflags)

 {

 pgraphics->drawsphere(this, drawflags);

 }

 And you'd have to add a new drawsphere method to cGraphics, giving it a void or trivial implementation for cGraphicsMFC and giving it an implementation in cGraphicsOpenGL that calls glutSolidSphere or glutWireSphere depending on whether psphere->filled() is TRUE.

virtual void drawsphere(cSpriteSphere *psphere, int drawflags ) You'd need to override imagedraw and implement a differently-argumented variant of cGraphics::draw something for each of the nine classes, which is a little boring to do.

One class

You could get by with slightly less typing by having all of these new classes inherit from a catch-all cSprite3D class. We could prototype cSprite3D something like this.

 And then you'd only need to prototype and code a single cGraphics method.

 virtual void draw3Dshape(cSprite3D *pshape, int drawflags )

; The cGraphicsMFC version of draw3Dshape can just draw a circle, while the cGraphicsOpenGL implementation will hold a big switch on pshape->shapecode(). Is the cost of the switch something worth worrying about?

No. Although we didn't raise this point earlier, the cSprite::draw method is constructed so that it will avoid the switch after the first call to a given draw method for a cSprite3D by using display lists. You will need to do some work to implement a correct radius() method for these sprites, and to have the value returned by radius() match the radius argument that you feed in and to match the visual appearance. If possible make radius() match the number in the _radius field, it may be that cSprite3D needs to maintain a supplemental Real _glutradius for the parameter that you actually feed into the glut call in cGraphicsOpenGL::draw(..), or for the parameter that you perhaps use in a scaling matrix. Compare our use of a Real _visualradius in the cSpriteIcon code.

The reason that radius is an issue is because you compute the distance from a cube's center to its corner one way, but you compute the distance from a tetrahedron or a cone's center to its furthest point another way. We care about the radius because in order for our cheap and dirty collision code to look right, the 'radius' of a sprite needs to match the radius of the smallest sphere that encloses it.

Pop Version 26 2. May 15, 2002, Rudy Rucker. - [Pop 1| Yew Game Blayer Window Help FO Score Health 5 Total Ciers 26 Updates per secord 12 (Slower than Real Time)