wined3d: universal surface convertor function for unsigned integer color formats(5th attempt)

[Alexandre Julliard]

Victor <ErV2005 at rambler.ru> writes:

> On Tuesday 29 July 2008 12:21:23 you wrote:
>> No, you shouldn't be accessing the surface per byte either, the access
>> should depend on the format, i.e. for a 32-bit format you want to access
>> DWORD by DWORD.
> 1) As I understand, surface data should be stored in same way on both 
> big/little endian platforms, so for rgb8 blue compes first, then goes green, 
> then red, no matter which endianness. I think so because when windows program 
> access surface data it, data is supposed to be in same format, no matter how 
> program accesses it - by reading bytes, dwords and words. In this way 
> accessing r5g6b5 as dword/word on big-endian machine, will require 
> byte-swapping, otherwise middle channel will be split in two parts. I do not 
> have access to big-endian platform, so I can't check if that is true, and how 
> exactly surface data is stored on big-endian platform. 
>
> 2) Pixel formats have different sizes - 1..4 bytes. Reading 1-byte or 3-byte 
> data as dwords doesn't look right. 

Obviously not, 1-byte formats should be read as bytes, 2-byte format as
WORDs, and 4-byte format as DWORDs. That's of course only if the data is
supposed to be swapped on big-endian; if you assume that the data is
always little-endian then you read byte by byte and rebuild DWORDs from
that. Either way you don't access a DWORD mask as an array of bytes.

You also need to do this in a single pass, it's silly to go through the
data 5 times, you should handle each pixel completely before moving on
to the next. You also have to expand types properly, i.e. converting a
component from 4-bit to 8-bit isn't just a shift.

-- 
Alexandre Julliard
julliard at winehq.org