I’m using glDrawPixels(x, y, GL_RGBA, GL_UNSIGNED_INT_10_10_10_2_EXT, buf); on a big-endian machine (IRIX) to display images and all is well. However, attempting to display the same image on a little-endian machine (x86, Linux, XFree, NVIDIA) results in garbage (as is expected) but I’m trying to use:
glPixelStorei(GL_UNPACK_ALIGNMENT, 4);
glPixelStorei(GL_UNPACK_SWAP_BYTES, GL_TRUE);
to fix the endianness problem, and it’s not working - ie, nothing has changed.
What am I doing wrong?
Not really sure if this is related to the problem you have, but on the little endian platforms you can try use GL_UNSIGNED_INT_10_10_10_2_EXT_REV instead. REV should reverse the order of the color components.
Originally posted by Bob:
Not really sure if this is related to the problem you have, but on the little endian platforms you can try use GL_UNSIGNED_INT_10_10_10_2_EXT_REV instead. REV should reverse the order of the color components.
Doesn’t GL_UNSIGNED_INT_10_10_10_2_EXT_REV reverse bit-ordering, rather than byte ordering?
Thanks anyway. I’ve been hacking away at this for some time now, and come to the conclusion that there’s a problem with glPixelStore(GL_UNPACK_SWAP_BYTES support in NVIDIAs Linux drivers. If I feed an SGI byte-swapped images and use
glPixelStorei(GL_UNPACK_ALIGNMENT, 4);
glPixelStorei(GL_UNPACK_SWAP_BYTES, GL_TRUE);
then all is well, so it’s not my code.
Besides, the latest Linux driver build completely broke 10_10_10_2 support - if I glDrawPixels such an image, I get a magenta rectangle.
Time to post NVIDIA a bug report.