Another endian problem - textures

[Roger H. <rog...@mi...>]

I am now working on dropping textures onto 3D objects using Cocoa on  
an MacBook Pro (Intel).

The easiest way to get the texture from Cocoa is as an NSImage and  
then get Cocoa to convert it
to an NSBitmapImageRep. This gives me a 24 bit per pixel image with  
no pad bytes. I create a
texture from it and then have some conditional code which sets the  
texture to little endian byte
order on Intel and big endian byte order on PowerPC. When I use the  
interactive renderer to draw
it (onto a cube), the red and blue components are swapped.

In IRTexture.h there is a routine called  
IRRenderer_Texture_ConvertDepthAndFlip
It checks the endian byte order. For little endian it swaps, and for  
big endian it does not.
But it never looks at the pixel as a long, always through a TQ3Uns8*.  
I do not understand
why it ever needs to swap the bytes. There is of course an issue with  
where the Alpha
component is when using 32 bit data, but that just happens to be  
resolved in the same
piece of code.

If I lie and say it is endian big then it works on Intel. Strange.

Roger.