Offscreen rendering to a texture using OpenGLEAN
There was an alternative library with a goal of being compatible: freeglut. freeglut had its own warts, but none as bizarre as the GLUT bug. This author submitted some requests and patches to the freeglut project, and was invited to be a freeglut developer.
For some time, this author worked on freeglut, but also developed a desire to add certain features that went beyond freeglut's scope. freeglut is geared only to be a drop-in for the last released version of Mark Kilgard's GLUT. Growth and innovation are very limited in freeglut.
So the presure began to mount almost immediately for a fork of freeglut.
Eventually, another freeglut author contacted this author suggesting that it was time to fork freeglut. This had not been discussed between them previously, but came to a head over deeply held convictions about the desirability of a more featureful GLUT like library. freeglut would never grow in the required way. Thus OpenGLUT was born. They added features that freeglut would not support, such as offscreen rendering, menu windows, etc. The OpenGLUT project documented the library as a major effort. They fixed many bugs. Most of OpenGLUT's changes, other than the documentation (the single biggest effort) and the new features, were either lifted verbatim back into freeglut (e.g., the vastly improved bitmapped font handling) or were re-implemented in freeglut (closely modeled on the trail-blazing that OpenGLUT had done.
Meanwhile, it was apparent that OpenGLUT was not going to be moved into one of the main directions that this author had always wanted. Namely, removal of "deadwood" features. E.g., there is no completely backwards-compatible way to "fix" gamemode. One or two functions had been obsoleted by Mark Kilgard's original GLUT in the 1990s while Mark was still active. Other problem features were ill-defined across multiple implementations. Then again, this author felt that if OpenGLUT were going to move beyond the realm of a toolkit for simple demonstration programs, and into the realm of a serious portability toolkit, OpenGLUT should define a clear focus for the library, and features that did not fit into that clear focus should be migrated out of the library.
The whole idea of trimming dead or obsolete features from OpenGLUT had been key to OpenGLUT's founding, since it was one of the main objectives of 50% of the founders. Unfortunately, the OpenGLUT team could never reach any consensus about actually removing dead features, and it was long past time to begin that process---a process that should have been done shortly after OpenGLUT began building.
So, taking his work up again, this author is finally beginning the work he stated he wanted to do when OpenGLUT was founded. OpenGLEAN, destined to be a leaner member of the GLUT family, was born in late 2004.
In some ways, it is unfortunate that the work has not continued under one library. However, from the other side, it is fortunate that two other libraries have been able to share in part of the work put into the codebase now called OpenGLEAN. Also, as freeglut chiefly aims at being a drop-in for already-compiled software, freeglut really should not change the library API number, which constrains it to be as compatible as possible (no function removals, however disagreeable the API may have been; even feature additions are dubious).
Remember: Forking is good in many cases. It means that there is energy and passion finding an outlet that did not exist before, for whatever reason. Energy and passion is what open source thrives on. Whether there was a way to uncork that energy and passion without forking, a fork only happens if pressure is forced to intolerable levels. (This must be said, since some push a propoganda that "forking is always wrong" or "forking is always a mistake". It may not always be right, but to categorically say that it is always wrong is either to over-simplify or to actively disemble. For OpenGLUT and OpenGLEAN, the fork was forced and was the best thing that those doing the fork could have done.)
General features of the GLUT family:
Within the family derived from freeglut, these features are possessed:
Shared with OpenGLUT are these features:
Additional OpenGLEAN features:
libtool versioning. OpenGLEAN can't claim perfection, but is being perhaps more nit-picky than most.UNIX_X11 builds to access the GLU library. This is intended to let you slightly reduce dependency webs in package systems, but it also lets you run entirely without GLU if that is desired for some reason. Use of dlopen() is optional.enum instead of #define for defining many integer constants. This makes the code clearer to read. It also helps avoid having two distinct API constants with the same value. Finally, because #define is resolved by the CPP, while enum is seen by the main pass, some debuggers may see the enum symbols but not be able to see the #define symbols; OpenGLEAN will make debugging easier in those cases.Plans:
linting, and use of other tools to eliminate potential, subtle bugs.TODO file. You can't see it from the web pages. The disposition of that file with respect to the web and "installed" documentation is undecided at this point.Some of these plans are intended to make OpenGLEAN a more stable API and implementation. Anyone who has administrated a UNIX-like system and dealt (seriously) with security issues in libraries such as PNG, JPEG, and TIFF (each of which has, if memory serves, had advisories just in the year 2004) will appreciate the value of symbol privacy and reduced dependancies---and won't sneer at faster builds. Developers with an eye to the future should appreciate that OpenGLEAN intends to break historic compatibility early: Through the fire once, quick and clean. This is seen as preferable to late and slowly. Once the pruning is done, the API should be stable against further losses for a long time to come. Features will be added, but retaining backwards compatibility will be a goal, and at the same time buggy "fluff" won't be an issue.
In addition, the OpenGLUT API proposals are still on the table: OpenGLEAN API Proposals.
Other OpenGLUT ideas being considered for OpenGLEAN; see also the other sub-projects:
Menu window using OpenGLEAN
OpenGLEAN 1.0 will neither be a proper superset nor subset of GLUT 3.x.
The motivation for the OpenGLEAN API is to make OpenGL based development easy, productive and reliable. We would welcome feedback in relation to API proposals, results with using OpenGLEAN in applications, and feature requests or proposals. There may well be functionality in your own application that could serve a broader long-term purpose.
There are various reasons for using a private tree. One was the desire to be able to track back through OpenGLUT history. Another is that at project inception, OpenGLEAN was wavering between being a private project and a public project; with neither a SourceForge project nor a domain name in the public eye, a private tree was created. Now, there is enough history in the private tree that migrating to a public tree may be problematic, even though some of the value of the original private tree has been undermined by rearrangments of the code relative to OpenGLUT.
Supported in part by SourceForge.net.
Generated on Fri Sep 16 20:15:18 2005 for OpenGLEAN by
doxygen 1.4.3
The OpenGLEAN project is hosted by
olib.org and
SourceForge.