Re: wined3d: Correctly display fog for right-handed projection matrix (try 7)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, This one looks good to me. Am 2014-10-12 17:08, schrieb Joachim Priesner:
+ enum + { + COLOR_ALPHA_0x00 = 0x00000000, + COLOR_CLEAR = 0xffff00ff, + COLOR_FOGGED = 0x0000ff00, + COLOR_UNFOGGED = 0x00ff0000 + }; + + /* Fill the null-shader entry with the FVF (SetVertexShader is "overloaded" on d3d8). */ + DWORD vertex_shader[3] = {D3DFVF_XYZ | D3DFVF_DIFFUSE | D3DFVF_SPECULAR, 0, 0}; Do you need the specular color on Windows as well, or to make this work right on Wine? I suspect that the NONE/NONE test doesn't work right on Wine because we do not set a controlled fog coordinate in wined3d/state.c, load_vertex_data(), in the case where WINED3D_FFP_SPECULAR is absent and similarly in drawprim.c, drawStridedSlow().
In either case that's no reason to hold up this patch any longer IMHO. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJUOp0lAAoJEN0/YqbEcdMwgD4P/iLeSfFbE/jEsJ+Yux1lR9PC FDoJ50dxiedieOJWl4TbvIgr5uNyXnBm9YtPiiLgZJNfwoJ2znYjYDsA4h2yZ8FU lrgHwWcAo1ZvlPS0QolSYfx7QH4TpGIKklfEr7Qe4LQgftJjHNGioDuK1zpT+E3e JjcZOXDKjOP4ACNu5awEBq9v427TxOT9E+GJQWrq/cxbCYRbDurFwuFS2Jb1o/j+ 9zEoy8qiaQ+6v0j8+RcAkBTMdg6DBwSOYsH7P/KjrnzUkj+yH1w+R9dcnHMdaeMP RRoJSLsGzfANXF05vn7vE5Q5QzOjhXtIWWL/yun/IAL/EofZrXyVikoGP28wxUV1 QBICfDUvel4dhnYxNzNGUMQXC7gaXmJI3q12gemhkX4vj2W/FxVIaSN7vr5j+5rp 2ijdi9rexyBopbDM/9ay599GSNjXrTljkv8sEH23JMIpKR2BP7afyih6Hta9e/zf Ao9LtFwyBye2F9HTyM9G10MBrnVdNIKhJ9ZY30bRhomtXrfP1HuRvvpfRPja9gjZ M/aiwqPM6a3vfdJ/kIOra72vNZAoE9ccEOuDPQqMhg2ccoYvLUg6+LGvKRLanmOO lCsKiFYUChwJlebbo98+bfhMiR7TBI5fkwXOxR4coDu9jIl1oP2GblaL5Sul+zg1 rXbnkL2Pltlb/ZaW33l0 =Ozzv -----END PGP SIGNATURE-----
Am Sonntag, 12. Oktober 2014 schrieb Stefan Dösinger:
Do you need the specular color on Windows as well, or to make this work right on Wine? I suspect that the NONE/NONE test doesn't work right on Wine because we do not set a controlled fog coordinate in wined3d/state.c, load_vertex_data(), in the case where WINED3D_FFP_SPECULAR is absent and similarly in drawprim.c, drawStridedSlow().
I need this only on Wine. I figured that even if this is a bug in Wine (which by definition it is, as Windows is always right(?)), fixing it would be ouf of scope for this patch.
In either case that's no reason to hold up this patch any longer IMHO.
:-)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-10-12 17:35, schrieb Joachim Priesner: (which by definition it is, as Windows is always right(?)) This is the general rule, yes. It gets more difficult when something works sometimes on Windows and applications still do it, and sometimes break on Windows, but break more often on Wine. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJUOqB0AAoJEN0/YqbEcdMwHFcP/iNl+O6hj2cyHkEmM9PxYM3L 9PMmcZYNUPvFtHmb+oKvJL41TQi1wq7mxNZI+zRAtzSkF5OiiaVk/lihqPclB+o1 YOXowPz87Cw+ucYGlc+hpyJxcoIl0r7A4nKfB6zHh9IjMmvPUGMYnJSlNdFYK2V8 A5/m8Gen/NQ724WtQ0oiiwEGxdj8mj2oEG/Q+d87sUZhlnD59rDd+pmpW9ADqsoT 4CVT7F6+388GNCIu8CRqDp1uHuL9KGajst0KQWWf8zYKFnjFJwOwq+t4DKwOhMzY UM7z91ybdq+nVAZgxl6YL08hjbSYXoyF/ekuoalslE5nBN0J/W6rMSQ1iuBIKT9K Fu5zgU0sMQUnoE/DDCpKlUIzYK1Bsco7Saf8V36oKOZOecyT3ctyIZ3ulwX3dUt5 3IWlbi0rOJQD7wRjlN1YQvnhmSAun1Y4UcViKwlsJo1VmTaA3x1i2lTx30gnPh60 R13i8WLkxuMw9LtBxYUEYmeJfTpZIBdh1xYjl7aiK5ZM0JL8cSIcjmMHvEWLcmRr W3kNIvNAgKgVEjTIZ58b6gO5jaD3NvbVlNP7BADGr2FPiy21YBtLR/KavXA5h7FC m1SFtw9M38q5tuRfWH+fJYmFO21VeLpmvYzOUMu55vxQ1p4RCeIrMF3K3jBfQWxj DOXu0iT8PkB1xNm3Nsfb =l4LT -----END PGP SIGNATURE-----
On 12 October 2014 17:24, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote:
In either case that's no reason to hold up this patch any longer IMHO.
But the tests still fail to distinguish between taking the absolute of ec_pos.z in shader_glsl_generate_ffp_vertex_shader() and taking the absolute of gl_FogFragCoord in shader_glsl_generate_fog_code(), of course.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-10-13 17:14, schrieb Henri Verbeet:
But the tests still fail to distinguish between taking the absolute of ec_pos.z in shader_glsl_generate_ffp_vertex_shader() and taking the absolute of gl_FogFragCoord in shader_glsl_generate_fog_code(), of course. Right, how could I miss this.
Joachim, I think a way to test this would be to generate a fog gradient from -1 to 1 in the fixed function pipeline codepath, set the Z coordinate to 0 in the projection matrix to prevent clipping and checking the fog value between the vertices at x=320. If the absolute value is taken before the interpolation this will result in a fogged pixel. If it is taken after the interpolation, it will result in an unfogged pixel. As a side effect this should also test the clamp(0.0, 1.0) behavior of the oFog vertex shader output. If the vertex shader side clamp is correct it'll result in a half fogged middle. We already know vertex shaders don't do an abs() like the fixed function pipeline, otherwise both sides of vs=2, tfog=none would be unfogged. If the clamp is incorrect this would result in fogged on the left, fogged in the middle, unfogged on the right (and half fogged at x=480). A third way negative fog coordinates could enter the fog calculation is a pretransformed vertex with z < 0 combined with table fog. If the depth test is off clipping is disabled (zenable_test) . -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJUO/hAAAoJEN0/YqbEcdMwWEgP/0eqNjqDK+b2oAFZ+egFB2Eg Lflq+62wtuhlL54EeTBZGajXCp7qFEEBqmG74BLG3se0ukylX19AqlwlukfHWFz8 9zVDBXXt19+Zfp5S7IjwlXIi3YaZkey9bvI/pVfIqlu5ytiL/RonNWobLz1PkR+i M2JpbVLUPm/9f6XBRlwxsKy2a7vY9d1n0nTLHM2Tkc8guJ9mMrJswEr/+sDkRZyv Jt2zDw23yvhYPvKAzlkEWoD+0HLIwvdOt2t5cBQv6V6RQhdwSb+wAAiOeyXrsWxd EAbFegpH7/xZx28cXlBQP+yywtS9pG7IM+33TXxdAQMyAoagH0oAnwMOLYj1Jhqg gZqijd26eflNfk2oKLe8/8azs6mUAANQsOrLMRbksZ/VowrgjeUCwQ8gZGBNiFpd htTrUhb4bXY9TZnrhvn2q9gKEdG9/0LfVIvXXqkDvSk6+kPqNYtBRJhzcFWbq9vm TF9oz8vjkp9ElV7T7X+yBbdoxtKgQmRyRN29yngAGMoSEd2uE+C3Zek5Yn1ZqA1X Va0epOl+CG2ixNChm6JbGsTy1kPZM8LwP5VseEeIz0HmTlBk/Gwj71ofIxtaVrbe VAiwM/iW5mUoiOkO1x0Vb6W5OE4NHBHv9kRBkyKK6bC3xgB7tZqGtWdQ58crlvIF /7OMRja2RliIOEzyZBGS =M3Mi -----END PGP SIGNATURE-----
Hi Stefan, thanks for your continuing help on this issue.
Joachim, I think a way to test this would be to generate a fog gradient from -1 to 1 in the fixed function pipeline codepath, set the Z coordinate to 0 in the projection matrix to prevent clipping and checking the fog value between the vertices at x=320. If the absolute value is taken before the interpolation this will result in a fogged pixel. If it is taken after the interpolation, it will result in an unfogged pixel.
Setting z=0 in the projection matrix (matrix[2][2] = 0) seems to lead to problems on Windows. As Windows uses the projection matrix to calculate w-based fog, all vertices will have a fog coordinate of 0. My proposal would be to keep the identity projection matrix and test only vertex fog, not pixel fog. The left half of the image will be clipped because the z coordinates are negative in this area, but the color is still calculated for each vertex and is interpolated. This test would still detect the issue I'm trying to fix. However, it would not be possible to test pixel fog with negative z coordinates that way. What do you think? Joachim
Am 18.10.2014 16:30 schrieb "Joachim Priesner"
Setting z=0 in the projection matrix (matrix[2][2] = 0) seems to lead to problems on Windows. As Windows uses the projection matrix to calculate w-based fog, all vertices will have a fog coordinate of 0.
I don't have the docs or Wine code available right now to look up how w fog works (yeah, we have some tests for that). Can you use matrix[2][3] to set z=1 or something?
My proposal would be to keep the identity projection matrix and test only vertex fog, not pixel fog. The left half of the image will be clipped because the z coordinates are negative in this area, but the color is still calculated for each vertex and is interpolated. This test would still detect the issue I'm trying to fix. However, it would not be possible to test pixel fog with negative z coordinates that way. What do you think?
Since vertex fog is supposed to be calculated per vertex the only possible answer to where the abs() happens is in the vertex pipeline. There may be surprises though. Why doesn't table fog work? I'd expect the fog corrdinate to be interpolated separately from the z coordinate, so you still get an interpolation from abs_maybe(-1.0) to 1.0, even if only half the quad is drawn.
participants (3)
-
Henri Verbeet -
Joachim Priesner -
Stefan Dösinger