Re: [AD] Status of A5 on OS X (ppc)

[Elias Pschernig <elias@xxxxxxxxxx>]

On Thu, 2008-09-18 at 20:24 -0400, Evert Glebbeek wrote:
> On 17 Sep 2008, at 22:11, Evert Glebbeek wrote:
> >> Should be four squares of different colours.
> >
> > I was afraid you were going to say something like that...
> 
> Another endianesse bug, this time in ex_lockbitmap rather than  
> Allegro itself.
> The problem was that the colour components were stored in a  
> particular byte order, but AARRGGBB really means that the lowest- 
> valued byte in a 32 bit word repersents blue, not necessarily the  
> lowest byte in memory.

Ok, so right now, all our pixel formats like
ALLEGRO_PIXEL_FORMAT_ARGB_8888 are not really what they say on big
endian. Do we want to fix that?

Can you try changing this line in src/opengl/ogl_bitmap.c

{GL_RGBA8, GL_UNSIGNED_INT_8_8_8_8_REV, GL_BGRA}, /* ARGB_8888 */

to this

{GL_RGBA, GL_UNSIGNED_BYTE, GL_BGRA}, /* ARGB_8888 */

instead, then try again with the original example? It makes OpenGL not
do endian-specific conversion, and I assume it will therefore make the
original example work (unless some endian-color-conversion takes place
in between).

Somehow I think this also is what we really intended - the pixel format
specifies the actual layout in memory, not the layout with a 32-bit
integer. I certainly would sleep better knowing that
ALLEGRO_PIXEL_FORMAT_ARGB_8888 means that layout in memory, following
DirectX naming (which is reversed OpenGL naming for that matter :P). So
the above (rather odd) format would mean this in memory:

address[0] = B
address[1] = G
address[2] = R
address[3] = A

Right now, it only means that on little endian, and means this on big
endian (consistent with your fix):

address[0] = A
address[1] = R
address[2] = G
address[3] = B

However, I'm unsure about the implications.. we might need another set
of pixel format conversion functions for big endian systems to get the
actual memory layout right in all cases then. But if we leave it be,
there also might be a lot of hidden issues crop up on big endian
systems.

-- 
Elias Pschernig <elias@xxxxxxxxxx>