Victor ErV2005@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.
- 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.
- 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.