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

[Branan Riley]

I'm running Gentoo Linux x86-64 on a Pentium 4, so endianness is
probably the issue. I don't think testing for the Mac OS define would
work, since there are also Intel-based macs. Does anyoen know the
right define to check for to distinguish endianness?

On 6/13/06, Brecht Van Lommel <brechtvanlommel at pandora.be> wrote:
>
> 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.
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers
>