Regression introduced with one old Dösinger's commit

[Milan Kostić]

http://source.winehq.org/git/wine.git?a=commit;h=fe0f0eb48a12e29af6a9e7407d4eec8bc500a057

 OK this is that commit with problem, but don't know what is corect
solution... i just remove it back and all my problems with water
flowing ine games is gone:). Problem is with changes just in utils.c
file and that is not working properly with Mesa drivers that i use (i
don't know for other drivers). Primer: water flow, wrong animation in
portals, etc in Dungeon Siege 2 and all other games with
similar functions.

 I'm just revert minus lines and remove plus:):

-        mat[12] = mat[8];
-        mat[13] = mat[9];
+        switch(coordtype) {
+            case WINED3DDECLTYPE_FLOAT1:
+                /* Direct3D passes the default 1.0 in the 2nd coord,
while gl passes it in the 4th.
+                 * swap 2nd and 4th coord. No need to store the value
of mat[12] in mat[4] because
+                 * the input value to the transformation will be 0,
so the matrix value is irrelevant
+                 */
+                mat[12] = mat[4];
+                mat[13] = mat[5];
+                mat[14] = mat[6];
+                mat[15] = mat[7];
+                break;
+            case WINED3DDECLTYPE_FLOAT2:
+                /* See above, just 3rd and 4th coord
+                 */
+                mat[12] = mat[8];
+                mat[13] = mat[9];
+                mat[14] = mat[10];
+                mat[15] = mat[11];
+                break;
+            case WINED3DDECLTYPE_FLOAT3: /* Opengl defaults match dx
defaults */
+            case WINED3DDECLTYPE_FLOAT4: /* No defaults apply, all
app defined */
+
+            /* This is to prevent swaping the matrix lines and put
the default 4th coord = 1.0
+             * into a bad place. The division elimination below will
apply to make sure the
+             * 1.0 doesn't do anything bad. The caller will set this
value if the stride is 0
+             */
+            case WINED3DDECLTYPE_UNUSED: /* No texture coords,
0/0/0/1 defaults are passed */
+                break;
+            default:
+                FIXME("Unexpected fixed function texture coord input\n");
+        }
+        switch (flags & ~WINED3DTTFF_PROJECTED) {
+            /* case WINED3DTTFF_COUNT1: Won't ever get here */
+            case WINED3DTTFF_COUNT2: mat[2] = mat[6] = mat[10] = mat[14] = 0;
+            /* OpenGL divides the first 3 vertex coord by the 4th by default,
+             * which is essentially the same as D3DTTFF_PROJECTED.
Make sure that
+             * the 4th coord evaluates to 1.0 to eliminate that.
+             *
+             * If the fixed function pipeline is used, the 4th value
remains unused,
+             * so there is no danger in doing this. With vertex
shaders we have a
+             * problem. Should an app hit that problem, the code here
would have to
+             * check for pixel shaders, and the shader has to undo
the default gl divide.
+             *
+             * A more serious problem occurs if the app passes 4
coordinates in, and the
+             * 4th is != 1.0(opengl default). This would have to be
fixed in drawStridedSlow
+             * or a replacement shader
+             */
+            default: mat[3] = mat[7] = mat[11] = 0; mat[15] = 1;
+        }

 and all problems with water animation is gone. Seems to any other
games not have problems with that i do, but i don't know is this
correct? Maybe someone of the developers knows better solution for
this?

 edit: this is tried in wine-0.9.58, Mesa versions 6.52, 7.0, 7.01,
7.02, 7.03rc2 (no problem with all this Mesas) and ATI 9250(r200) and
also ATI 9800(r300) cards.