FMudanyali/FreeGLUT-Vita
Archived
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Changes to TODO, Windows files - from John Fay

Browse Source 
git-svn-id: https://svn.code.sf.net/p/freeglut/code/trunk@130 7f0cb862-5218-0410-a997-914c9d46530a
This commit is contained in:
puggles 2003-07-10 11:51:09 +00:00
parent dbbe8e5b60
commit 4ab7ad7266
3 changed files with 86 additions and 59 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

132
freeglut/freeglut/TODO
View File

@ -4,89 +4,115 @@
Issues in Freeglut (so we don't forget): Issues in Freeglut (so we don't forget):
(3) In the Atlantis demo, if you stop the animation and move the mouse around with a menu open, the whales jiggle but don't circulate. My guess is that you need a way to redisplay the menu without forcing a redisplay from the application. Issues to Settle in 2.0.0:
(4) In the Atlantis demo, if you bring up the menu in GLUT the animation stops; in freeglut the animation continues. This may be another manifestation of (3). (A) We need a "configure" script.
(5) In the Atlantis demo modified to draw a solid torus instead of a mother whale, the torus is not shaded according to the lighting. This is true with both GLUT and freeglut. With freeglut, when you bring up a menu the shading turns on; with GLUT it does not. (B) We need to settle on MSVC workspace and project names for the static and dynamic "freeglut" libraries.
(6) There are several thousand compiler warnings. (C) We need a "configure" script.
(8) With the "bluepony" demo, if you reshape the window using the mouse, the scene does not redraw until you move it with a keypress (arrow key or space bar to start the animation). Check out the "CS_VREDRAW or CS_HREDRAW" sections in MSVC help for a pointer about this. (D) I'd like to change the names of the Windows target directories from names like "Debug__Win32_freeglut_static" (or something like that) to names like "DebugStatic".
(13) If you compare the "bounce" demo with freeglut and GLUT, you see that the slider widths are still slightly off. (E) We seem to have a problem with binary font compatibility.
(19) The "skyfly" demo resized my video and set it to 256 colors but didn't set it back when it was done. This is a problem with "skyfly" and not freeglut.
(22) We seem to have troubles with programs that use display lists. Check out the "walker" demo and load a new curve set. If you have the debugger going while it is loading, you get the new curves; otherwise you don't. This has to do with the debugger hiding the freeglut window while the display list is being changed.
(24) The "fgCleanUpGlutsMess" function seems to duplicate the "fgDestroyStructure" or "fgDeinitialize" function and should probably be removed.
(26) The "G_LOG_DOMAIN" defined constants are never used. Should we start using them in warning and error messages or should we delete them?
(27) The "freeglut_internal.h" file on lines 45ff defines or undefines "G_DISABLE_ASSERT" and "G_DISABLE_CHECKS" but these are never used. Shall we start using them or should we delete them?
(28) P-GUIDE apparently calls the get and set window size functions repeatedly. Each time it does, the window shrinks by 2 pixels in each direction.
(29) (for Don Heyse) We need to implement the "glutLayerGet ( GLUT_NORMAL_DAMAGED )" call.
These are all for the Windows version. Somebody needs to check the Unix version to see if the same issues exist there. Issues that can Wait until 2.2.0:
(1) In the Atlantis demo, under windows and with the task bar to the left of the screen, the GLUT window comes up in a position relative to the corner of the screen while the "freeglut" window comes up down and to the right of where it was the last time it was opened.
(2) In the Atlantis demo, if you stop the animation and move the mouse around with a menu open, the whales jiggle but don't circulate. My guess is that you need a way to redisplay the menu without forcing a redisplay from the application.
(3) In the Atlantis demo, if you bring up the menu in GLUT the animation stops; in freeglut the fish and whales wiggle without advancing. This may be another manifestation of (2).
(4) In the Atlantis demo modified to draw a solid torus instead of a mother whale, the torus is not shaded according to the lighting. This is true with both GLUT and freeglut. With freeglut, when you bring up a menu the shading used to turn on but doesn't any longer; with GLUT it never did and still does not. Interestingly, if you change to a teapot it is shaded, but other geometric shapes are not shaded.
(5) The "freeglut" wire cone does not look like the GLUT wire cone. There are several differences, one of which is that the "freeglut" cone draws the base.
(6) With the "bluepony" demo under Windows, if you reshape the window using the mouse, the scene does not redraw until you move it with a keypress (arrow key or space bar to start the animation). Check out the "CS_VREDRAW or CS_HREDRAW" sections in MSVC help for a pointer about this.
(7) If you compare the "bounce" demo with freeglut and GLUT, you see that the "freeglut" lights are larger and dimmer (and don't shine on the walls) than the GLUT lights.
(8) Large submenus in "freeglut" tend to cover their parent menus, making it difficult to get past them. This is visible in the "geoface" demo. In GLUT the menus can extend outside the window; "freeglut" should do the same thing.
(9) In the "gliq" demo, the cones forming the ends of the arrows in the "select board" are lighted differently in "freeglut" than they are in GLUT.
*fixed*(10) The "skyfly" demo resized my video and set it to 256 colors but didn't set it back when it was done. This is a problem with "skyfly" and not freeglut. <This seems to have fixed itself.>
<June 20, 2003> *fixed*(11) We seem to have troubles with programs that use display lists. Check out the "walker" demo and load a new curve set. If you have the debugger going while it is loading, you get the new curves; otherwise you don't. This has to do with the debugger hiding the freeglut window while the display list is being changed. <This seems to have fixed itself.>
A call for issues brought in the following:
*Fixed*(30) From Aleksandar Donev: Just a reminder to make sure an autogen.sh script or something alike is there to make the makefiles for the ignorant like me. From an earlier post of Bernd: I propose to create a script called autogen.sh in the CVS and make it hold these lines: (12) The "fgCleanUpGlutsMess" function seems to duplicate the "fgDestroyStructure" or "fgDeinitialize" function and should probably be removed.
set -x (13) The "G_LOG_DOMAIN" defined constants are never used. Should we start using them in warning and error messages or should we delete them?
autoheader
aclocal
libtoolize --copy --force
automake --add-missing
autoconf
(31) Also from Aleksandar Donev: can some add support for building a debbing version of freeglut to the makefiles? I have no clue how to use automake... (14) The "freeglut_internal.h" file on lines 45ff defines or undefines "G_DISABLE_ASSERT" and "G_DISABLE_CHECKS" but these are never used. Shall we start using them or should we delete them?
*Fixed*(32) From Eero Pajarre: A patch to make "freeglut" use the refresh rate in the gamemode string under Windows. (15) P-GUIDE apparently calls the get and set window size functions repeatedly. Each time it does, the window shrinks by 2 pixels in each direction.
*Fixed*(33) Also from Eero Pajarre: A patch to prevent "freeglut" from adjusting for the window border thickness in game mode. (16) (for Don Heyse) We need to implement the "glutLayerGet ( GLUT_NORMAL_DAMAGED )" call.
*Fixed*(34) Change the name of the source directory from "freeglut-1.3" to "src".
<From the Web Page, dated January 16, 2000; I don't know how many of these have (17) Also from Aleksandar Donev: can some add support for building a debugging version of freeglut to the makefiles? I have no clue how to use automake...
already been fixed.>
(35) 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. (18) 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.
(36) None of the bizarre input devices found in GLUT API is supported (and probably won't). (19) None of the bizarre input devices found in GLUT API is supported (and probably won't).
(37) The joystick code should work fine 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. (20) The joystick code should work fine 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.
(38) 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. (Several of the GLUT demos use the menu system. John Fay has checked it out pretty well.) (21) 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. (Several of the GLUT demos use the menu system. John Fay has checked it out pretty well.)
*Fixed*(39) 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. (22) 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.
(40) 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. (23) Indexed color mode 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?)
(41) Indexed color mode 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?) (24) 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.
(42) 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. (25) Layers would be good for drawing the menus and mouse cursor, as they wouldn't force the application redraw to update their state.
(43) Layers would be good for drawing the menus and mouse cursor, as they wouldn't force the application redraw to update their state. (26) Does the init display string work?
(44) Does the init display string work? (27) Is the game mode string parsed correctly?
(45) Is the game mode string parsed correctly? (28) Does the geometry need normal vectors?
(46) Does the geometry need normal vectors? (29) 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.
(47) 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. (30) GLX 1.3 spec states that glXChooseVisual() et consortes are deprecated. Should move to glXFBConfig.
(48) GLX 1.3 spec states that glXChooseVisual() et consortes are deprecated. Should move to glXFBConfig. (31) 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...
(49) 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... (32) I was told it is wrong to have the redisplay forced in the main loop. Is that right?
(33) 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
(34) We should really implement overlays, if only for the sake of completeness.
(35) Menus do not display in single-buffered windows, although they are active and the user can pick from them if he knows how to move the mouse exactly right.
(36) In the "boundary.c" demo in the "advanced" directory, if the outline rendering is turned on the menu background turns black.
(37) In the "comp.c" demo in the "advanced" directory, we find that we need a window to be defined before "glutGet ( GLUT_DISPLAY_MODE_POSSIBLE )" can be called. GLUT does not have this restriction. In "freeglut" there is a check at the beginning of the "fgSetupPixelFormat" call and a few references to "window->" later in the function.
(38) When you get around the requirement for an existing window in "comp.c", you find that "freeglut" renders the window differently from GLUT. For starters, "freeglut" looks like it is double-buffering while GLUT looks like it is single-buffering. In 'freeglut" the background is all black while in GLUT it starts black and turns white before your eyes.
(39) Running the "convolve" GLUT demo in the "advanced" directory (after fixing it so it doesn't terminate on error), I find that the "freeglut" version runs much more slowly than the GLUT version. I think this has to do with forcing redraws when the menu comes up.
(40) The "genmipmap" demo runs much more slowly in "freeglut" than in GLUT (try moving a window!) and flashes the texture over the whole window instead of just the part of the window where it finally settles down.
(41) We need to keep the "freeglut" structure current (including the GLUT action on window closure) after the last window closes. (Aleksandar Donev e-mail, 7/4/03, 5:00 PM).
(42) Menus need to display in their own subwindow with a special menu OpenGL rendering context. This will fix a wide range of menu-related bugs.
(43) We need to keep the "freeglut" structure current (including the GLUT action on window closure) after the last window closes.
(44) The "freeglut" wire cone differs from the GLUT wire cone. As a minimum, it draws the base where GLUT does not. I would check the solid cone as well.
(45) The different mouse pointers (crosshair, double pointer, etc.) do not get shown.
(46) The visibility callback is not invoked when minimizing a window. It should be.
(47) We should add a "glutExit" call to the interface. Also a "glutGet" to tell whether it has been initialized properly. And have "freeglut" call "glutExit" before it calls "exit ()".
(50) I was told it is wrong to have the redisplay forced in the main loop. Is that right?
(51) 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

1
freeglut/freeglut/freeglut.dsp
View File

@ -65,6 +65,7 @@ LINK32=link.exe
# PROP Use_Debug_Libraries 1 # PROP Use_Debug_Libraries 1
# PROP Output_Dir "Debug" # PROP Output_Dir "Debug"
# PROP Intermediate_Dir "Debug" # PROP Intermediate_Dir "Debug"
# PROP Ignore_Export_Lib 0
# PROP Target_Dir "" # PROP Target_Dir ""
# ADD BASE CPP /nologo /MTd /W3 /Gm /GX /ZI /Od /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /D "FREEGLUT_EXPORTS" /YX /FD /GZ /c # ADD BASE CPP /nologo /MTd /W3 /Gm /GX /ZI /Od /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /D "FREEGLUT_EXPORTS" /YX /FD /GZ /c
# ADD CPP /nologo /MTd /W3 /Gm /GX /ZI /Od /D "_DEBUG" /D "WIN32" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /D "FREEGLUT_EXPORTS" /FR /YX /FD /GZ /c # ADD CPP /nologo /MTd /W3 /Gm /GX /ZI /Od /D "_DEBUG" /D "WIN32" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /D "FREEGLUT_EXPORTS" /FR /YX /FD /GZ /c

12
freeglut/freeglut/freeglut_static.dsp
View File

@ -37,8 +37,8 @@ RSC=rc.exe
# PROP BASE Target_Dir "" # PROP BASE Target_Dir ""
# PROP Use_MFC 0 # PROP Use_MFC 0
# PROP Use_Debug_Libraries 0 # PROP Use_Debug_Libraries 0
# PROP Output_Dir "freeglut_static___Win32_Release" # PROP Output_Dir "ReleaseStatic"
# PROP Intermediate_Dir "freeglut_static___Win32_Release" # PROP Intermediate_Dir "ReleaseStatic"
# PROP Target_Dir "" # PROP Target_Dir ""
# ADD BASE CPP /nologo /W3 /GX /O2 /D "WIN32" /D "NDEBUG" /D "_MBCS" /D "_LIB" /YX /FD /c # ADD BASE CPP /nologo /W3 /GX /O2 /D "WIN32" /D "NDEBUG" /D "_MBCS" /D "_LIB" /YX /FD /c
# ADD CPP /nologo /W3 /GX /O2 /D "NDEBUG" /D "FREEGLUT_STATIC" /D "WIN32" /D "_MBCS" /D "_LIB" /YX /FD /c # ADD CPP /nologo /W3 /GX /O2 /D "NDEBUG" /D "FREEGLUT_STATIC" /D "WIN32" /D "_MBCS" /D "_LIB" /YX /FD /c
@ -60,11 +60,11 @@ LIB32=link.exe -lib
# PROP BASE Target_Dir "" # PROP BASE Target_Dir ""
# PROP Use_MFC 0 # PROP Use_MFC 0
# PROP Use_Debug_Libraries 1 # PROP Use_Debug_Libraries 1
# PROP Output_Dir "freeglut_static___Win32_Debug" # PROP Output_Dir "DebugStatic"
# PROP Intermediate_Dir "freeglut_static___Win32_Debug" # PROP Intermediate_Dir "DebugStatic"
# PROP Target_Dir "" # PROP Target_Dir ""
# ADD BASE CPP /nologo /W3 /Gm /GX /ZI /Od /D "WIN32" /D "_DEBUG" /D "_MBCS" /D "_LIB" /YX /FD /GZ /c # ADD BASE CPP /nologo /W3 /Gm /GX /ZI /Od /D "WIN32" /D "_DEBUG" /D "_MBCS" /D "_LIB" /YX /FD /GZ /c
# ADD CPP /nologo /W3 /Gm /GX /ZI /Od /D "_DEBUG" /D "FREEGLUT_STATIC" /D "WIN32" /D "_MBCS" /D "_LIB" /FR /YX /FD /GZ /c # ADD CPP /nologo /W3 /Gm /GX /ZI /Od /D "_DEBUG" /D "FREEGLUT_STATIC" /D "WIN32" /D "_MBCS" /D "_LIB" /FR /YX /FD /GZ /c
# ADD BASE RSC /l 0x409 /d "_DEBUG" # ADD BASE RSC /l 0x409 /d "_DEBUG"
# ADD RSC /l 0x409 /d "_DEBUG" # ADD RSC /l 0x409 /d "_DEBUG"
BSC32=bscmake.exe BSC32=bscmake.exe