I’m working on my “easy to use” fullscreen toggle function using a win32 implementation(i.e. not glut).
call toggle
kill hGLRC
kill hDC
kill hWnd
call CDS
create new window
create hWnd
create hDC
set pixelformat
attach hGLRC
blah blah…
so far, it works fine, except for 2 things.
first is the annoying boxes occasionally left on the task bar, after the window closes
now, that i can kinda deal w/ and i can probably find more info through ms. it’s not a gl problem, so i’m not worried about it here.
the reason for my post is that after toggling,say, 5 or 6 times (i can’t recreate the exact circumstances), the fullscreen mode runs slow as molasses (drops from around 50 fps to 7fps)
it makes sense that it could be caused by that, but it doesn’t seem to be the case here because part of the toggle code calls my KillWindow() function, which has these lines of code in them… am i releaseing the RC correctly?
uggh.
thx again, for the reply, and in advance for others
[This message has been edited by Succinct (edited 11-10-2000).]
Now I’m a bit curious, I looked in our code base to see how Quake3 shuts down GL and it seems to do it in the order that you listed.
But then again, I found this other code which seems to come from the SGI OpenGL SDK and it shuts down GL in the order that I originally listed, that is:
That’s the order in which I create them, so i destroy them in reverse order, just incase, say, if you delete an hDC then you can’t delete the hRC, etc.
similar to deleteing a dynamic record w/ dynamic elements. if you delete the record, you’ll never be able to delete the elements, unless they’re deleted first.
i figure that if you need an hDC to make an hGLRC, delete the RC first…
dunno, just how it makes sense to me, too bad it’s WRONG!!! lol
[This message has been edited by Succinct (edited 11-10-2000).]
About the annoying boxes occasionally left on the task bar, try doing :
ShowWindow(hWnd, SW_HIDE);
before you destrow the window.
I was woundering if there was a way of changing the window styles of a window and the display mode without having to kill the window and create a new one.
I was able to change the window styles with :
unsigned int uiFullScreenStyles = WS_POPUP | WS_CLIPCHILDREN | WS_CLIPSIBLINGS;
Nope, for some reason, adding the ShowWindow( hWnd,SW_HIDE ) is causing my program to freeze after i toggle fullscreen.
even when i toggle it back to windowed mode, the window reappears, but there’s no gl action other than displaying the very first frame that would appear. Resizing causes it to behave as it would w/o having a WM_PAINT handler…
hrmmm.
besides, the box is still there.
i figure that it changed an internal flag registered to the hWnd, and later when i call SW_SHOWNORMAL, it doesn’t like it, and won’t create the correct contexts for me, but that can’t be, because i have error checking when i create my window (lol)
Succinct:
Yah, you’re right, as soon as you change the display mode and it has a different number of color bits then you have to destroy the window and create another one. All this, like you said, because you can only set the pixel format once!
About the ShowWindow( hWnd,SW_HIDE ), well that shouldn’t make your program crash. I do this in my program and onyXMaster does the same. You probably have a bug somewhere else .
onyXMaster:
Thanks for the code but I have a few questions if you don’t mind :
1- Why do you always check the dmFields field of the DEVMODE struct when you call EnumDisplaySettings() ? Occording to the help files, dmBitsPerPel, dmPelsWidth, dmPelsHeight always get filled. Doesn’t this mean the corresponding bits in dmFields get set ? In other words, you shouldn’t have to check them all the time.
2- Aren’t display modes returned by EnumDisplaySettings() always supported by our hardware. In other words, do we have to do a ChangeDisplaySettings(&Mode, CDS_TEST) for each of them to make sure they are supported ?
1 - I check dmFields, because, as you see I check everything which is not under my control. Call it paranoia - but it feels right to me and helped me a lot. I don’t trust plain assumptions.
2 - yes, they are. but it may be impossible to set this mode. trust me, this situation occurs, especially on not-so-new drivers for not-so-good hardware on not-so-fresh OS-es.
i.e. win95 cannot change color depth easily. So if you’re launching from 32-bit desktop, these checks will eliminate 16-bit modes from list. But when you run from 16-bit desktop, it will show 16-bit modes only. And if you run win98/me/2k - it will show all modes regardless of your desktop depth.
.