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

2008-07-30 Thread Victor
On Wednesday 30 July 2008 15:15:45 you wrote: > Am Mittwoch, den 30.07.2008, 15:03 +0400 schrieb Victor: > > > 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 _

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

2008-07-30 Thread Michael Karcher
Am Mittwoch, den 30.07.2008, 15:03 +0400 schrieb Victor: > > 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

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

2008-07-30 Thread Victor
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,

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

2008-07-29 Thread Victor
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. How it is supposed to be implemented inside pixel conversion loop? As separate per-pixel callbacks for fetching data? Or as switch()? The best

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

2008-07-29 Thread Alexandre Julliard
Victor <[EMAIL PROTECTED]> 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 sto

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

2008-07-29 Thread Victor
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

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

2008-07-29 Thread Stefan Dösinger
> 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. This defeats the point of a format-independent conversion function I think

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

2008-07-29 Thread Alexandre Julliard
Victor <[EMAIL PROTECTED]> writes: > I've changed things a bit and resubmitted patch. Now there will be less > ifdefs. Not much better I'm afraid. > I'm not sure which "data types" are you talking about, since I'll need > per-byte surface access in any case, and It doesn't look like it can be

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

2008-07-28 Thread Stefan Dosinger
> I've changed things a bit and resubmitted patch. Now there will be less > ifdefs. > I'm not sure which "data types" are you talking about, since I'll need > per-byte surface access in any case, and It doesn't look like it can be > wrapped into endianness-independant datatype. Maybe you could use

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

2008-07-28 Thread Victor
On Monday 28 July 2008 19:09:03 you wrote: > Victor <[EMAIL PROTECTED]> writes: > > Well, the last attempt (with added big-endian support) was submitted > > several days ago, and again - no feedback, and patch still isn't > > accepted. > > > > What's wrong with patch now? > > The big endian support

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

2008-07-28 Thread Alexandre Julliard
Victor <[EMAIL PROTECTED]> writes: > Well, the last attempt (with added big-endian support) was submitted several > days ago, and again - no feedback, and patch still isn't accepted. > > What's wrong with patch now? The big endian support makes things worse than before. You need to use the prope

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

2008-07-28 Thread Stefan Dösinger
> Well, the last attempt (with added big-endian support) was submitted several > days ago, and again - no feedback, and patch still isn't accepted. > What's wrong with patch now? Sorry, I must have missed this on Wine-patches again :-( It look ok to me. The endianess #ifdefs look strange, but I

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

2008-07-27 Thread Philip Nilsson
On Thu, Jul 24, 2008 at 08:14:40PM +0400, Victor Eremin wrote: > Supports conversion between most of "unsigned color" argb/xrgb > surface formats (D3DFMT_A8R8G8B8, D3DFMT_A8R3G3B2, etc), and > "luminosity" color formats (D3DFMT_L8, etc), > excluding D3DFMT_A16R16G16B16, D3DFMT_A8P8, D3DFMT_P8 and D

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

2008-07-27 Thread Victor
Well, the last attempt (with added big-endian support) was submitted several days ago, and again - no feedback, and patch still isn't accepted. What's wrong with patch now? --- Victor Eremin signature.asc Description: This is a digitally signed message part.