wined3d: universal surface convertor function for unsigned integer color formats(5th attempt)
Victor
ErV2005 at rambler.ru
Tue Jul 29 12:28:19 CDT 2008
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.
3) And I agree that this completely defeats purpose of the function.
4) There will be ifdefs anyway. Especially if assumption in #1 is true, then
each value will require byte-swapping, at least.
This won't work and I've already thought about accessing data as DWORDs, it
doesn't look reasonable.
My suggestion is to accept patch as it is, until someone with access to
big-endian machine will change it to be more elegant (although I don't see
any way to do this).
--
Виктор Ерёмин (ErV2005 at rambler.ru)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: This is a digitally signed message part.
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20080729/ef74f946/attachment.pgp
More information about the wine-devel
mailing list