From: Eero P. <epa...@ko...> - 2004-01-11 21:02:16
|
Does anybody remember breaking gamemode on Windows during fall/winter? ;-) In my development side I run my program in a window, and I have been slow at updating freeglut for my "production side", so I unfortunately cannot really say what has happened and when, but now I am having problems with gamemode. My code does something like: glutInitWindowPosition(0,0); glutInitWindowSize(SCREEN_WIDTH(),SCREEN_HEIGHT()); glutInitDisplayString("double rgb depth>=24"); if (!in_window){ glutGameModeString(screen_mode); if(0 == (win=glutEnterGameMode())) { So it might be that my InitWindowSize call etc are part of the problem, but I suspect that. (glutInitWindowSize gives my preferred window size, the screen size in glutGameMode is something quite different, and I think there anyways is a default window size which is NOT the 2048x768 size I want...) This is my current analysis of the problem: When I call glutEnterGameMode it ends up calling the (Win32) CreateWindow with correct size, but that activates fgWindowProc with the WM_CREATE message. In fgWindowProc there is code: (about line 1208) window->State.NeedToResize = GL_TRUE; window->State.Width = fgState.Size.X; window->State.Height = fgState.Size.Y; This stuffs my gamemode window with an the size specified in glutInitWindowSize, and sets it up for resize. On the next window redraw the the window gets sour. I assume I will hack my self around this, but unless there is something wrong with my setup, a proper fix is needed. Eero |
From: Richard R. <sf...@ol...> - 2004-01-12 07:51:59
|
On Sun, Jan 11, 2004 at 11:03:06PM +0200, Eero Pajarre wrote: > Does anybody remember breaking gamemode on Windows during > fall/winter? ;-) I remember it being broke, and someone fixing it. I don't use gamemode, though, so I can't tell you much. I do know that it crashed for me in the "One" demo; it appears to have munged the pointer for a menu construct. -- "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
From: Eero P. <epa...@ko...> - 2004-01-20 08:15:06
|
Eero Pajarre wrote: > Does anybody remember breaking gamemode on Windows during > fall/winter? ;-) > .... > > In fgWindowProc there is code: (about line 1208) > > window->State.NeedToResize = GL_TRUE; > window->State.Width = fgState.Size.X; > window->State.Height = fgState.Size.Y; > > This stuffs my gamemode window with an the size specified > in glutInitWindowSize, and sets it up for resize. > As the SourceForge Anon-CVS actually happened to work for a while, I checked when the lines mentioned above were added. The Width and Height setting lines are from 1.63 version for freeglut_main.c, and the relevant comment is: (b) Changes to postpone the handling of window resizes. For gamemode the above change breaks because it overwrites the correct size in window->state with non current data from fgState. Im also a little suspicious what would happen if the user would quickly create several windows and set the initial window size between calls to create window. My first attempt to fix this by checking if this is a gamemode window failed because the code above is run for the first time before the fgStructure.Gamemode is set, and thus finding out if we are in gamemode failed. At the moment I am running freeglut with the above lines commented out, but I am not sure if this breaks something else. (Not sure though) Eero |
From: Richard R. <sf...@ol...> - 2004-01-21 02:12:43
|
On Tue, Jan 20, 2004 at 10:15:58AM +0200, Eero Pajarre wrote: > Eero Pajarre wrote: > > >Does anybody remember breaking gamemode on Windows during > >fall/winter? ;-) [...] > >In fgWindowProc there is code: (about line 1208) > > > > window->State.NeedToResize = GL_TRUE; > > window->State.Width = fgState.Size.X; > > window->State.Height = fgState.Size.Y; [...] > (b) Changes to postpone the handling of window resizes. > > For gamemode the above change breaks because it overwrites > the correct size in window->state with non current data from > fgState. Im also a little suspicious what would happen if the > user would quickly create several windows and set the initial window > size between calls to create window. I think that the idea of postponing the resize is sound, at least in general. GLUT promises that it will be so, and some programs may depend upon it. GLUT seems to fullfill this promise, I think, so it is consistant with whatever else GLUT does. I do not remember if this issue directly affected me, but there is some related order-of-events that does affect a GUI library I have. I've been meaning to fix that, but have been sidetracked. > My first attempt to fix this by checking if this is a gamemode > window failed because the code above is run for the first time > before the fgStructure.Gamemode is set, and thus finding out if > we are in gamemode failed. > > At the moment I am running freeglut with the above lines > commented out, but I am not sure if this breaks something > else. (Not sure though) I do not think that this feature should be backed out. Unfortunately, I'm at a disadvantage for editing, at the moment. I just updated to the latest NetBSD -current image on my main machine, and XFree86 4.3.0 has decided that it no longer likes my video card. (I get a fatal error during device probe.) (Actually, editing isn't *that* bad, but testing freeglut is rather hard without a graphic environment. (^&) -- "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
From: Eero P. <epa...@ko...> - 2004-01-21 07:16:47
|
Richard Rauch wrote: > I do not think that this feature should be backed out. > > Unfortunately, I'm at a disadvantage for editing, at the moment. > I just updated to the latest NetBSD -current image on my main > machine, and XFree86 4.3.0 has decided that it no longer likes > my video card. (I get a fatal error during device probe.) > I suspect that this problem only exists at (Microsoft) Windows version. fgState.Size is not used in similar style in the X11 codepaths. Eero |
From: Richard R. <sf...@ol...> - 2004-01-23 16:58:14
|
On Wed, Jan 21, 2004 at 09:17:36AM +0200, Eero Pajarre wrote: > Richard Rauch wrote: > > >I do not think that this feature should be backed out. > > > >Unfortunately, I'm at a disadvantage for editing, at the moment. > >I just updated to the latest NetBSD -current image on my main > >machine, and XFree86 4.3.0 has decided that it no longer likes > >my video card. (I get a fatal error during device probe.) > > > > > I suspect that this problem only exists at (Microsoft) Windows > version. fgState.Size is not used in similar style in the > X11 codepaths. ...which is the kind of thing that makes me wish to (re)unify some of the code paths. (^& The only OS-specific junk should be where you decide what OS function to call. However, in the case of window resizes, the semantics and whole chain of logic gets substantially rethreaded by choosing UNIX_X11 or WIN32, as I recall. That, IMHO, is wrong, if we can avoid it. -- "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |