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