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 :-)