Michał Król wrote:
> José Fonseca pisze:
>> I found one other problem in the way we use 4 x 8bit color formats:
>> sometimes we interpret them as arithmetically coded in an unsigned (e.g
>> src/gallium/auxiliary/util/u_tile.c when reading/writing
>> color/depth/stencil buffers), sometimes we interpret them (e.g.
>> src/gallium/auxiliary/translate/translate_generic.c when reading/writing
>> vertex buffers). And these actually mean different things on
>> little-endian architectures.
>>
>>
> Some text is missing from the first sentence. I am guessing that
> sometimes we interpret them as an array of bytes, right?
>
>> I think the only viable option is to distinguish between these two kinds
>> in the cases where it is ambiguous, like
>>
>> PIPE_FORMAT_R8G8B8A8_UNORM /* a | ( b << 8) | (g << 8) | (r << 24) */
>> PIPE_FORMAT_RGBA8_UNORM /* {r, g, b, a} */
>>
>> Since there are legitimate uses in for both (color buffers, and vertex
>> buffers).
>>
>> Anybody has better ideas?
>>
>
> We should go with and stick to a single convention. I don't know, maybe
> for example this:
>
> A16R16G16B16
>
> The format description above would indicate that we are dealing with a
> 64-bit entity with bits being numbered from right to left. That would
> mean the B component occupies first 16 bits (bytes 0:1), the G component
> next 16 bits (bytes 2:3) and so on. Because there is no implied dword
> and encoding using shifts, we could easily write some code that decodes
> the format in a portable way across LE and BE architectures.
When I've worked on this stuff in the past, the convention I was
following was:
IF total pixels size <= 32 bits THEN
Treat the pixel as a uint, ushort or ubyte where the components
are listed in MSB to LSB order. Individual components are
accessed with bit shifts and masks.
ELSE
Components are listed in "array" order and accessed as an array.
It would be consistant to use the array style everywhere but that
doesn't really work for a format like RGB565 or Z24S8.
Note that this issue is similar to OpenGL's "regular" pixel types such
as GL_UNSIGNED_BYTE and GL_UNSIGNED_SHORT vs. the "packed" pixel types
such as GL_UNSIGNED_INT_8_8_8_8 and GL_UNSIGNED_SHORT_5_6_5.
-Brian
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
