X-Git-Url: http://git.mutantstargoat.com/user/nuclear/?a=blobdiff_plain;f=doc%2Fprogress.html;fp=doc%2Fprogress.html;h=8a844835ddfceadf3b462667dbde1354f1deabac;hb=057254a3eaf0f58056b025bf34f6be860cbfbbb4;hp=0000000000000000000000000000000000000000;hpb=192b34825a36ab967867865ba3c7886c2331531b;p=freeglut diff --git a/doc/progress.html b/doc/progress.html new file mode 100755 index 0000000..8a84483 --- /dev/null +++ b/doc/progress.html @@ -0,0 +1,137 @@ + + + + + + + + + + The freeglut project + + + +
The freeglut logo
+
+I love reports. They are so full of brightness and hope... +
+ +

+ +

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. + +
    3. +GLX 1.3 spec states that glXChooseVisual() et consortes are deprecated. Should move to +glXFBConfig.
    4. + +
    5. +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...
    6. + +
    7. +I was told it is wrong to have the redisplay forced in the main loop. Is that right?
    8. + +

  • 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

    2. + +
+ +Back to the main page + +
+