January the 16th, 2000

It looks like both X11 and Win32 version have reached a comparable usability stage. They are still missing many GLUT API 3 features, but the number is getting smaller and smaller every day :)

• input devices

Keyboard and mouse seems to work well. There is a big guess about the mouse buttons count under X11 (always 3) -- I must remember to correct the menu activation code if this shows to be invalid.

None of the bizarre input devices found in GLUT API is supported (and probably won't).

Steve Baker contributed the joystick code. It should work fine, as it did in PLIB, but I haven't tested it out yet. It might not compile under FreeBSD, as I had to convert it from C++ to C and had no possibility to compile it under FreeBSD (the Win32 version had some typos, but I've already fixed them).



• pull-down menus

Pull down menus seem to work. The menu is displayed using OpenGL, so it requires the window's contents to be refreshed at an interactive rate, which sometimes does not happen. That's why I'll consider adding optional window-system menu navigation later. For now -- extensive testing is what I believe should be done with the menu system.



• fonts

Bitmap fonts support is done. However it would be good to add two more API functions -- glutBitmapString() and glutStrokeString(), which should limit the quantity of state changes when drawing longer strings.

Good that somebody finally told me where to get the stroke fonts data from... XFree86 sources contain the ROMAN and MONO ROMAN stroke fonts data. For now stroke fonts are rendered using the bitmap font GLUT_BITMAP_8_BY_13.

What has changed is the way the fonts are specified. I moved to the GLUT's strange way of supplying (fake for freeglut) font data pointers instead of some nice enums. Hope it helps in achieving the binary compatibility between freeglut and GLUT.

Added two new API calls: glutBitmapHeight() and glutStrokeHeight(), that return a font's height. Hope this doesn't break the GLUT compatibility a lot.



• mouse cursor

Need to have own cursor shapes, so that freeglut can pass them to the windowing system, draw them using glBitmap() and/or texture mapping. The cursor shapes are very probable to be found in XFree86 sources.



• indexed color mode

This might work, however I have not tested it yet. glutGetColor/glutSetColor is not implemented. Again, looks like a single Xlib call, but there might be some problems with the colormap access. Need to switch into indexed color mode some day and check it out (does Mesa 3.1 work with indexed color mode?)



• planes

Overlays are not supported, but one of the GLUT conformance tests fails due to glutLayerGet( GLUT_NORMAL_DAMAGED ) returning FALSE when the window has actually been damaged.

Layers would be good for drawing the menus and mouse cursor, as they wouldn't force the application redraw to update their state.



• init display string

I am in middle of the fight with the init display string. It's parsing OK, now it would be cool to make it impress some effects on the display...



• game mode

Is the game mode string parsed correctly?



• geometry

Andreas Umbach has contributed the cube and sphere code. The teapot rendering is done using free SGI code. I have also added the cone rendering, however it is missing normal vectors (just as Andrea's wireframed cube does). All of the glut*hedron() functions await to be implemented.



• obvious bugs



1. the visibility/window status function is a conceptual mess. I had to peer into the GLUT source code to see what actually happens inside. It helped me a bit, but still one of the visibility tests fails. This is probably the reason for which a window covered by enlightenment status bar is marked as hidden and does not get redrawn.
2. GLX 1.3 spec states that glXChooseVisual() et consortes are deprecated. Should move to glXFBConfig.
3. need to investigate what happens when initial window position is set to (-1,-1). GLUT specification says, that the window positioning should be left to the window system. And I do not know how to force it do so...
4. I was told it is wrong to have the redisplay forced in the main loop. Is that right?


• not so obvious bugs



1. some of the tests freeze because they do not generate the glutPostRedisplay() call every frame. Again, this is somehow handled by GLUT, but I can't see how. And why.

   Looks like I've fixed it (or rather hacked it?) by forcing a redisplay every frame, but this is no good and kills interactiveness of my console :D