In the past, I've read about driver bugs when resetting a device. Is this still an issue? Before too long we will need to implement lost device recovery for our application. In the past, I recreated the device from scratch when it was lost. This will be the first time using the Reset method for the device. Is there anything I should be aware of before getting started? Thanks for any help.

1. D3DERR_DRIVERINTERNALERROR are rare, very rare, but still possible (I think I've seen a genuine case once since D3D8.0 - and I've had a few PC products go through extensive compat. testing at various publishers).

If getting back to where you were after tearing down and recreating the device is going to be difficult, IMO this is one of those places where it's acceptable to shut the app down and display a "sorry, the driver for your display adapter just did something really weird and I can't continue" message. Preferably save the game state to get back to at least a place near where they were and offer to re-launch the app.


2. Something to watch out for is lost device situations that occur after TestCooperativeLevel() said it was ok to restore. i.e. check the return code from Reset() and any Create*() calls you're using to restore the app - if any return D3DERR_DEVICELOST start the whole thing again. It's difficult to re-produce this one, but quick fingered testers (and so end users) can get it to happen on some machines.


3. My tip for testing the robustness of your lost device handling is to stick a GetAsyncKeyState() check in just before your Present() which calls IDirect3DDevice9::Reset() when some key is pressed. The Reset() puts the device in a very similar state to a true lost device and all the same errors get returned from functions like TCL(). This is of course in addition to traditional methods.


4. Tip for testing lost device handling in windowed mode applications: change the resolution and bitdepth of the desktop (often trips up a few apps that thought lost device handling was only necessary in fullscreen exclusive mode...). This can also be handy for testing in fullscreen mode too if you're finding that a simple Alt-Tab isn't getting you a lost device.

Quote:Original post by Evil Steve
You should really be handling lost devices from early on, so you can stucture your code around it properly.

The engine is designed properly for lost devices, we just aren't handling them.

S1CA: I've seen a D3DERR_DRIVERINTERNALERROR on a friends build, on his laptop. I've never seen them on one of my projects or computers, but they are definetly still around.

Vista is good for testing lost devices also. Ctrl-alt-delete steals the device from all running programs.

Quote:Original post by blaze02
Vista is good for testing lost devices also. Ctrl-alt-delete steals the device from all running programs.

This trick works on XP too if you lock the machine, or have your screensaver kick in with the 'show welcome screen' option checked.

I ran into the type of issue I was worried about. It wasn't a big deal, but I was a bit confused at the first.

On older DirectX SDK's (specifically Dec. 2004), the debug DirectX DLL will fail without reason. If the program creates queries, the Reset call will fail and the output window will claim the queries are not being released.

This guy gets the same problem on Oct. 2004 SDK.
http://www.gamedev.net/community/forums/topic.asp?topic_id=428860&whichpage=1&#2852284

1. you are releasing any queries you created before you call Reset() aren't you? (an IDirect3DQuery9 is a COM object and so has a Release() method...)

2. have you called Issue() on the same query object multiple times without waiting for a previous issue on the same query object to return data? I suspect this could give you problems.

S1CA, I think you misunderstood me. The code is fine, but the older DirectX SDK reports errors. Newer SDK's do not see a problem.