I’m wondering if it’s possible to enumerate pixel formats for display modes other than the one the desktop is currently in. For example, if my desktop color depth is 16-bits, then enumerating the wgl pixel formats gives me a list of 16-bit backbuffer formats. If I then change my desktop color depth to 32-bit and enumerate again, I get a different list consisting of 32-bit backbuffer formats. The color bits part isn’t a huge deal (since I can safely assume a 32-bit display mode supports a 32-bit backbuffer), but the depth/stencil/multisample part is. Can I safely assume that the depth/stencil bits and multisample levels will be available when the adapter is in a different display mode (they’re the same on my card)? Any help would be greatly appreciated.
Here you go
http://msdn.microsoft.com/en-us/library/ms970779.aspx
For fullscreen stuff you want to look at the MDSN on ChangeDisplaySettings and friends (EnumDisplaySettings, etc).
Yes I’m quite familiar with that article; what I’m asking for is something different.
The WGL pixel format interface only lists formats that are compatible with the current display mode. If the current display mode happens to be 16-bit, and I want to change to a 32-bit mode for my fullscreen game, then I have no way of telling what pixel formats are available to me until I switch. EnumDisplaySettings doesn’t solve the problem because it doesn’t give you depth/stencil/multisample information. Finally, there is no guarantee that the depth/stencil/multisample information enumerated by GetPixelFormatAttrib*ARB will be available in a different display mode. For example, I’m pretty sure some older cards only had 32-bit depth/stencil buffers available in 32-bit mode.
To illustrate, pretend we start up our game in windowed mode. The user goes to the options menu and selects graphics options. Like most games, you have a combo box with all the available display modes for the user to choose from. Let’s say you also have a multisample quality slider. You have no way of knowing how many ticks to put on that slider to represent the multisample levels supported by the card for a particular display mode other the one you’re currently in. Also, the mode they select might not support the depth/stencil bits you need, but you won’t know about until you actually try to switch modes, recreate your gl window/context, and then realize none of the pixel formats support what you need. Then you have to give the user a tacky error message. The correct thing behavior is to simply not list the mode in the first place but there doesn’t appear to be any way to tell which modes support what you want in GL.
Now I realize that at installation or startup time you could cycle through all display modes and enumerate the pixel formats in each one and store them, but this seems unnecessary when the information is clearly stored in the driver. Direct3D supports exactly what I’m talking about via CheckDeviceType/CheckDepthStencilMatch/CheckDeviceMultiSampleType where you can ask for the pixel format info of any display mode, so I know it’s there.
Now if I can safely assume the multisample and depth/stencil values enumerated for the current mode will apply to any other mode, well that’s good enough for me. I don’t see this explicitly stated anywhere in the GL or MSDN WGL documentation, but if it’s de facto behavior across most modern cards then I’d be fine with that too.
This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.