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
|