   multitasking with fullscreen D3D
  Here is hopefully a not too lengthy description of two possibly related problems I'm having with multitasking and D3D8.When I run my game in fullscreen mode and use alt+tab to switch to another app the game does not always behave properly. Sometimes everything is ok and the game minimizes as it should. But just as often it seems to be minimizing but the game "screen" remains. All I can see is the last frame from the game and the mouse cursor but it's not the game that is running. If know this because if I move the mouse around the cursor changes correctly for the underlying app.Now if I alt+tab back to the game, it resumes. I reset the D3D device if needed (which it always does) and almost everything is fine. I say almost because when I use the win32 function GetClientRect() it reports an incorrect size. It should give me the same result as GetWindowRect() which is also the size of the current resolution because it's running in fullscreen. GetWindowRect() reports the the correct size, that is, a window at the top left screen position with the size of the current fullscreen resolution.GetClientRect() gives me a result that is slightly smaller than GetWindowRect() which matches exactly what I should be getting if the window has a frame and caption bar. But it doesn't.My game can switch between fullscreen and window while running, without a problem. In windowed mode it has a frame and caption bar and when I switch to fullscreen D3D makes sure it is covering the whole screen, which GetClientRect() confirms. When I switch back to windowed, the frame and caption bar are restored, not by my code, by D3D. I don't touch the window style after creating the window during startup.Why doesn't it work when minimized/restored?   
  Because you're doing something wrong.Without more information, there's really no more I can tell you. What does the relevant code look like?   ;  I think the best you can do for problems of this kind is to make a stripped down test application which only, say, clears the screen to a different color each frame, and then see if the behaviour of that application differs from yours. Also, I'm not sure, but I don't think using GetClientRect() or GetWindowRect() is the right way to get the screen size... I think Direct3D doesn't resize the window when switching to fullscreen at all - it uses the window when presenting in windowed mode, but in fullscreen mode it ignores the window's size and position. Again, I'm not sure. Sorry.   ;  All the SDK samples handle this scenario properly, so compare what you are doing to what the samples are doing.  To make this comparison properly, you have to understand what the sample framework is doing in addition to the code in the specific sample.  Most of them just delegate handling of this scenario to the framework, so its the framework you want to examine closely.   ;  Thanks for the advice about the sdk framework, I looked at what they did and tried the same. It helped me fix the problem with GetClientRect() which now reports the correct size. Most of the other stuff was the same, the biggest difference was that they use WM_SIZE to determine if the app is losing/regaining focus, while I use WM_ACTIVATE. I tried their way but I wasn't satisfied by the behaviour. I switched back to using WM_ACTIVATE which I think seems to be the more appropriate way to do it. Does anyone else have an opinion about this?However, I wasn't able to solve the minimize problem with the use of the framework. But after a lot of trial and error I think I finally solved it. When I detect that I'm losing focus (with WM_ACTIVATE) I call d3ddevice->TestCooperativeLevel(), which of course returns D3DERR_DEVICELOST. Then I just let it be and the app minimizes properly. If I don't call TestCooperativeLevel() then the last frame of the game is stuck on the screen.Does anyone have an explanation to this behaviour?It seems like first after I call TestCooperativeLevel() D3D lets go of the screen.;  Interesting.  Can you reproduce the problem with the SDK samples?  If not, then the SDK samples are still doing something that you're not doing.Also, you might want to try it on REF, there's a possibility that there's some HAL wigginess in there.   ;  Using TestCooperativeLevel as I described earlier only helped but did not solve the problem entirely. Sometimes the screen still gets stuck. Meanwhile the SDK samples work perfectly everytime.I really can't see what they do different. When minimizing they really don't do anything so it must be something earlier, perhaps during initialization.I must also point out that on another computer that I have my game works perfectly every time. That machine is much newer and has an nVidia card. The problematic machine has an ATi card. I tried the latest drivers but same problem.Any ideas what to look for? Cause I've spent countless hours on this problem and I'm starting to give up.;Quote:Original post by Decept[...] Meanwhile the SDK samples work perfectly everytime.[...] Any ideas what to look for?Again, it comes back to what the samples are doing that you aren't doing or vice-versa.  Run a sample in the debugger, or step through it mentally or something, but you are obviously doing something different from the samples and that's why your code doesn't work and the samples work.That it "works" on the nvidia card isn't telling you anything useful; its just working by accident there (as opposed to working by design, like the samples).   