Jump to content
  • Advertisement
Sign in to follow this  
amarhys

Direct X Error Handling good practice

This topic is 2586 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

Hello,

I am working on a Direct3D game (Myst-like) using DirectX9.

I have already created a demo and tried it on some computers (one XP, one Vista, 2x Windows 7 and some others) and it worked fine.

I tried to install it on a IBM Lenovo machine, a T420 which has 2 embedded video cards (one IBM for low consumption, one NVIDIA for performance). The managing of these two cards is fully tranparant for the users, Windows 7 takes care of switching the cards when needed. Moreover, when I enumarate the available display adapters, only the IBM one is listed (GetAdapterCount() returns 1 - followed by GetAdapterIdentifier() which returns the IBM card description).

This is for the context.

Now, the demo was not working very well on this Lenovo. Investigating a little bit and debugging the code, I noticed some of the directX calls (most of them during the rendering phase) where not returning D3D_OK (whereas texture are loaded correctly and everything seems fine) and then made the program to crash (because I check all directX calls and display error message and exit when an error is seen - which is working fine on the other computers I tried).

I decided not to check the status of DirectX calls during the rendering (I just check, before using a texture for example, that the texture has been correctly loaded, if not, I skip the display of this texture and continue rendering ..) and now everything works fine on the Lenovo. The demo is just running well, no crash any more, and no display artifacts noticeable.

Maybe my initial code was too strict, I mean to exit the game with an error when one of the DirectX call has failed (but as I said, working well until Lenovo experience).

What is the good practice ? Should I investigate more on the Lenovo or could I accept a rendering procedure whose some DirectX calls are failing .. in any case they will be performed on next calls to rendering function .. which is confirmed because no display artefacts at the end..).

Note : before each call to rendering function my code is already checking if the device is lost, and if lost, waits if not ready to be reseted and reset as soon as ready.




Thanks in advance for your answer.

-amarhys

Share this post


Link to post
Share on other sites
Advertisement
What error code do you get when those textures fail to load?

Which pool are you loading your textures into?

If you're running low on texture memory using D3DFMT_DXT1 and D3DFMT_DXT5 appropriately can also save huge quantities of memory (and disc space), with a fairly small loss of visual quality for most textures.

Share this post


Link to post
Share on other sites
For all textures I am using D3DPOOL_MANAGED.

Most of my textures (90%) are in DXT3 format.

I am still investigating where do the error exactly come from. For sure from one or more DirectX calls in my global render() function. This function is a basic rendering sequence, ie. BeginScene() .. vertex buffer updates ... basic draw primitive .. vertex buffer updates ... basic draw primitive...... EndScene().

All textures are loaded outside this render() function. If I have added check of textures in the render() function, it was just to be sure I am not trying to render a texture which has not been loaded successfully .. but I don't think the problem comes from texture (indeed, when I just ignore the render() call which are failing, the next render() call seems to work fine and the texture are all displayed, any missing ones).

I guess the problem is in my render() function, it seems that sometimes DrawPrimitive and/or Vertex buffer updates are not working .. and only with this Lenovo computer with the dynamic management of the video cards.

I am still investigating the issue to try to find which D3DX calls are failing. And trying to find if I can do something to avoid this or just have to live with it.

Is there something to check before entering BeginScene() -> EndScene() sequence ? I am already checking if the device is lost or not, and call the render() only when the device is ready. Can the device be lost during the BeginScene () -> EndScene() ?

Thanks for your help Adam_42.

Xavier




Share this post


Link to post
Share on other sites
Hmm, using the managed pool I'd be surprised if it's running out of memory. D3D will swap those textures in and out of video memory as need be.

If you can install the DirectX SDK on that laptop, then use the debug runtime to track down what error messages you're getting. I normally set the debug output level to one below maximum.

By the way for textures without an alpha channel DXT1 is half the size of the other DXT formats, and no different in quality.

Share this post


Link to post
Share on other sites
If you're testing for hr == D3D_OK as your success condition then you should change that and use the FAILED and SUCCEEDED macros instead. Yeah, they look a little uglier, but it's the case that not every success is D3D_OK (in fact any non-negative HRESULT is a success according to WinError.h).

It's also worthwhile building some more benign error responses. Sometimes it may be more acceptable to just draw nothing, or run a fallback path, if you get a failure.

One other thing that springs to mind here is that your Present call may return D3DERR_DEVICELOST (and friends), which is a normal condition that you need to handle in your code. This may be particularly relevant for your switchable graphics case. Note that Present is not the only call that can return this, but it's normally OK to restrict your check of it to your Present calls. (If you're already handling lost devices through WM_ACTIVATE then you need to junk that code pretty damn pronto and move it to a check after your Present call instead; Alt-Tabbing is not the only thing that can cause a lost device; far from it. I bet that switchable graphics can cause lost devices without the user even needing to go near either the Alt key or the Tab key.)

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!