I've got a master plan (to take your API down)...

After that I get the freeglut Windows port working in an acceptable manner and thus getting assured that the freeglut internal structure is valid, I will split the project into three separate parts, listed below.

- freeglut-common

The least common denominator between the two freeglut versions. This will probably contain most of the internal structure of the toolkit, notably the windows and menu hierarchy, and possibly some private helpers.

- freeglut-1.3

The GLUT API 3 compatible library. This is what's can be found now in the alpha release (apart from the bugs, naturally :D).

- freeglut-2.0

Hopefully this will be what GLUT should have been from the beginning. I will give a try to design a much more coherent API than GLUT's, aiming at fast games prototyping. Suggestions are welcome.

Here's a list of propositions I have received so far. Hopefully this some day turns into an API spefication proposal, not just a bunch of meaningless phrases...

- glutBitmapHeight() and glutStrokeHeight() -- I have added them to the freeglut-1.3 API, they are already implemented and should work fine,
- glutBitmapString() and glutStrokeString(), to write (multiple-line maybe) strings, starting from the current raster position, using some simple formatting maybe (changing the color, font, etc.?)
- texture mapped fonts -- this is easy and could be added to freeglut-1.3, but would require adding the...
- glutHint() function to tell freeglut to: use bitmapped/texture mapped fonts, draw the menus and mouse cursor using OpenGL/window system, and stuff...
- glutMainLoop() termination and glutMainLoopStep() function, which should perform a single check of pending events, so that one can have his own main loop,
- multiple joysticks support with multiple axes, buttons, hats, etc. It is a real good thing to do, yet the API to do the magic might result in being really twisted,
- glutModifierFunc() could be added, or glutGetModifierState() should be allowed to be called anywhere from the client's code

We might also think about:

- freeglut-2.0 modularity via plugins, so that only the features that one needs get loaded (plugins are easily supported by GLib),
- OpenGL state management functions,
- audio support -- using OpenAL maybe?,
- a real menu system, not only the popups
- non-OpenGL but portable UI, something like Java Swing
- window-closing confirmation box (this is related to the above)

Following ideas are bad for freeglut:

- more accurate timers under Win32 -- this goes to the GLib development afaik
- portable file I/O, portable threads, plugins/modules -- this is already done in GLib
Back to the main page