[Bf-committers] Re: image editor / draw alpha

Brecht Van Lommel brechtvanlommel at pandora.be
Wed Jun 14 01:20:27 CEST 2006


Hi,

Branan Riley wrote:
> The problem is the draw alpha option, to show what the alpha looks
> like. It's using a single 32-bit value for the display of the alpha,
> which is actually all four components, not just the alpha.
> 
> I did a test with an image, and it's definately using all four
> channels. I'm getting drastically different values based on the color,
> not just on the alpha.

I can't reproduce that here (Mac OS X, PPC, ATI).

> Here's the offending code segment...
> 
> static void sima_draw_alpha_pixels(float x1, float y1, int rectx, int
> recty, unsigned int *recti)
> {
> 
>    /* swap bytes, so alpha is most significant one, then just draw it
> as luminance int */
>    glPixelStorei(GL_UNPACK_SWAP_BYTES, 1);
>    glaDrawPixelsSafe(x1, y1, rectx, recty, rectx, GL_LUMINANCE,
> GL_UNSIGNED_INT, recti);
>    glPixelStorei(GL_UNPACK_SWAP_BYTES, 0);
> }
This might be an endianness issue. The trick used here is to make
alpha the most significant byte, so that after rounding the RGB part
will just be ignored. On big endian alpha is the least significant byte,
so it needs to be swapped. On little endian the swap is not needed.

So I guess you're using Intel or another little endian processor, and
Ton tested this on his Mac OS X PPC?

Brecht.


More information about the Bf-committers mailing list