COM & Lost
Author
Two Q's:
1- Can I apply the C++ polymorphysm rules on DirectX COM: i.e to make a pointer of type IUnknown * and assign different kinds of D3D resources (textures, surfaces, VB's, ...) and then call Release() on the pointer succefully?
2- Why when the device is lost it cannot be restored? The program stucks there, lost device state.
Thanks.
Quote:Original post by quaker
1- Can I apply the C++ polymorphysm rules on DirectX COM: i.e to make a pointer of type IUnknown * and assign different kinds of D3D resources (textures, surfaces, VB's, ...) and then call Release() on the pointer succefully?
Yes.
Quote:2- Why when the device is lost it cannot be restored? The program stucks there, lost device state.
Device loss means that the OS doesn't allow your application to render for some reason specific to it (the OS) and its architecture. For example, the OS can't give 2 applications exclusive access to the card. In such a case, the device becomes lost until the OS decides it can be restored.
Author
Thanks. I don't think so, because the OS grants access to other games when they are iconized then restored. But it seesm there's something wrong in my program how to re-gain the lost device, using TestCooperativeLeve.
All what it does, in the message loop, before any rendering action takes places:
it checks the TestCooperativeLevel result, if it's lostdevice then it sleep for about 50 milisecs then continues for the next iteration (frame), then checks again if it's not lost (notreset) then it attepts to reset the device, otherwise it continues.
All what it does, in the message loop, before any rendering action takes places:
it checks the TestCooperativeLevel result, if it's lostdevice then it sleep for about 50 milisecs then continues for the next iteration (frame), then checks again if it's not lost (notreset) then it attepts to reset the device, otherwise it continues.
Author
Mmmmmmm the device cannot be resotred, why? I ttried other sampl tutorials and the result is not better than mine. I think those closed source games handle it by destroying and re-constructing the device with all the resources. Hidden trick.
There is a BIG BUG in Direct3D.
There is a BIG BUG in Direct3D.
It looks like I misunderstood your question. I took it to be a question on why devices get lost in general. Now, what you're saying is that when your device is lost it can never be restored. If that's so, it's definitely a bug with your code. This is definitely not a d3d bug - this is a very well tested use case of the API, and everyone uses IDirect3DDevice9::Reset happily.
Do the SDK samples exhibit the same behavior? Launch an SDK sample, go fullscreen, ALT-Tab, and re-activate the sample. If it works, you have an application bug. If it doesn't, your driver's buggy.
Do the SDK samples exhibit the same behavior? Launch an SDK sample, go fullscreen, ALT-Tab, and re-activate the sample. If it works, you have an application bug. If it doesn't, your driver's buggy.
Author
Nop. After playing with some samples including the SDK ones, it's not a bug in my code. The SDK says it clearly TestCooperativeLevel and then sleep for ...mili secs and then continue till it restores. Not the case, I need to Recreate the device again, and that's what the demos do in fullscreen mode.
You could also check your windows messages - I've managed to confuse my app/D3D by accidentally missing messages or dropping into a tight loop during lost-device states.
Another trick is to get a simple DXUT sample, put a D3DPERF_BeginEvent() in OnLostDevice() and a D3DPERF_EndEvent() in OnResetDevice() and run a PIX full call-stream capture. You'll then get a nice report of exactly what API calls were made by DXUT (which does handle lost devices correctly) in this particular instance. Compare with what your application does and see if there is anything missing or in the wrong order [smile]
hth
Jack
Another trick is to get a simple DXUT sample, put a D3DPERF_BeginEvent() in OnLostDevice() and a D3DPERF_EndEvent() in OnResetDevice() and run a PIX full call-stream capture. You'll then get a nice report of exactly what API calls were made by DXUT (which does handle lost devices correctly) in this particular instance. Compare with what your application does and see if there is anything missing or in the wrong order [smile]
hth
Jack
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement