In hex that is 0x8876086C, which is D3DERR_INVALIDCALL.
This thread may help you fix the problem.
Nevermind.. that's using the ref device. I'm not sure what the problem could be. Google isn't turning up a lot of information, but either one of your parameters is wrong or your card doesn't support something you're trying to access.
D3D device pointer somehow becomes invalid??
Author
oh ok, that may be the problem, i've got horrible integrated graphics, is there any way to use just software rendering?
Quote:Original post by godsenddeath
is there any way to use just software rendering?
Pass D3DDEVTYPE_REF instead of HAL to CreateDevice.
First, you should really be checking all your "important" D3D return values. Particularly ones that returns a pointer (Such as Create*() Lock(), etc). If any of those functions fail and you don't notice, you'll end up dereferencing null (or worse, undefined) pointers and crashing at best the next time you reference it, and at worst at some random point in your app.
It's a good idea (although I admit I don't bother) to check ALL your D3D functions with a macro that asserts or something in debug builds, and compiles way in release builds, and use that for non-essential calls.
Second, the debug runtimes ar invaluable. In this case in particular, they'll tell you exactly what's wrong - if a D3D function fails, they'll ALWAYS give you a useful message in the debug output, telling you why the function failed. Such as "D3D(ERROR): ValidatePresentParameters(): BackBufferWidth cannot be 0. CreateDevice fails with D3DERR_INVALIDCALL" - which is possibly the problem you're seeing.
To install the debug runtimes, go to the DirectX control pannel (In the Windows control pannel in older SDKs, in the DirectX SDK folder -> tools in the start menu in more recent SDKs), and make sure "Use Debug Runtime" is selected.
Although, if the debug runtimes tell you what's wrong, and you fix it, it's still extremely important to check your return values. Just because it works on your hardware, doesn't mean it'll work on someone elses.
Also, slightly unrelated - the reference rasterizer isn't really for checking bugs like this. It might show them up, but it won't be as useful as the debug runtimes. The ref rast is so you can test things not supported by your hardware, such as advanced pixel shaders, and is for use if you think you have a driver bug (If a HAL and REF device behave differently, it's almost always the REF device that's correct, and the HAL device is buggy, meaning bad drivers).
Finally, the ref device is only available on machines with the SDK installed. You can't expect end users to have it installed at all.
It's a good idea (although I admit I don't bother) to check ALL your D3D functions with a macro that asserts or something in debug builds, and compiles way in release builds, and use that for non-essential calls.
Second, the debug runtimes ar invaluable. In this case in particular, they'll tell you exactly what's wrong - if a D3D function fails, they'll ALWAYS give you a useful message in the debug output, telling you why the function failed. Such as "D3D(ERROR): ValidatePresentParameters(): BackBufferWidth cannot be 0. CreateDevice fails with D3DERR_INVALIDCALL" - which is possibly the problem you're seeing.
To install the debug runtimes, go to the DirectX control pannel (In the Windows control pannel in older SDKs, in the DirectX SDK folder -> tools in the start menu in more recent SDKs), and make sure "Use Debug Runtime" is selected.
Although, if the debug runtimes tell you what's wrong, and you fix it, it's still extremely important to check your return values. Just because it works on your hardware, doesn't mean it'll work on someone elses.
Also, slightly unrelated - the reference rasterizer isn't really for checking bugs like this. It might show them up, but it won't be as useful as the debug runtimes. The ref rast is so you can test things not supported by your hardware, such as advanced pixel shaders, and is for use if you think you have a driver bug (If a HAL and REF device behave differently, it's almost always the REF device that's correct, and the HAL device is buggy, meaning bad drivers).
Finally, the ref device is only available on machines with the SDK installed. You can't expect end users to have it installed at all.
Everything Evil Steve said is great.
If you want a more verbose treatment/explanation of those issues, look at my book. From the way you are talking, it sounds like you are completely new to Direct3D and don't know a thing about it, so instead of pointing you to specific chapters, I'd just recommend you read the whole thing.
If you want a more verbose treatment/explanation of those issues, look at my book. From the way you are talking, it sounds like you are completely new to Direct3D and don't know a thing about it, so instead of pointing you to specific chapters, I'd just recommend you read the whole thing.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
