-----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.
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.
On 12 October 2014 17:24, Stefan Dösinger stefandoesinger@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) .
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.
-
Henri Verbeet -
Joachim Priesner -
Stefan Dösinger