Sign in to follow this  
deffer

You've lost device? You loose!

Recommended Posts

So my full-screen app is loosing device, when loosing focus. Not a tragedy, you may say, simply wait till you can reset it and recreate the resources, that need to be recreated. The problem is, I loose the device in a wrong moment. If you loose the device when you are in BeginScene/EndScene block, all device-related commands silently fail. If you mean drawing commands - no prob. But what about locking buffers? I'm calling Lock on a vertex buffer, and that bastard gives me S_OK, and a pointer to some memory (not NULL). So how the hell would I know if it's valid or not at the time (obvious answer would be: with a call to TestCooperativeLevel, but do I want to call it before(after?) every device-related command??) Finally - my app crashes at first attempt to write to the given memory chunk. So I'm a little "nervous" about all this... What do you think? ~def

Share this post


Link to post
Share on other sites
Check before rendering. In my Graphic object's Begin() wrapper before calling BeginScene() just test the cooperative level:

HRESULT hResult = m_d3dDevice->TestCooperativeLevel();
if(hResult == D3DERR_DEVICELOST)
{
//release D3DPOOL_DEFAULT stuff and the like

//wait until device is ready to be reacquired
do
{
hResult = m_d3dDevice->TestCooperativeLevel();

//continue processing window messages

//sleep for whatever amount of time
Sleep(10);
}
while(hResult != D3DERR_DEVICENOTRESET);

//reacquire D3DPOOL_DEFAULT stuff and the like
}


That way the last frame drawn to the screen stays there until you regain focus then everything starts running again. The silent fail is documented, by the way.

Share this post


Link to post
Share on other sites
What operating system do you use?
After successful buffer lock try to check returned memory pointer with Win32 API function IsBadWritePtr.

Share this post


Link to post
Share on other sites
load_bitmap_file:
The device is lost between a call to BeginScene and EndScene and before locking a vertex buffer. So it is too late when I check BeginScene's result.
I'm fine with the silent failure paradigm btw, but I don't think it is documented well enough. Drawing commands silently fail. But locking commands shouldn't. Do they? I haven't seen anywhere any info about that.

arabesc:
I'm a window guy (well most of the time).
I don't know what the returned pointer means, really. It could be an invalid location, or it could be a random location, which could point to a valid(but still, incorrect) memory location.

I would like to know what really happens there. Is there any info about locking (not managed) buffers while device is lost?
~def

Share this post


Link to post
Share on other sites
I think these "device lost" failures are great...

Makes you wonder why there is no "whereDidYouLeaveIt"-function.

/R

Share this post


Link to post
Share on other sites
Quote:
Original post by deffer
I'm a window guy (well most of the time).

If you are using the DirectX it's obvious that you are using Windows OS too. But which version? I'm assume that it's Win2000.

Quote:
I don't know what the returned pointer means, really. It could be an invalid location, or it could be a random location, which could point to a valid(but still, incorrect) memory location.

And what stops you from doing this check?
VOID* pData = NULL;
hr = IDirect3DVertexBuffer9::Lock(0, SizeToLock, &pData, 0);
if (SUCCEEDED(hr) && FALSE == IsBadWritePtr(pData, SizeToLock))
...


Quote:
I would like to know what really happens there. Is there any info about locking (not managed) buffers while device is lost?

From DX SDK Doc's:
Quote:
Locking Operations
Internally, Direct3D does enough work to ensure that a lock operation will succeed after a device is lost. However, it is not guaranteed that the video-memory resource's data will be accurate during the lock operation. It is guaranteed that no error code will be returned. This allows applications to be written without concern for device loss during a lock operation.

Share this post


Link to post
Share on other sites
Quote:
Original post by arabesc
If you are using the DirectX it's obvious that you are using Windows OS too. But which version? I'm assume that it's Win2000.

Yeah, that was obvious ;\ It's XP btw.

Quote:

And what stops you from doing this check?
*** Source Snippet Removed ***

If pData points to a random location, it could be my program's memory space, in which case IsBadWritePtr will return TRUE.

Quote:

From DX SDK Doc's:
[...]

Now this is pretty straightforward. Apparently I'm supposed to receive a normal block of memory to write on, so that my app won't crash.
So why does my app crash nevertheless...?

Share this post


Link to post
Share on other sites
Quote:
Original post by deffer
Yeah, that was obvious ;\ It's XP btw.

I had the similar problem some time ago, but it appears only on the W2K system.

Quote:
If pData points to a random location, it could be my program's memory space, in which case IsBadWritePtr will return TRUE.

If the return value of the IsBadWritePtr is TRUE then the memory pointer is not valid for writing.
So, IsBadWritePtr does not really help you solve the problem?
In my case it helped.

Edit: spelling.

[Edited by - arabesc on September 2, 2005 8:57:29 AM]

Share this post


Link to post
Share on other sites
Of course I meant:
Quote:
Original post by deffer (changed by deffer)
If pData points to a random location, it could be my program's memory space, in which case IsBadWritePtr will return FALSE.

So on the one hand - there is no problem, so the docs say. Ptr should be always valid.
On the other hand - my app crashes. And you're saying that it helped, so there was a problem to be solved.

*Confusion*

Share this post


Link to post
Share on other sites
Quote:
Original post by deffer
On the other hand - my app crashes. And you're saying that it helped, so there was a problem to be solved.

In my case the problem exist on Win2K system and does not exist on WinXP. So the problem may be in the OS/drivers but not in the DirectX.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this