You lose a device when:

You're fullscreen and another application (including Windows [message boxes]) takes the focus

You're in windowed mode and the screen bit depth changes (It's useful to do this to test your resetting code in windowed mode, since debugging is so much easier)

When you lose a device, all resources stored in D3DPOOL_DEFAULT are trashed, and the device is set back to the same state as when you created it (All render states are reset, all lights, materials, transform matrices are reset, etc).
Most games will use D3DPOOL_MANAGED for most resources, and the D3D runtime takes care of restoring those resources for you (They keep a copy of the data in system memory). Pre-DX8 applications will need to do that themselfs, and store their own copy of the data in system memory (Managed pools didn't exist pre-DX8).

The reason some games take a long time to reset after you alt+tab, is that they probably use the default pool, and have to read all the resources from disk. Even if they use the managed pool, they still need to recreate all dynamic resources (Dynamic resources can't be managed), and reset all render states, lights, etc etc.

If you use a scene graph (Or even just a light wrapper around your D3D device), then you can respond nicely to a reset device, since you'll have a cached copy of all states, lights, materials, etc. Plus, you can create a pure device without any drawbacks, which can give you slightly better performance, and you can avoid redundant SetRenderState()s, etc.

HTH,
Steve

Others might say make things managed pool because it will handle the reloading of resources, but I will say that you should create everything with the default pool and handle the reloading yourself.

Managed pool has limitations*, so if you want to use the feature you have to make the pool default anyways and handle reloading for that one object, so you're gonna need the code anyways. Might as well do it all.

(*its been a few years but I believe the limitations were dynamic vertex buffers, where the contents of the vertex buffers change every frame, you could not use the managed pool when creating a dynamic vertex buffer.)

Quote:Original post by JoeyBlow2
Others might say make things managed pool because it will handle the reloading of resources, but I will say that you should create everything with the default pool and handle the reloading yourself.

Managed pool has limitations*, so if you want to use the feature you have to make the pool default anyways and handle reloading for that one object, so you're gonna need the code anyways. Might as well do it all.

(*its been a few years but I believe the limitations were dynamic vertex buffers, where the contents of the vertex buffers change every frame, you could not use the managed pool when creating a dynamic vertex buffer.)

The managed pool does more than just handle restoring lost resources. It also manages swapping resources in and out of video memory. If you use the drfault pool for everything, you have to watch for D3DERR_OUTOFVIDEOMEMORY errors when you create resources, and release some resources to make room, then try to recreate the resource.

Yes, you can't create dynamic resources in the managed pool, but why would you want to? Dynamic resources are almost always in AGP memory, so both the CPU and GPU can access them, and the data in them isn't persistant, so there's nothing to load into them after you recreate them.