In OpenGL you can use glGetIntegerv(GL_RED_BITS,Varptr(redbits)) and the same for GL_GREEN_BITS, GL_BLUE_BITS, GL_ALPHA_BITS, and also for the other buffers such as GL_STENCIL_BITS, GL_DEPTH_BITS, GL_ACCUM_BITS.
You WILL find that the numbers that this reports back to you might well be different to how the mode is *described* in the list of screen modes, and even how it is described in the o/s.
My desktop is 32-bit. Or rather, it refers to is as widthxheight Millions of colors. Then in Max, if I get the list of modes, it reports it as 32-bit. However, OpenGL reports the desktop is a 24-bit desktop, not 32-bit, and doesn't have an alpha buffer. Also if I switch my display to a 16-bit desktop, which is advertized in the o/s as widthxheight Thousands of colors, Max reports it as a 16-bit mode from the list, but in OpenGL it reports it is actually a 5:5:5 mode, ie 15-bit, with no alpha.
Conclusion: GetGraphicsMode() returns only a higher-level approximation of what the mode is, not the actual mode. The actual mode internally may be less bits per pixel and may not include an alpha channel. 32-bit might actually be 24-bit and 16-bit might be 15-bit.
Yet, if you try opening a 15-bit screen, having been told by OpenGL that it is 5 bits per pixel not 5:6:5, you will have some problems - a display might open but it can be extremely slow compared to the 16-bit mode - whereas if you request a 16-bit mode, it gives you 16-bits-per-pixel but uses only 15 of them. All confusing stuff.
To get desktop depth I open a very small window 64x1 and then use test via OpenGL, add up the bits and see what you get. You might want to assume that 15-bit=16-bit, but it probably will report correctly whether you have an alpha buffer.
NB: Opening a window on a 32-bit screen which is actually a 24-bit screen, and asking for an alpha channel, does give you an alpha channel. It seems.
You WILL find that the numbers that this reports back to you might well be different to how the mode is *described* in the list of screen modes, and even how it is described in the o/s.
My desktop is 32-bit. Or rather, it refers to is as widthxheight Millions of colors. Then in Max, if I get the list of modes, it reports it as 32-bit. However, OpenGL reports the desktop is a 24-bit desktop, not 32-bit, and doesn't have an alpha buffer. Also if I switch my display to a 16-bit desktop, which is advertized in the o/s as widthxheight Thousands of colors, Max reports it as a 16-bit mode from the list, but in OpenGL it reports it is actually a 5:5:5 mode, ie 15-bit, with no alpha.
Conclusion: GetGraphicsMode() returns only a higher-level approximation of what the mode is, not the actual mode. The actual mode internally may be less bits per pixel and may not include an alpha channel. 32-bit might actually be 24-bit and 16-bit might be 15-bit.
Yet, if you try opening a 15-bit screen, having been told by OpenGL that it is 5 bits per pixel not 5:6:5, you will have some problems - a display might open but it can be extremely slow compared to the 16-bit mode - whereas if you request a 16-bit mode, it gives you 16-bits-per-pixel but uses only 15 of them. All confusing stuff.
To get desktop depth I open a very small window 64x1 and then use test via OpenGL, add up the bits and see what you get. You might want to assume that 15-bit=16-bit, but it probably will report correctly whether you have an alpha buffer.
NB: Opening a window on a 32-bit screen which is actually a 24-bit screen, and asking for an alpha channel, does give you an alpha channel. It seems.