Given that the sources for GLUT don’t seem to be ever going to make open-source, and there are many problems which need sorting out and updating. The argument for other packages is compelling - and hence the reason this section has others in it!
However, as pointed out by many, GLUT is pretty ubiquitous, and is used in many books and online web tutorials.
The proposal is to provide a GLUT emulation layer on top of a.n.other (maybe more than one) package.
However, it would NOT be sensible to try to recreate the whole API, and I therefore propose we should look to provide at least the functions calls used in e.g. redbook and the other major web sites. Not many calls in the end I’m sure.
Can folks please post up the list here so those of us considering doing the work can be sure we don’t miss a call out.
With help I’m sure we can make this happen, and then the source code in so many places both on-line and printed can still work!
Your proposal sounds like a good one. To make the process a bit quicker, maybe one could hack up a simple Unix shell script that does some statistics on GLUT programs.
Just download as many GLUT programs as possible (that seem relevant), place them in a dir, and do some clever grep | wc, and count the matches. That should give a good start. I’m not a shell guru, but I suppose csh or ksh should be the right tool.
Counting programs that use a certain call is probably better than counting total number of calls.
Function calls is not everything. Constants (e.g. glutGet( GLUT_XYZ )) are also important, but can be handled in the same way, probably.
That should give a rough break down, which can then be manually sorted in priority order.
To make it even easier to build such an
emulation layer, you can probably borrow
some big pieces of this from the freeglut
sources which are open sourced.
Originally posted by robus: I count totally 107 distinct glut functions in “GLUT 3.7, Macintosh Implementation Reference Manual” and many, many constants and some built-in types.
The idea was to find the most widely used subset of GLUT to focus on when designing the emulation layer. Wouldn’t it be nice if every single Redbook example compiled with the emulation library - even if it only implements 30% of the functions?
More functions would be added later, of course, but priority #1 must be to get a working prototype to build upon - a proof of concept if you will.
Rob: The next version of GLFW will be quite nice - superior keyboard interface for one thing: national keyboard, ISO-8859-1 8-bit encoding for the present key interface (plus loads of special keys, of course), plus an additional Unicode character/text interface (way ahead of GLUT anyway). Another thing is - Mac OS X support (state = “almost working”).