2015-10-05 11:49 GMT+02:00 Henri Verbeet hverbeet@gmail.com:
On 2 October 2015 at 14:54, Matteo Bruni mbruni@codeweavers.com wrote:
@@ -4998,7 +4996,22 @@ static GLuint generate_param_reorder_function(struct shader_glsl_priv *priv, output->register_idx, reg_mask[1]); } }
shader_addline(buffer, "}\n");
for (i = 0; i < MAX_TEXTURES; ++i)
{
if (ps && !(ps->reg_maps.texcoord & (1u << i)))
continue;
if (texcoords_written_mask[i] != WINED3DSP_WRITEMASK_ALL)
{
if (gl_info->limits.glsl_varyings < wined3d_max_compat_varyings(gl_info)
&& !texcoords_written_mask[i])
continue;
shader_glsl_write_mask_to_str(~texcoords_written_mask[i] & WINED3DSP_WRITEMASK_ALL, reg_mask);
shader_addline(buffer, "gl_TexCoord[%u]%s = vec4(0.0)%s;\n", i, reg_mask, reg_mask);
}
} else {}
Doesn't this end up writing 0.0 to .w instead of 1.0? IIRC unwritten texture coordinates are assumed to be (0, 0, 0, 1) in D3D. May apply to the previous patch in the series as well.
My test (which is still a few patches ahead in the series but I can send you somewhere) shows that on Nvidia the texture coordinate defaults to (0, 0, 0, 0), while on AMD it defaults to (0, 0, 0, 1), so the value of the .w component probably doesn't matter much. Assuming the test is correct, of course...