On losing my device, the only thing I do (or ever will do) is release things or call wrapper OnLostDevice events, which I can only assume ultimately do the same thing. I know everyone keeps saying to check the return codes, but I honestly cannot see a situation where even the D3DX OnLostDevice() wrappers will ever return a failure code, save for an occasion I call them when the device isn't really lost. ;) Why worry about return codes on lost device events when everything else shows more reason to be checked? I don't see a reason to report to the caller that everything was released successfully, because I don't see any reason for THAT to fail outside of forgetting to actually do that job! (In which case, you still don't think you've failed until the app crashes.)

Quote:Original post by zyrolasting
Why worry about return codes on lost device events when everything else shows more reason to be checked?

because when you get an D3DERR_INVALIDCALL error its usually your fault and is something that you can prevent from happening so you want to make sure to always catch it so you can find problems in how your using D3D as fast as possible.

if your worried about extra code for checking do something like

#define HR(x) {  HRESULT hr = x; if(FAILED(hr)){ LogError("D3D Call failed with error result '%i':\n\t%s", (int)hr, #x); __debugbreak(); }}

and then just wrap your calls that you never expect to fail with HR() and when your debugging your code and one of those functions happens to fail it will break right away and you can figure out whats wrong with your code.

My point is that the chance of failure for responding to a lost device is effectively zero when you check return codes for other device events, etc and you respond when the device is really lost.

Outside of the scenarios I've mentioned, give me some reasons why some D3DX OnLostDevice() calls can be invalid. I just see no need for checking them, because the only "oops" moment I've observed is forgetting to release everything, and no return code can help you there.

As I see it, checking lost device return codes is like checking if a pointer to newly allocated dynamic memory is NULL. Sure you are "playing it safe", but there's not much point to it if all that ever happens is ultimately calling IUnknown::Release() a few hundred times.

Just understand I'm not saying that return codes shouldn't be checked at all.

Quote:Original post by zyrolasting
Outside of the scenarios I've mentioned, give me some reasons why some D3DX OnLostDevice() calls can be invalid. I just see no need for checking them, because the only "oops" moment I've observed is forgetting to release everything, and no return code can help you there.

Like I said the checking code isn't necessarily about fixing the problem at run time, think of the HR() macro I presented above like an ASSERT, when it goes wrong something broke, but it alerts you as the programmer debugging the problem exactly where the first signs of the problem occurred.

Thing is, with the right setup, you don't actually know if your lost device response failed until you actually try to reset the device.

Beating a dead horse here, but there is nothing to assert in lost device methods because of the simplicity in the task. The only assertion ever made is "I got rid of ALL volatile resources!". Is there a function that checks how many volatile resources are still unfreed in D3D? I can understand doing your thing and checking THAT. That would actually be awesome.