From: Elizabeth Figura zfigura@codeweavers.com
This reverts commit ed62b8bf30ac926ae100eee42fee3f6ceb8541e2.
GL_TRUE here signifies that the matrix is in row-major storage, and we do indeed pass it in row-major order here (like other d3d matrices).
The problem is that this matrix, like other d3d matrices, is not only row-major in storage, it also uses what Sean Middleditch [1] calls "row-major notation". Contrary to GL, Vulkan, and almost the entire world of mathematics, Direct3D matrices have the *column* in their first component.
A matrix which is row-major in both storage and notation is effectively identical, at least in storage order, to one which is column-major in both storage and notation, as here. That is, it should *not* be transposed.
Adding to the confusion is the fact that, as mentioned by the commit being reverted (as well as texbem_test() in d3d9:visual), some drivers get this wrong too, and transpose the matrix. I originally thought that NVidia was broken, but it turns out that AMD is the one in the wrong here, at least for the BEM and TEXBEM(L) shader instructions. Incidentally, WARP incorrectly transposes the matrix for TEXBEM(L) but not for BEM.
This fixes test failures in texbem_test() and fixed_function_bumpmap_test().
[1] https://web.archive.org/web/20180419095941/http://seanmiddleditch.com/matric... --- dlls/wined3d/glsl_shader.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dlls/wined3d/glsl_shader.c b/dlls/wined3d/glsl_shader.c index c0071dcdfaa..e7b1d817314 100644 --- a/dlls/wined3d/glsl_shader.c +++ b/dlls/wined3d/glsl_shader.c @@ -1954,7 +1954,7 @@ static void shader_glsl_load_constants(struct shader_glsl_priv *priv, if (prog->ps.bumpenv_mat_location[i] == -1) continue;
- GL_EXTCALL(glUniformMatrix2fv(prog->ps.bumpenv_mat_location[i], 1, GL_TRUE, + GL_EXTCALL(glUniformMatrix2fv(prog->ps.bumpenv_mat_location[i], 1, GL_FALSE, &constants->bumpenv.matrices[i]._00));
if (prog->ps.bumpenv_lum_scale_location[i] != -1)