Window doesn't have an alpha channel

[BlastRock]

Hi !

I have a problem with the window creation with SFML. Here's how a create my window :
  sf::Window(sf::VideoMode(640, 480, 32),
      "OpenGL", sf::Style::Default,
      sf::ContextSettings(32, 0, 0, 2, 1)),

Even if I create my window with 32 bpp, it seems like the window does not have an alpha channel. I checked with gDEBugger which tells me that GL_ALPHA_BITS is 0. The consequence is that when I do a glReadPixels, I can't get the alpha channel.

Btw, blending with GL_BLEND works fine and I'm using SFML2 (revision 5706111) on Linux.

Any help on that?

[BlastRock]

I just tested the same code on Mac and I get a context with GL_ALPHA_BITS == 8.

[BlastRock]

Can someone test this code to see if they have the same issue as me?

#include <SFML/Window.hpp>
#include <iostream>
#include <GL/gl.h>

int main()
{
  sf::Window w(sf::VideoMode(640, 480, 32),
      "OpenGL", sf::Style::Default);

  int b;
  glGetIntegerv(GL_ALPHA_BITS, &b);
  std::cout << b << std::endl;
}

Thanks.

[binary1248]

First you could look at what OpenGL pixel formats are available in gDEBugger (Tools->System Information->OpenGL Pixel Formats). If you find what you want in that table you can try sf::VideoMode::getFullscreenModes() and see if it shows up there. If it doesn't match up then something went wrong in SFML or the system calls somewhere.

[eXpl0it3r]

I'm not sure if this will help you but I get printed out 8, so it seems it must be something strange with your system...

[BlastRock]

Thanks for the answers!

First you could look at what OpenGL pixel formats are available in gDEBugger (Tools->System Information->OpenGL Pixel Formats). If you find what you want in that table you can try sf::VideoMode::getFullscreenModes() and see if it shows up there. If it doesn't match up then something went wrong in SFML or the system calls somewhere.

I just looked in gDEBugger, all the formats listed there are marked as 32 bits RGBA. Though they are all 32 bits RGBA, some of them are marked with 8, 8, 8, 0 bits and others with 8, 8, 8, 8 bits. So, the context I want seems to be supported. Can it be that SFML takes the first 32 bit context that it can create, which is the one with no alpha bits? I think that because in this list, for each format, there is a 0 alpha bits variant and a 8 alpha bits variant and the 0 alpha bits variant is listed first every time.
I also looked at the getFullscreenModes(), it gave me all the supported resolutions with different bpp (1, 4, 8, 15, 16, 24, 32) but I'm not sure what this means since gDEBugger listed all the modes as 32 bits.

I'm not sure if this will help you but I get printed out 8, so it seems it must be something strange with your system...

Thanks for testing! Was it on Linux too? And what is your SFML version? With which OpenGL drivers?
Btw, I'm using the nVidia proprietary drivers.

I have very little knowledge in OpenGL context creation so any help is appreciated

[eXpl0it3r]

Thanks for testing! Was it on Linux too? And what is your SFML version? With which OpenGL drivers?
Btw, I'm using the nVidia proprietary drivers.

No it was on Windows 7 with the latest SFML version and the official Catacylst driver.
Have you already tried a diffrent driver?

[BlastRock]

I just tried the xorg software driver, same result, 0 with the program of my previous post.
gDEBugger would just crash on start-up with these drivers. I checked the list of supported formats with glxinfo, it seems that they are the same as with the nVidia driver.

[eXpl0it3r]

I just tried the xorg software driver, same result, 0 with the program of my previous post.
gDEBugger would just crash on start-up with these drivers. I checked the list of supported formats with glxinfo, it seems that they are the same as with the nVidia driver.

What graphics card do you use then?

[TheVirtualDragon]

I get 0 as well.

Specifications:
OS: Linux Mint 13
Bit Type: 64 bit
Graphics: nVidia
Driver: Official nVidia driver

This is strange...I might test it on Windows later.

[Laurent]

This might be related to these issues:
https://github.com/SFML/SFML/issues/258
https://github.com/SFML/SFML/issues/35

[binary1248]

I just looked in gDEBugger, all the formats listed there are marked as 32 bits RGBA. Though they are all 32 bits RGBA, some of them are marked with 8, 8, 8, 0 bits and others with 8, 8, 8, 8 bits. So, the context I want seems to be supported. Can it be that SFML takes the first 32 bit context that it can create, which is the one with no alpha bits? I think that because in this list, for each format, there is a 0 alpha bits variant and a 8 alpha bits variant and the 0 alpha bits variant is listed first every time.
I also looked at the getFullscreenModes(), it gave me all the supported resolutions with different bpp (1, 4, 8, 15, 16, 24, 32) but I'm not sure what this means since gDEBugger listed all the modes as 32 bits.

Something might have went wrong in SFML's GlContext::evaluateFormat(...). If you ask me it doesn't take into account that different non-matching attributes can lead to the same score. The bpp being off by 8 (because of missing alpha for example) might have the same score as stencil, depth or AA being off by 8 in another configuration and because SFML sticks with the first occurrence of a lowest score it might end up being the one without alpha.

https://github.com/SFML/SFML/issues/258

This looks like it only applies to OpenGL 3.0+ contexts. TheVirtualDragon is having this issue with a "standard" 2.0 context.

[BlastRock]

What graphics card do you use then?

nVidia GeForce 9300M GS, a bit old but I'm sure it can support at least 32 bit output ^^
Also, the mac on which I tested the program (where it printed had a GeForce 9400M or something like that.

I get 0 as well.

Thanks for testing, glad to know I'm not the only one with this problem

Ok, I just put some debug in GlxContext::createContext, which calls evaluateFormat.
Here is the interesting part:

    // Get the attributes of the target window
    XWindowAttributes windowAttributes;
    if (XGetWindowAttributes(m_display, m_window, &windowAttributes) == 0)
    {
        err() << "Failed to get the window attributes" << std::endl;
        return;
    }

    // Setup the visual infos to match
    XVisualInfo tpl;
    tpl.depth    = windowAttributes.depth;
    tpl.visualid = XVisualIDFromVisual(windowAttributes.visual);
    tpl.screen   = DefaultScreen(m_display);

    // Get all the visuals matching the template
    int nbVisuals = 0;
    XVisualInfo* visuals = XGetVisualInfo(m_display, VisualDepthMask | VisualIDMask | VisualScreenMask, &tpl, &nbVisuals);

I don't know how this works, but it turns out that windowAttributs.depth (and thus tpl.depth) is 24. Then XGetVisualInfo gives only one format which is 24 bits.

Thanks binary1248 for mentioning evaluateFormat which lead me to this function

[Laurent]

XGetVisualInfo will always give only one format, because I force its ID. This is what issue #35 describes.

[BlastRock]

Okay, I think I get it now!
So, you create the window before you create the GL context. Then, the problem is not that the context is created with 24 bit colors but the window itself is created with 24 bit colors and then you create the context with the same settings. Am I correct?

I tried putting 32 instead of DefaultDepth(m_display, m_screen) in the XCreateWindow call but it would just fail with a BadMatch error. I guess it couldn't be that easy

Anyway, my issue here seems to differ a bit from the issue #35 since it only deals with color depth. Doesn't this issue only involve X11, as opposed to issue #35 which involve OpenGL specific stuff?