Friday, December 19, 2008

The Alt-Tab Problem

Here we hit another classic example of things that probably bedevil everybody starting out with Direct3D. I'll quote from MSDN:

"By design, the full set of scenarios that can cause a device to become lost is not specified. Some typical examples include loss of focus, such as when the user presses ALT+TAB or when a system dialog is initialized."
However, while they certainly do provide a comprehensive enough set of warnings that you must recover from a lost device, nowhere can I see any simple step-by-step instructions for doing so. Instead you're largely left to jump around the documentation frantically searching for the correct methods to use.

So far as I can determine, the correct procedure seems to be:
  • Keep all of your resources in managed memory; this gives you more memory overhead but it saves a lot of pain later on.
  • Check for a D3DERR_DEVICELOST return from Present ().
  • Suspend all rendering for the remainder of the operation.
  • Go into an infinite loop and test Device->TestCooperativeLevel () until you get either D3DERR_DEVICENOTRESET (you're good to go again) or D3DERR_DRIVERINTERNALERROR (time to die). It might be an idea to Sleep (10) after each test so that you don't tie up the CPU.
  • Reset the device using Device->Reset (). You'll need to specify new D3DPRESENT_PARAMETERS to do this.
  • Go into another infinite loop and test Device->TestCooperativeLevel () until you get either D3D_OK (you're good to go again) or D3DERR_DRIVERINTERNALERROR (time to die). It might be an idea to Sleep (10) after each test so that you don't tie up the CPU.
  • Recreate any resources that were not originally created in managed memory.
That seems like a mightily ugly way of going about something that the API should be able to handle automatically!

0 comments: