Take the 2-minute tour ×

DIRECTX9... For ages, I've shipped games that only half-fill out the D3DPRESENT_PARAMETERS structure, and now I'm wondering if this is buggy. The items I'm worried about, and never set are:

  • hDeviceWindow
  • Windowed
  • EnableAutoDepthStencil
  • FullScreen_RefreshRateInHz

I zero out the whole structure initially, so they should all be zero, even if my game is running (happily) in a window. As ever, there are a tiny %tage of users who have issues, and I am looking for possible causes. Could not setting one of these cause problems? The documentation doesn't say either way, and 99% of users certainly are fine with these settings. Does anyone have a definitive answer as to what should be set?

share|improve this question
Upvoted, because cliffski. And I'd like to see GTB working everywhere. :) –  Bloodyaugust Jul 24 '12 at 14:58

1 Answer 1

I normally set all of them, and if you have a look at the enum and other values in the D3D SDK and your header files you'll find that there are very few cases where you can safely use 0.

Windowed is OK if fullscreen is your desired behaviour - it's a BOOL so FALSE will be 0. That'll clash with BackBufferFormat though where D3DFMT_UNKNOWN (value 0) is only documented as safe for windowed modes.

FullScreen_RefreshRateInHz should definitely be given a value for fullscreen modes, and it should be a value from a properly enumerated mode; 0 is only safe for windowed modes (which again clashes with Windowed 0).

Without EnableAutoDepthStencil set to TRUE (1) you won't (or at least shouldn't) have a depth buffer, but yet you may be setting AutoDepthStencilFormat. And so on...

This will be internal driver and/or D3D runtime behaviour so we're into "best guess" country now, but it doesn't seem unreasonable to suppose that there are drivers (or versions of the runtime) out there that can figure something meaningful out from conflicting parameters like this. It's not guaranteed though and shouldn't be relied on.

share|improve this answer

Your Answer


