Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

[Michael Mc Donnell]

On Sun, Jul 31, 2011 at 8:12 PM, Stefan Dösinger <stefandoesinger at gmx.at> wrote:
> On Sunday 31 July 2011 12:02:35 Michael Mc Donnell wrote:
>> I figured out how to do the conversion using bit-fields. I've updated
>> the patch to include a test and implementation of UDEC3 and DEC3N
>> welding.
>
> Nice, I was just about to reply not to bother too much about it. No Windows
> driver I know of supports those formats. Wined3d doesn't implement them
> either.
>
> With the bitfields I'm not sure about stuff like endianess. My gut feeling
> would be to use bitmasks and shifts to separate a DWORD instead, but bitfields
> certainly look nicer. Beyond that endianess is a somewhat academic
> consideration with an API that's available on x86 only. So I'd say keep the
> bitfields.

Ok good. That'll keep me from the pain of doing bit twiddling on a
little endian machine :-)

> On Saturday 30 July 2011 14:13:00 Michael Mc Donnell wrote:
>> I've implemented D3DCOLOR welding as UBYTE4N welding as you described.
>> Test 14 improves the color comparison to check that it is correct.
>
>> +static BOOL weld_short4(void *to, void *from, float epsilon)
>> ...
>> SHORT truncated_epsilon = epsilon;
> This will cause a precision loss warning on msvc. Adding a cast should do.

Ok. I've also added casts for the other types.

> Some nitpicking: struct D3DXWELDEPSILONS uses "FLOAT" not "float". It is
> advised to stick to the API types. This is quite academic since a "F+static
> BOOL weld_short4(void *to, void *from, float epsilon)
> LOAT" is afaik just a typedef for "float", but it helps when porting Wine to
> different CPUs. I think we had problems with LONG vs long on amd64 because
> win32 uses 32 bit LONGs or something like that.

Ok I hadn't thought about portability. I've changed float to FLOAT,
int to INT and unsigned int to UINT.

>> I've also added tests 25 and 27 for color usage index larger than 1.
>> The usage index is not capped like TEXCOORD > 7. It instead uses the
>> default value of 1e-6f. I've changed the implementation so it uses the
>> default value instead of printing out an error message.
> That's interesting. I wonder what those people in Redmond are smoking :-)

He he yeah I found that quite odd too :-)

Btw. I just noticed I have 1e-6 as a value by itself in
get_component_epsilon and as a constant DEFAULT_EPSILON in
D3DXWeldVertices. Would it be ok if I move the constant to
d3dx9_36_private.h or is that header file meant for something else?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-d3dx9-Implemented-D3DXWeldVertices-and-test.patch
Type: text/x-patch
Size: 104664 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20110801/9b8c66a4/attachment-0001.bin>