Im following some code from frank lunas book, in which he checks whether the device has been lost or not via Just a few questions 1. What causes the device to be lost? 2. How can I cause the device to be lost, to check if the code i have implemented for the case in which a device gets lost. 3. In a descent sized application, the code needed to be implemented for the case in which a device gets lost, is probably going to be huge, and there is a good chance you may miss an item that needs to call .onLostDevice and .onResetDevice, is it acceptable to just close the application when a problem occurs, rather than try to reset the device? surely resetting all your buffers and shaders etc is going to take some time. 4. How exactly do you know which devices need to be reset? atm im just looking to see if that device has the function or not. 5. My code has been written so that i have copies of the d3ddevice pointer in many classes, (terrain class, texture loader etc etc) when you reset the device, does it still point to the same location in memory? or do i have to update the device pointer in all my classes? 6. When you adjust the settings in the directx control panel, such as use debug runtimes and error message detail, does this affect games you have bought?

The best information you can get on lost devices is directly from the DirectX SDK documentation here.

As for item 5, the pointer to the device remains the same, so no worries there.

For item 6, when you switch to the debug runtimes via the control panel, you affect all DirectX applications. So you probably don't want to leave it that way when you aren't actively debugging.

Quote:Original post by maya18222
Im following some code from frank lunas book, in which he checks whether the device has been lost or not via

*** Source Snippet Removed ***

Just a few questions

1. What causes the device to be lost?
2. How can I cause the device to be lost, to check if the code i have implemented for the case in which a device gets lost.
3. In a descent sized application, the code needed to be implemented for the case in which a device gets lost, is probably going to be huge, and there is a good chance you may miss an item that needs to call .onLostDevice and .onResetDevice, is it acceptable to just close the application when a problem occurs, rather than try to reset the device? surely resetting all your buffers and shaders etc is going to take some time.
4. How exactly do you know which devices need to be reset? atm im just looking to see if that device has the function or not.
5. My code has been written so that i have copies of the d3ddevice pointer in many classes, (terrain class, texture loader etc etc) when you reset the device, does it still point to the same location in memory? or do i have to update the device pointer in all my classes?
6. When you adjust the settings in the directx control panel, such as use debug runtimes and error message detail, does this affect games you have bought?

1. Alt-tabbing away from your app in fullscreen mode, or logging off / changing desktop resolution in windowed mode.
2. Change the desktop resolution in windowed mode (Much easier to test this stuff in windowed mode)
3. You should always handle it - otherwise you're preventing people from alt+tabbing from your app in fullscreen mode, which is extremely annoying. Personally, I have each class that contains an interface that needs reset / released register itself with a manager class. When the device is lost or reset, I can then iterate through that list and call my OnLostDevice() / OnResetDevice() functions, then reset all render states I need.
4. I don't understand - all devices need reset. Before calling IDirect3DDevice9::Reset(), you need to Release() all resources in D3DPOOL_DEFAULT, and call OnLostDevice() for all D3DX interfaces that have such a method (Internally, the D3D object will Release() it's buffer when you call that function). Similarly, after Reset()ing, you need to re-create all D3DPOOL_DEFAULT resources and call OnResetDevice() for all D3DX objects that have such a function.
5. Yes, the pointer remains the same.
6. Yes, it affects all D3D applications. fun fact; turning on the debug runtimes for the original Unreal Tournament has some "interesting" effects because in some areas they don't clear the backbuffer by use D3DSWAPEFFECT_DISCARD, so you see areas flashing green / magenta. You can also download and run DebugView with the debug output level set up to maximum and then run a D3D game to see the D3D output (And possibly other output) from it.

1) The list of circumstances where a device can be lost is long, and therefore not even Microsoft gives you a full list. Things such as other apps going fullscreen on top of yours, ctrl-alt-del, a hardware failure will all lead to a lost device.
2) The most common cause of a lost device is a ctrl-alt-del to the task manager. Most of the time this will cause a lost device. I usually check my recovery procedures this way.
3)Usually, what you do, is you add some sort of "reset" or other routine to any classes that allocate resources that will need to be reset with a device. Then you have some sort of manager that tracks these resources and resets them all when necessary.
4) Anything that resides in video memory will need to be reset. This means POOL_DEFAULT definitely, and might be others. POOL_MANAGED will always have a backup copy in system memory and takes care of itself, and POOL_SYSTEM will be fine as well.
5) Your pointers should be fine as long as you are resetting a lost device and not reallocating a new device. However, you should not use these pointers when the device is in a lost state. This creates a debugging nightmare, so get in the habit of testing your pointers.
6) I am not sure, but I believe much of the debugging will not take place unless a certain #define is present, so it should not cause too many problems.