Re: Quesa on Intel woes. Does Quesa support only native byte order?

[Sean M. <se...@ro...>]

On 2006-05-19 10:54, James W. Walker said:

>>  That is, can I not provide a big
>>endian buffer on a little endian system or vice versa=3F
>
>Currently not.  Why do you want to=3F

I don't.  I'm just trying to understand how changing inputs affects the
output I see.

>>  If I change the
>>"Background Test" in such a way that I pass the wrong byte order I get
>>the assertion but the app still works (no images are byte swapped).
>
>Exactly what did you change=3F  Do you mean pass the wrong value for 
>pixmapDrawContextData.pixmap.byteOrder, which would just be a case of 
>false advertising, or do you mean that you removed the 
>kNativeEndianPixMap flag from the NewGWorld calls in QutTexture.c=3F

The former.  So the behaviour makes sense given that Quesa always works
in native endianness.  If I change the latter, then the triangle becomes
awash in blue (expected) but the background image does not get swapped,
why is that=3F

I'm just trying to understand the Background Test example fully because
with Quesa 1.7 both it and my app had the same problem (offscreen
rendering awash in blue).  Now with 1.8 the example app works, but my
app still has the same problem as in 1.7.

Cheers,

-- 
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Sean McBride, B. Eng                 se...@ro...
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montr=E9al, Qu=E9bec, Canada