[PATCH 3/4] d3d9/tests: Add a test for signed formats.

Stefan Dösinger stefandoesinger at gmail.com
Tue Mar 3 05:36:06 CST 2015


2015-03-03 12:22 GMT+01:00 Matteo Bruni <matteo.mystral at gmail.com>:
> For the 8-bit format you mean that 1 is not representable in the
> signed u/v components, correct?
> Also "singed" typo, but otherwise good to me.
1 and -1 (the signed input value, not the post-scaled -1.0 and 1.0)
are missing from U and V, yeah. The reason is that this way I can
reuse the expected color array. Q in D3DFMT_Q8W8V8U8 tests some 8 bit
specific values. I'll see if I can clarify that comment a bit.

>> +        {0x4067, 0x53b9, 0x0421, 0xffff}, /* 0x4067, 0x53b9, 0x0421, 0xffff */
>> +        {0x8108, 0x0318, 0xc28c, 0x909c}, /* 0x8108, 0x0318, 0xc28c, 0x909c */
>> +    };
>
> What did you mean to put in the comments here? Those currently there
> match the actual content of the array.
I thought I removed those comments. It was a sort of backup of the
values while I experimented with the problem Geforce 7 cards have.

> This is clearly my brain failing right now, but why is blue expected
> to be 0xff when the texture component is missing?
All formats return 1.0 for channels that aren't defined by the format.
E.g. D3DFMT_G32R32F returns R, G, 1.0, 1.0. That differs from GL,
which returns 1.0 for alpha and 0.0 for color channels.

> Cool additional test for UpdateSurface, thank you for that.
> Here and in the previous test I guess you might want to put the
> slop_broken check into a broken(), unless that also fails on Linux.
I also think I fixed that before sending. I wonder if I forgot a git
commit --amend...



More information about the wine-devel mailing list