Jump to content
  • Advertisement
Sign in to follow this  
PumpkinPieman

Device Reset

This topic is 4814 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm having this little problem with resetting the device, I have it reset it everytime the window is resizes to prevent stretching. I'm getting the error D3DERR_INVALIDCALL but I'm passing the structure I used to setup the device to it, I never changed it so I don't know what else it could be. When I use DXGetErrorDescription9 I get the return string "Invalid Call", which means nothing to me. Resetting the device works but when it starts to fail, it will fail everytime the window is resized after that. Has anyone had this error before?

Share this post


Link to post
Share on other sites
Advertisement
So you get the Invalid call when it attempts to reset the second time? Are you sure that it reset the first time? Did it return D3D_OK? Do you release all of your resources that use video memory (textures, vertices, etc) and device resources (render targets, depth stencils, etc) before calling Reset? Do you then put all of that back in place after you call Reset?

Share this post


Link to post
Share on other sites
Reset works a few times, it works more then once before it stops working; it also stops working after a swapchain has been released. The textures I set up are managed.

Here's a quick and dirty reset I made (I'm in the process of littering my code with a lot of error checking).

void cGraphics::Reset(DWORD width, DWORD height, bool fullscreen)
{
if(m_device == NULL)
return;

m_width = width;
m_height = height;
m_fullscreen = fullscreen;

m_sprite->OnLostDevice();
m_line->OnLostDevice();

// Release swap chains

if(m_fullscreen){
m_d3dpp.Windowed = FALSE;
m_d3dpp.BackBufferWidth = m_width;
m_d3dpp.BackBufferHeight = m_height;
}else{
m_d3dpp.Windowed = TRUE;
m_d3dpp.BackBufferWidth = 0;
m_d3dpp.BackBufferHeight = 0;
}

HRESULT hr = 0;
if(FAILED(hr = m_device->Reset(&m_d3dpp))){
MB(DXGetErrorString9(hr));
MB(DXGetErrorDescription9(hr));
}

// Recreate Swap chains


m_sprite->OnResetDevice();
m_line->OnResetDevice();

};

Share this post


Link to post
Share on other sites
Have you tried the debug D3D runtime with the dbug output set to maximum? You should get some information spat out telling you why it's failing.

Do you have any resources created in D3DPOOL_DEFAULT? Or anything like an ID3DXSprite interface that needs to have OnLostDevice() and OnResetDevice() called on it?
Edit: I see you already call OnLostDevice() and OnResetDevice(). Never mind...

Share this post


Link to post
Share on other sites
One thing, i can think of is the hwnd.
Do you save the hwnd in the present param struct?
Sometimes when you get the WM_SIZE message, the hwnd has a invalid size, like 0,0 for instance. I solved this by not saving the hwnd in the present param struct. But saving it somewhere else and using it in the present(0,0,hwnd,0) function as an argument instead.

This would cause reset() to stop failing for me when resetting it on WM_SIZE.

Hope it helps.

EDIT: This is also true for recreating the swapchains, which also needs a present param struct.

Share this post


Link to post
Share on other sites
I've ran into InvalidCallExceptions myself.

Here's what I've encountered:

1) I reset the device. No exceptions are thrown and it appears to be successful.

2) Try and use the device pointer to do something shortly after. This throws and InvalidCallException. The MSDN says this exception is thrown because of a bad param in my method but that doesn't seem to be the case.

The solution I've found is to let Windows do a little message pump processing. For example, reseting the device usually happens during a window state or form border style change. I'll catch the InvalidCallException, let Windows do some processing by calling Applicaiton.DoEvents() (i'm using .net). This flushes the message queue, and then goes back to the previous device code, which no longer throws an exception.

Not sure what the Win32 equivalent to Application.DoEvents() is, but I hope that helps.

I recommend implementing a tracing mechanism. You'll be shocked at what Windows does, and what you think it should have done.

Regards.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!