| Re: [AD] Status of A5 on OS X (ppc) |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
(seems SF changed something so mails sent to [AD] with my normal email
server didn't get through.. using gmail now which apparently works)
On Thu, 2008-09-18 at 22:09 -0400, Evert Glebbeek wrote:
>
> I can confirm that this does indeed fix the problem with
> ex_lockbitmap also, and from a quick test with some of the other
> examples it doesn't seem to lead to a regression.
> I have to admit I don't really understand the change though. The
> relevant bit that tells OpenGL to not do the conversion is presumably
> the change of GL_UNSIGNED_INT_8_8_8_8_REV to GL_UNSIGNED_BYTE? Is the
> change of GL_RGBA8 to GL_RGBA relevant (I presume not)?
No, could also just use numerical "4" there. It's OpenGL's
"internalformat" value. Basically, OpenGL supports both endianness-aware
formats and "real" byte formats. For little-endian machines, there is no
difference, and that I originally used the *INT* formats in that table
was just coincidence.
>
> That is the impression I had, yes, which is part of the reason I
> didn't try to clean up the patch and commit it.
> That is a slightly dangerous mindset to have though (in my opinion),
> because it is true on little endian systems, which is probably the
> most common type of machine available at the moment. That makes it
> easy to assume that ARGB also represents the byte order in memory (I
> certainly would do that). For instance, there was a similar bug in
> the TGA loader (outside the scope of the colour conversion functions).
Yes, whenever you are directly dealing with pixel data, like in an image
loader, this will be a problem.
> Tthe question is really what "ARGB8888" would mean as a datatype: a
> packed 32 bit integer or an array of 4 bytes with a particular order.
> They are of course the same on a big endian machine, but not on a
> little endian machine
Other way around. Big endian simply is stupid, no matter how you look at
it :P
> The pixel conversion functions in pixels.c all work on packed
> integers using bitshifts and logical operators. So they do not encode
> for an array of 4 characters. If they are supposed to do that, then
> they are technically wrong.
Well, they can stay as they are - just on big endian, different
functions would need to be used (the ones with opposite ordering). One
problem is, what do we do about 24-bit types? How are they supposed to
work on a big endian system?
> I should point out that they actually work properly, indicating that
> at least part of the code was written with the (accidental?)
> intention that the format refers to the layout of a 32 bit integer.
> Changing that now may lead to many unexpected bugs and clumsy fixes
> and workarounds (which would be a shame, the code so clean compared
> to some of the A4 code!). I also don't think there's any real reason
> why they would need to be changed: as long as you always refer to
> bits within a 32 bit integer and never treat it as though it's an
> array of 4 8 bit integers you're always safe.
True. At least for all 32-bit and 16-bit formats.
> Part of the reason we have a colour type is to hide all that
> confusion from the end user, and I would certainly appreciate Allegro
> taking care of any endianesse problems for me.
Seems that's impossible if we want to keep al_lock_bitmap or any other
direct access to our pixel data.
>
> I know, I'm finding them. :P
> I would personally prefer that ARGB8888 would translate into
> 0xAARRGGBB, in other words the machine's native 32 bit integer
> format. That's just a preference though and in the end of the day it
> doesn't matter either way, but it does need to be clear and there
> should never be any sort of ambiguity.
Since I guess you are the only big-endian user of A5 right now, we
should do that then. It also means the least work, you can simply apply
your original fix to the example. I'll put a note on the TODO that we
have to add a big-endian note to the documentation about it (i.e. forbid
byte-wise access like the example did).
> Allegro 4 had the makecol32() function partly for this reason.
> What would be the main reason the user needs to care about the byte
> ordering in a chunk of memory? The sample code in ex_lockbitmap? In
> that case a function that encodes a quartet of (A, R, G, B) and
> stores them in the indicated location in the buffer could hide the
> details from the end user.
Yes, maybe we should have a function which converts AL_COLOR to int, for
the formats where this is possible.
> There is also an alternative, but I don't have the birds-eye point of
> view at the moment to see whether this means more work or less:
> Allegro's internals stay as they are, treating 32 bit integers that
> represent a colour as 32 bit integers and using logical operators and
> bitshifts to extract the data. In other words, it means Allegro uses
> whatever the native endian encoding is (as it does now). When
> returning colour components to the user or recieving them from the
> user it communicates in terms of arrays where the first component is
> B, the second is G, the third R and the fourth A.
Yes, I think now it would not be too much work, al_lock_bitmap and
passing data to OpenGL are the only two places where Allegro needs to
actually know the bit positions of color components.
> If that's all your fix does, then cool. It's less work. If there are
> other places where Allegro would have to do such a conversion, it's
> more work.
No, leaving it as is is less work :) And thinking about it again, there
really is no ideal solution. If we return a pointer to pixel data, then
it's up to users to know how to access those data - we simply need to
tell them that the right way is to use 32-bit or 16-bit integers to
access them, and they can't make assumptions about byte positions or it
will break on the opposite endianness. If we change it like I originally
wanted, the same thing will apply, except that the byte order would be
the same on big endian systems - but then accessing it as bigger integer
types would not be portable in return.
--
Elias Pschernig <elias@xxxxxxxxxx>