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

[Stefan Dösinger]

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.

d3dx9 has a few of those issues(and similar things like float vs double) that 
should be good for a search and replace job. I've fixed a few of those issues 
in wined3d and friends, but I'm sure more are remaining.

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.

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.

> 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 :-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20110731/8b68c1a1/attachment.pgp>