Re: Another endian problem - textures

[James W. W. <ja...@fr...>]

Roger Holmes <rog...@mi...> wrote:

>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.

When you say "sets the texture to little endian..." are you referring 
to setting the byte order field in the TQ3StoragePixmap structure? 
Are you sure that the bytes actually are in the order you are 
declaring in the byteOrder field?

>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.

Because the source data could be in either order.  Even if Intel Macs 
did not exist, you could still be loading a 3DMF file containing 
little-endian textures on a PowerPC Mac.

There's a comment in the code that addresses this: "We will fetch one 
byte at a time from the image, so the native endian-ness doesn't 
matter, only the endian-ness of the image as specified by 
srcByteOrder."
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>