+
+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
+
+ |
