i’m in the midst of porting some graphics application code forward from windows xp to windows 7. in so doing, i’ve run into some blank-screen problems. the situation is sort of complicated, and i’ll explain everything at a high level, but i think i’ve isolated the problem. correct me if i’m wrong, of course. if you need more details, just ask.
the platform i have created supports simultaneous rendering of games created using both opengl and directx9. a top-level shell, which is a directx app renders a menu when no games are running and shares a rendering context with the directx games. opengl applications are relegated to their own window, which is shown when an opengl game is running and hidden otherwise. the directx window is never hidden – the gl window is shown on top of it.
the trouble is that opengl rendering is clobbering the direct3d device because of (my current theory: changing video modes). (slightly off topic: the typical way to resolve this is to wait for the device to enter the D3DERR_DEVICENOTRESET state then reset the d3d device. but that state is never reached. so the game runs, but nothing’s rendered). i’m trying to avoid this issue by not having opengl change the video mode.
first, the things that do work: if the system is run in ‘windowed’ mode, with 800x600 (smaller than screen res) windows, everything works just fine. if running in ‘full screen’ mode, with WS_POPUP|WS_CLIPSIBLINGS|WS_CLIPCHILDREN windows and the opengl window offset (say, to 400,400) everything runs fine, technically, but not all of the opengl window can be seen, because of the offset.
what doesn’t work is if the window has its origin at (0,0), so it paints every pixel of the screen. at this point, leaving an opengl game causes the screen to blank and d3d to be hosed. apps are still running, they’re just not painting. in fact, it’s worse than that. windows stops rendering everything. alt-tab doesn’t bring up the familiar dialog box, changing to another application (visual studio, for instance) does not cause that apps window to be brought forward/rendered. again, i have not had any luck waiting around for d3d to sort itself out, so i’m trying to figure out how to avoid the situation. everything goes back to normal, though, if i quit the application and the gl window is destroyed.
originally, the code detected the fullscreen mode and the opengl window that was created also called ChangeDisplaySettings(&d, CDS_FULLSCREEN). i figured an easy way to get around this problem was to stop changing the display settings and just create a window that was the size of the screen, rather than explicitly entering fullscreen mode. but this hasn’t worked. i’m fairly sure that the display settings are changing, because there’s considerable flickering that goes on when the opengl game starts and the lcd that i’m using for display shows a ‘searching’ icon for a moment.
is there something sneaky going on where windows or the opengl state machine notice that the window occupies exactly all of the screen and changes the display settings behind its back? how can this be avoided? what is the difference between a fullscreen window and a window that covers the entire screen? what tools should i use to track down these changes (i’ll try to run programs, but it will be unlikely that i can see anything in realtime because of this rendering problem. )
system spec is:
windows 7 rc build 7100
pentium 4 3Ghz
nvidia geforce 7800 gt
forceware 191.07 (latest as of posting)
ps - i know that there’s more going on here than opengl and windows, but currently i think this is windows’s/opengl’s fault. if, however, you think there’s a better forum to ask this question, please let me know.