From: Brian P. <br...@tu...> - 2003-06-17 14:54:25
|
Fay John F Contr AAC/WMG wrote: > Brian, > > Welcome aboard, again. > > While I don't have anything against adding a "glutGetProcAddress > ()" function, I am curious as to why you want the functionality. > Most--well, I guess all--of my graphical programming is self-taught and > I am always looking for gaps in my knowledge that need filling. And I > think you just pointed one out to me. Suppose you write a program that uses GL_NV_register_combiners if it's available (and use a fallback path otherwise). You'll need to use the glCombinerInputNV() function. If you call glCombinerInputNV() directly, your program will only run (link/load actually) if you're using NVIDIA's OpenGL library. By using a function pointer instead of a regular function call, the program can avoid this portability pitfall. The glXGetProcAddressARB() and wglGetProcAddress() functions were designed to solve this problem. Clearly, calling glXGetProcAddressARB() directly from within a GLUT program violates GLUT's window system abstraction. A second feature I'd like to add is a GLUT_FPS env var. If it's set, its value will be intepreted as a time interval in milliseconds. Then, glutSwapBuffer() will print a frames/second report to stdout every N milliseconds. This basically lets you measure the frame rate of any GLUT program. I had prototyped it in regular GLUT and I find it useful. Sound OK? > We're starting to gear up for an official release. We've had > two requests in the last month or so. Last Thursday at 9:17 AM (if you > want to check the archives) I put out a request for file changes to > "freeglut" and for demo programs to put into a release. I have a batch > of my own changes that need entering into CVS and I have a couple of > demos (2-d fractal generators using Michael Barnsley's algorithms). I > don't have a time line but I do have a sequence of events: > > (1) Everybody gets his changes into CVS > (2) Everybody checks out the new CVS version and runs all his > pet programs using it > (3) Somebody creates a release tarball > (4) Everybody checks out the release tarball and makes sure it > runs properly on his system > (5) Steve Baker announces a new release. > > While I have been in open source projects for a while, I have never > overseen this sort of thing before. I am certainly open to hints, > suggestions, or even an outright transfer of control to somebody else. > I just don't want to see the ball dropped. Sounds like a good plan. I can have my changes checked in soon. -Brian |