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 _
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
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,
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
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
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
> 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
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
> 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
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
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
> 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
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
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.
Victor Eremin <[EMAIL PROTECTED]> writes:
> +void mask_copy(DWORD srcMask, BYTE srcPixelSize,
> +DWORD dstMask, BYTE dstPixelSize,
> +BYTE *src, BYTE* dst, DWORD src_pitch, DWORD dst_pitch,
> +unsigned int w, unsigned int h){
> +unsigned int x, y;
> +BYTE i;
> +BY
On Wednesday 23 July 2008 21:48:59 Chris Robinson wrote:
> But extracting the mask offset and size from the actual mask takes a bit of
> time,
Extracting mask is called once or twice per channel conversion. I.e. in case
of converting a8r8g8b8->a1r5g5b5 mask should be calculated only 8 times, no
On Wednesday 23 July 2008 10:29:37 am Victor wrote:
> 0) initial patch used "mask size" + "mask offset", but was rewritten to use
> mask value when Stefan Dösinger requested that. I don't want to rewrite it
> back to use mask size + mask offset.
> 1) mask size and offset can be extracted from mask
On Wednesday 23 July 2008 21:18:57 Chris Robinson wrote:
> Maybe it would be better if the table was changed to have a bit offset and
> a mask size, instead of the actual mask.
0) initial patch used "mask size" + "mask offset", but was rewritten to use
mask value when Stefan Dösinger requested tha
On Wednesday 23 July 2008 09:10:02 am Stefan Dösinger wrote:
> The patch looks reasonably, just one small thing: There is a count_bits
> function implemented in utils.c, which as far as I can see does the same as
> getMaskSize. Can you check if you can reuse it?
Maybe it would be better if the tab
On Wednesday 23 July 2008 20:10:02 Stefan Dösinger wrote:
> Actually, one more idea:
>
> It will be extra-slow, but we could implement a general all-to-all format
> by converting the source format to A32R32G32B32F(float values), and then
> write code to convert this format to all possible destinati
PROTECTED] On Behalf Of Victor Eremin
> Sent: Wednesday, July 23, 2008 10:25 AM
> To: [EMAIL PROTECTED]
> Subject: wined3d: universal surface convertor function for unsigned
> integer color formats(3rd attempt)
>
>
> Supports conversion between most of "unsigned
Actually, one more idea:
It will be extra-slow, but we could implement a general all-to-all format by
converting the source format to A32R32G32B32F(float values), and then write
code to convert this format to all possible destination formats. The from->to
table lookup could be replaced by code
> It has been a couple of days since I've submitted patch. Patch still
> isn't in git. Will it be accepted? If not, what should be changed to
> make it "acceptable"?
I think the problem was that I forgot to reply to your mail.
I think the idea of using this as a fallback if no special conversion f
It has been a couple of days since I've submitted patch. Patch still isn't in
git. Will it be accepted? If not, what should be changed to make
it "acceptable"?
--
With best regards Victor Eremin ([EMAIL PROTECTED])
signature.asc
Description: This is a digitally signed message part.
On Thursday 17 July 2008 22:33:34 Stefan Dösinger wrote:
> How many different conversions do the two games need?
The games I've mentioned before use simple things like X8R8G8B8 to R5G6B5 or
X8R8G8B8 to R8G8B8. By using Google I didn't found much applications with
this particular FIXME (simcity3k
universal surface convertor function for unsigned
> integer color formats(2nd attempt)
>
>
> Supports conversion between most of "unsigned color" argb/xrgb surface
> formats (D3DFMT_A8R8G8B8, D3DFMT_A8R3G3B2, etc), and "luminosity" color
> formats (D3DFMT_L8, etc),
On Monday 14 July 2008 18:21:19 Stefan Dösinger wrote:
> There's a pixelformat table that describes bitmasks and sizes in utils.c,
> you can access it with a function that is next to it. I think you can infer
> the shifting information from this table, if not please add it there
> instead of creati
On Mon, Jul 14, 2008 at 02:51:42AM +0400, Victor Eremin wrote:
>
> Converter function supports conversion between most of
> "unsigned color" argb/xrgb surface formats (like D3DFMT_A8R8G8B8,
> D3DFMT_A8R3G3B2, and so on), and between "luminosity" color formats
> (D3DFMT_L8, etc), excluding D3DFMT_
nt: Sunday, July 13, 2008 5:52 PM
> To: [EMAIL PROTECTED]
> Subject: wined3d: universal surface convertor function for unsigned
> integer color formats
>
>
> Converter function supports conversion between most of "unsigned color"
> argb/xrgb surface formats (like D
29 matches
Mail list logo
