On Tuesday 29 July 2008 21:54:36 you wrote:
Obviously not, 1-byte formats should be read as bytes, 2-byte format as WORDs, and 4-byte format as DWORDs.
This will require several nearly identical read functions, or callbacks which means either code duplication or slowdown within Blt function, which isn't good idia, IMHO.
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.
I"ve resubmitted patch and removed accessing DWORDs as bytes where it was possible (it was possible only in one place, actually). Accessing DWORD mask as array of bytes is required by algorithm. Accessing everything as DWORD is not possible, because, for example, accessing last pixel of r8g8b8 as DWORD will cause segfault, unless there is one additional byte available due to the surface alignment. Making several different functions which will read 1/2/3/4 bytes seems clumsy/pointless to me.
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.
Conversion process for every channel is identical, and calling several if's for every pixel doesn't look like good idea (code duplication/slowdown). That's why surface is walked several times. Also, generic per-channel functions allows to add support for other formats later.
You also have to expand types properly, i.e. converting a component from 4-bit to 8-bit isn't just a shift.
In all places where I saw pixel format conversion before, it was _always_ done by shifting components (even in MS-DOS vesa-based applications). Your assumption that "converting isn't just a shift" requires link to official documentation (i.e. proof), where it is clearly stated that during Blt() (from which convert_unsigned_pixels is being called) between different surface format, ddraw/d3d converts pixel format by means other than simply shifting components. I doubt that in real software ddraw implementation blt from 565 to 888 is done by completely recalculating components using floating point operations.