Pardon my insistence, but there was an error in my previous post.
Instead of leaving incomplete/incorrect information lying around, I
decided to clarify things up...
I created a simple 1-pixel texture using the following data:
byte[0] = 0x00
byte[1] = 0x01
byte[2] = 0x02
byte[3] = 0x80
I called glTexImage2D with the following:
internalFormat = GL_RGBA8
format = GL_BGRA
type = GL_UNSIGNED_INT_8_8_8_8_REV
The thing I didn't understand was why DigitalColor Meter reported a
color of:
R = 2
G = 1
B = 0
My understanding was that GL_BGRA+GL_UNSIGNED_INT_8_8_8_8_REV meant
that the B,G,R,A byte order was reversed, and therefore became A,R,G,B
(the classic native form in hardware). So, with the above bytes, I
was expecting:
R = 1
G = 2
B = 128
Actually, this is not the case, because this is a pixel packed in an
unsigned int. On x86, the 4 bytes above spit out as an int of
0x80020100 (it's little endian). Now, this is where it gets tricky...
I looked at the OpenGL spec (version 2.1), and had a hard time
figuring out the channel order of the packed pixels
(GL_UNSIGNED_INT_8_8_8_8_REV). My main gripe is that neither Preview
nor Adobe Reader could find occurrences of
"UNSIGNED_INT_8_8_8_8_REV" (sounds like the underscores and other
things give bad juju). Anyways, I finally found p.135 which clearly
states that the bit ordering for 32b chunks is the following:
[ 7.. 0] = first element = B = 0x00
[15.. 8] = second element = G = 0x01
[23..16] = third element = R = 0x02
[31..24] = fourth element = A = 0x80
So that explains why I get the result I saw on screen. And that is
also where the error lies in my previous message.
If I had used GL_UNSIGNED_INT_8_8_8_8, then it would have given me the
other result I keep mentioning:
[ 7.. 0] = fourth element = A = 0x00
[15.. 8] = third element = R = 0x01
[23..16] = second element = G = 0x02
[31..24] = first element = B = 0x80
I hope it can clarify things for someone...
On 2007-11-29, at 09:01 , Jocelyn Houle wrote:
Logically no, they should not be the same.
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
This email sent to email@hidden
_______________________________________________
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
