8a844835ddfceadf3b462667dbde1354f1deabac
[freeglut] / progress.html
1 <!doctype html public "-//w3c//dtd html 4.0 transitional//en">
2 <html>
3 <head>
4    <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
5    <meta name="author" content="Pawel W. Olszta">
6    <meta name="copyright" content="Pawel W. Olszta">
7    <meta name="description" content="The freeglut development progress reports">
8    <meta name="keywords" content="freeglut glut OpenGL">
9    <meta name="GENERATOR" content="WebMaker">
10    <title>The freeglut project</title>
11 </head>
12 <body text="#000000" bgcolor="#FFFFFF" link="#0000EF" vlink="#51188E" alink="#FF0000">
13
14 <center><img SRC="freeglut_logo.png" ALT="The freeglut logo" height=106 width=314></center>
15 <center><dt><i><font face="Courier New,Courier"><font size=+1>
16 I love reports. They are so full of brightness and hope...
17 </font></font></i></dt></center>
18
19 <center><table WIDTH="620" ><tr><td><hr WIDTH="100%">
20
21 <p><i>January the 16th, 2000</i>
22
23 <p>It looks like both X11 and Win32 version have reached a comparable usability stage.
24 They are still missing many GLUT API 3 features, but the number is getting smaller and
25 smaller every day :)
26
27 <br><ul><li><b><font size=+2>input devices</font></b></li>
28
29 <p>Keyboard and mouse seems to work well. There is a big guess about the mouse buttons 
30 count under X11 (always 3) -- I must remember to correct the menu activation code if 
31 this shows to be invalid.
32
33 <p>None of the bizarre input devices found in GLUT API is supported (and probably won't). 
34
35 <p>Steve Baker contributed the joystick code. It should work fine, as it did in PLIB,
36 but I haven't tested it out yet. It might not compile under FreeBSD, as I had to 
37 convert it from C++ to C and had no possibility to compile it under FreeBSD (the Win32
38 version had some typos, but I've already fixed them).
39
40 <br><br><li><b><font size=+2>pull-down menus</font></b></li>
41
42 <p>Pull down menus seem to work. The menu is displayed using OpenGL, so it requires 
43 the window's contents to be refreshed at an interactive rate, which sometimes does not 
44 happen. That's why I'll consider adding optional window-system menu navigation later. 
45 For now -- extensive testing is what I believe should be done with the menu system.
46
47 <br><br><li><b><font size=+2>fonts</font></b></li>
48
49 <p>Bitmap fonts support is done. However it would be good to add two more API functions
50 -- glutBitmapString() and glutStrokeString(), which should limit the quantity of state
51 changes when drawing longer strings. 
52
53 <p>Good that somebody finally told me where to get the stroke fonts data from... XFree86
54 sources contain the ROMAN and MONO ROMAN stroke fonts data. For now stroke fonts are 
55 rendered using the bitmap font GLUT_BITMAP_8_BY_13.
56
57 <p>What has changed is the way the fonts are specified. I moved to the GLUT's strange
58 way of supplying (fake for freeglut) font data pointers instead of some nice enums.
59 Hope it helps in achieving the binary compatibility between freeglut and GLUT.
60
61 <p>Added two new API calls: glutBitmapHeight() and glutStrokeHeight(), that return
62 a font's height. Hope this doesn't break the GLUT compatibility a lot.
63
64 <br><br><li><b><font size=+2>mouse cursor</font></b></li>
65
66 <p>Need to have own cursor shapes, so that freeglut can pass them to the windowing
67 system, draw them using glBitmap() and/or texture mapping. The cursor shapes are very
68 probable to be found in XFree86 sources.
69
70 <br><br><li><b><font size=+2>indexed color mode</font></b></li>
71
72 <p>This might work, however I have not tested it yet. glutGetColor/glutSetColor is not 
73 implemented. Again, looks like a single Xlib call, but there might be some problems 
74 with the colormap access. Need to switch into indexed color mode some day and check it 
75 out (does Mesa 3.1 work with indexed color mode?)
76
77 <br><br><li><b><font size=+2>planes</font></b></li>
78
79 <p>Overlays are not supported, but one of the GLUT conformance tests fails due to 
80 glutLayerGet( GLUT_NORMAL_DAMAGED ) returning FALSE when the window has actually 
81 been damaged.
82
83 <p>Layers would be good for drawing the menus and mouse cursor, as they wouldn't force
84 the application redraw to update their state.
85
86 <br><br><li><b><font size=+2>init display string</font></b></li>
87
88 <p>I am in middle of the fight with the init display string. It's parsing OK, now it 
89 would be cool to make it impress some effects on the display... 
90
91 <br><br><li><b><font size=+2>game mode</font></b></li>
92
93 <p>Is the game mode string parsed correctly?
94
95 <br><br><li><b><font size=+2>geometry</font></b></li>
96
97 <p>Andreas Umbach has contributed the cube and sphere code. The teapot rendering is 
98 done using free SGI code. I have also added the cone rendering, however it is missing 
99 normal vectors (just as Andrea's wireframed cube does). All of the glut*hedron() 
100 functions await to be implemented.
101
102 <br><br><li><b><font size=+2>obvious bugs</font></b></li>
103
104 <br><br><ol>
105 <li>
106 the visibility/window status function is a conceptual mess. I had to peer into the GLUT
107 source code to see what actually happens inside. It helped me a bit, but still one of 
108 the visibility tests fails. This is probably the reason for which a window covered by 
109 enlightenment status bar is marked as hidden and does not get redrawn.</li>
110
111 <li>
112 GLX 1.3 spec states that glXChooseVisual() et consortes are deprecated. Should move to 
113 glXFBConfig.</li>
114
115 <li>
116 need to investigate what happens when initial window position is set to (-1,-1). GLUT 
117 specification says, that the window positioning should be left to the window system. 
118 And I do not know how to force it do so...</li>
119
120 <li>
121 I was told it is wrong to have the redisplay forced in the main loop. Is that right?</li>
122
123 </ol><br><li><b><font size=+2>not so obvious bugs</font></b></li>
124
125 <br><br><ol>
126 <li>some of the tests freeze because they do not generate the glutPostRedisplay() call 
127 every frame. Again, this is somehow handled by GLUT, but I can't see how. And why.
128
129 <p>Looks like I've fixed it (or rather hacked it?) by forcing a redisplay every
130 frame, but this is no good and kills interactiveness of my console :D</li>
131
132 </ol></ul>
133
134 <a href="index.html"><i>Back to the main page</i></a>
135
136 </table></center></body></html>
137