BGRA when reversed (with is what the _REV means) gives you ARGB,
which is clearly not RGBA.
The article you quoted doesn't seem to imply that they are
equivalent. It simply states that the {GL_BGRA,
GL_UNSIGNED_INT_8_8_8_8_REV} combination is better for performance
than {GL_RGBA, GL_UNSIGNED_BYTE} on many cards. If they were
equivalent, the driver would/should be able to figure this out and
do it seamlessly for you. But they are not, thus switching to this
would actually require you to change your texture data.
Good point about the seamless workaround. And it does indeed make
more sense then what I was originally thinking.
Our image-loading code puts:
byte[0]=R
byte[1]=G
byte[2]=B
byte[3]=A
And while GL_BGRA+GL_UNSIGNED_BYTE would mean OpenGL expects:
byte[0]=B
byte[1]=G
byte[2]=R
byte[3]=A
the fact that it is GL_UNSIGNED_INT_8_8_8_8_REV means it is instead:
byte[0]=A
byte[1]=R
byte[2]=G
byte[3]=B
The only thing matching is, well, the classic GL_RGBA+GL_UNSIGNED_BYTE.
It's just that I hadn't touched my code in >5 months, and only just
noticed that textures with alpha had their channels swizzled.
But I looked at the code, and I can't figure out how it could have
worked in the first place...
So unless Tiger had a driver bug that was saving me (unlikely), I'll
have to blame it on a sustained momentary lapse of reason... ;-)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Mac-opengl mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/mac-opengl/email@hidden
