Now this is bawled up!

Alright, guys, here’s what’s going on.

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)

any ideas?


thanks in advanced

Sounds like your previous RCs were not previously destroyed: your graphics card runs out of memory and your rendering falls back to software mode…

Could it make sense ?



part of my KillWindow() routine deletes the hGLRC… even checks to make sure it was deleted:

wglMakeCurrent( 0,0 );

if( mhGLRC != 0 )
if( !wglDeleteContext( mhGLRC ) )
return DisplayFatalError( “Unable to release hGLRC.” );

    mhGLRC = 0;


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?


thx again, for the reply, and in advance for others

[This message has been edited by Succinct (edited 11-10-2000).]

Hmmm, I do things in the order listed below, which seems to be a bit different than what you do. Perhaps try something like this??

wglMakeCurrent( NULL, NULL );

ReleaseDC( win.appWnd, win.appDC );
wglDeleteContext( win.appRC );
DestroyWindow( win.appWnd );

[This message has been edited by El Jefe (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:

wglMakeCurrent(NULL, NULL);
ReleaseDC(hDC, hWnd);


[This message has been edited by El Jefe (edited 11-10-2000).]

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;

SetWindowLong(hWnd, GWL_STYLE, uiFullScreenStyles);

// Change windows styles

// Change window size and show window

This works fine but problems start when I try to change the display mode. When I do that, the program crashes.

It seems like whenever the display resolution is changed, the rendering context has to be deleted and recreated. Is there a way around ?

The big problem is that windows will only let you set the pixel format for a window once. only once…

sucks, but it’s the rules.

you can check it out in the documentation for SetPixelFormat(),ChoosePixelFormat(),etc.

that means that when you ChangeDisplaySettings(), you’re also changing the pixelformat, i believe…

that would really piss off a window

at least that’s the first thing that comes to mind.

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…


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)

oh well, the quest continues…

This is my entire video driver from old OpenGL program. It seem to work perfectly. Though it uses a lot of my external stuff it should be pretty straightforward.

[This message has been edited by onyXMaster (edited 11-15-2000).]

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 .

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 ?

Thanks to all

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.

Thanks for the feedback !