SDL_SetVideoMode(depth=0) returns a screen with an alpha channel in
Xgl even though screen->format->Amask is 0. In fact, the pixel format is
identical to the format of a screen returned by a normal X server without
an alpha channel.
Is there a way to detect that a screen has an alpha channel other than
checking Amask? Is this a bug? This is SDL 1.2.9.
Regards,
Anthony Liguori
Anthony Liguori wrote:
SDL_SetVideoMode(depth=0) returns a screen with an alpha channel in
Xgl even though screen->format->Amask is 0. In fact, the pixel format is
identical to the format of a screen returned by a normal X server without
an alpha channel.Is there a way to detect that a screen has an alpha channel other than
checking Amask? Is this a bug? This is SDL 1.2.9.
I’d like to add that this is really annoying since it results in all SDL
windows being transparent in Xgl.
Stephane
And I’d also like to add that it also screws up under X.org when a
composite manager is running.On 3/6/06, Stephane Marchesin <stephane.marchesin at wanadoo.fr> wrote:
I’d like to add that this is really annoying since it results in all SDL
windows being transparent in Xgl.
–
I can’t seem to compile Xgl or get a composite manager working on my
ATI drivers. What exactly is happening here, is it that it’s creating
a 32-bit surface and clearing the unused byte to zero?
-Sam Lantinga, Senior Software Engineer, Blizzard EntertainmentI can’t seem to compile Xgl or get a composite manager working on my
ATI drivers. What exactly is happening here, is it that it’s creating
a 32-bit surface and clearing the unused byte to zero?
It’s actually using SDL_SetVideoMode() and not specifying a depth. This
results in a 32-bit surface being returned. The unused byte is being set
to zero.
Setting the unused byte to 0xFF results in the behavior that one would
expect.On Mon, 06 Mar 2006 22:47:34 -0800, Sam Lantinga wrote:
-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment
It’s actually using SDL_SetVideoMode() and not specifying a depth. This
results in a 32-bit surface being returned. The unused byte is being set
to zero.
Setting the unused byte to 0xFF results in the behavior that one would
expect.
Can you submit a patch? Does it result in slower blits?
Thanks!
-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment
It’s actually using SDL_SetVideoMode() and not specifying a depth. This
results in a 32-bit surface being returned. The unused byte is being set
to zero.Setting the unused byte to 0xFF results in the behavior that one would
expect.Can you submit a patch? Does it result in slower blits?
What I mean, is that if an application sets the byte to 0xFF it fixes the
problem.
For instance, if you treat the pixel as a u32:
(0xFF000000 | r << 16 | g << 8 | b)
To generate a pixel value. I think the right solution would be to detect
Xgl in SDL and avoid grabbing a 32 bit XImage (I’ve got another
application that grabs XImages directly and it can happily grab 24 bit
images on Xgl).
I’m not sure how to detect Xgl or the existence of an alpha mask in X.
Looking into it now.
Regards,
Anthony LiguoriOn Tue, 07 Mar 2006 09:16:18 -0800, Sam Lantinga wrote:
Thanks!
-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment
Indeed. There was some checkbox I was able to set somewhere in KDE
when playing with composite stuff, which worked around this.
It’d be great if SDL itself worked Out Of The Box, though 
-bill!On Tue, Mar 07, 2006 at 12:33:20AM -0500, Simon Roby wrote:
And I’d also like to add that it also screws up under X.org when a
composite manager is running.
Yep, I had to do the same thing. SDL apps were the only screw-ups…On 3/7/06, Bill Kendrick wrote:
On Tue, Mar 07, 2006 at 12:33:20AM -0500, Simon Roby wrote:
And I’d also like to add that it also screws up under X.org when a
composite manager is running.Indeed. There was some checkbox I was able to set somewhere in KDE
when playing with composite stuff, which worked around this.
It’d be great if SDL itself worked Out Of The Box, though
–