[PATCH 2/5] wined3d: Handle fog_start==fog_end with table fog(try 2)
stefan at codeweavers.com
Tue Jun 18 07:19:17 CDT 2013
-----BEGIN PGP SIGNED MESSAGE-----
Am 2013-06-18 09:12, schrieb Henri Verbeet:
> On 17 June 2013 22:53, Stefan Dösinger <stefan at codeweavers.com>
>> correctly with fixed function fog. Tested as usual on Geforce9
>> (OSX, Linux), Geforce7 (Linux), r300g, r600g, i965 (OSX), r200.
> Which of those is affected by the quirk? I think all of those
> except r200 should be able to do GLSL, but you say r200 is the only
> one that doesn't pass the tests.
All Linux drivers. The OSX drivers I tested get the special case right.
I don't know what exactly goes wrong on r200. My plan was to look at
this (why the quirk is needed in the first place, and why it doesn't
work) once more important Wine 1.6 business is done. The quirk works
with mfcfog.exe, but my tests behave as if start = 0.0 and end = 1.0,
no matter what values I set. Either there's some precision problem, or
a different state breaks the driver.
(That said, r200 has another regression documented in bug 21708 that I
have to look at.)
> You may be able to convince me that this is a good idea, but so far
> I don't think it's worth all the extra code.
My motivation is to make the tests pass on as many configurations as
I can deal with ARB in another way, by implementing the fog equation
myself instead of using #option ARB_fog_linear. That would throw
pre-sm2 hardware under the bus though.
GLSL is also lucky in the situation where fog_coord == start && start
== end. In that case the linear fog evaluates to NaN, but clamp(NaN,
0.0, 1.0) is 0.0, which afaics matches the spec. I don't know if that
is lucky wording of min() and max() or intentional. (Windows drivers
disagree if they should use the fragment color or fog color in that
case, but no windows driver uses a different color like black or pink)
>> #define WINED3D_ADAPTER_CAP_XYZRHW 0x00000001
>> #define WINED3D_ADAPTER_CAP_VS_CLIPPING 0x00000002
>> +#define WINED3D_ADAPTER_CAP_BROKEN_FOG 0x00000008
> Is this intentional?
No, good catch.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----
More information about the wine-devel