2
\$\begingroup\$

i'm was revising some code i wrote some time ago when working on the window wrapper for my rendering framework. The framework is based off DirectX, but it wasn't really using any D3D-related facility. Instead it was wrapping the EnumDisplaySettings call :

DEVMODE dm;
dm.dmSize = sizeof(dm);
int_32 count{ 0 };
while (EnumDisplaySettings(NULL, count, &dm))
{
    if (dm.dmPelsWidth == _width && dm.dmPelsHeight == _height)
    {
        m_width = dm.dmPelsWidth;
        m_height = dm.dmPelsHeight;
        m_color_resolution = dm.dmBitsPerPel;
        m_display_frequency = dm.dmDisplayFrequency;
        return true;
    }
    ++count;
}

Simple as that, this doesn't take into account the format. It does take the refresh rate in count (DisplayFrequency) that I've supposed being the same thing. I'm using this Win32 call because later whenever someone needs to set the window to fullscreen I apply the DEVMODE through ChangeDisplaySettings().

I could have used the IDXGIAdapter::EnumOutputs call, but this doesn't give me the bits per pixel (or color resolution). I've done some tests and its value is 32 most of the times but I don't want to take it for granted. My question(s) is(are):

  • Is there any way to get the color resolution through Direct3D ? is it strictly related to the format ?
  • Is my approach correct at all ? because i'm having some doubts, should i keep using the Win32 calls or use the D3D ones ?

I apologize if this question has already been answered or if it has an obvious answer that I can't get, I bet I'm missing something.

\$\endgroup\$
2
\$\begingroup\$

Is there any way to get the color resolution through Direct3D ? is it strictly related to the format?

The color resolution (bits per pixel) of a surface is strictly bound to the format of that surface, yes. You can use CheckFormatSupport to determine what formats are available for what uses at runtime.

Is my approach correct at all ? because I'm having some doubts, should I keep using the Win32 calls or use the D3D ones?

Due to the nature of the Windows platform and the way it's evolved over the years and focused on retaining backwards compatibility, there are a lot of ways to do things. Each will have various pros and cons but often any option will work fine. You may be able to accomplish what you want in slightly fewer lines with DXGI, or slightly more (without knowing in detail what you are doing, it's hard to say). The DXGI approach is "more modern," if that matters to you.

However, if your code is functional and (appears) bug-free, I wouldn't rush to change it.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.