http://source.winehq.org/git/wine.git?a=commit;h=fe0f0eb48a12e29af6a9e7407d4...
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.
Am Sonntag, 23. März 2008 17:12:51 schrieb Milan Kostić:
I recommend you to write a test for this to see how WineD3D should behave. Take a look at dlls/d3d9/tests/visual.c, function texture_transform_flags_test(). There are a lot of tests for this code already. The function is a bit messy unfortunately.
There are a few bug reports about regressions due to this patch. I fixed most of them already, but it seems that one bug is still remaining, which is the same as the one you're seeing.
Sorry Stefan but i'm prety new with Wine and for now don't understand many things:(, i'm test games for now and don't know how to test tests with wined3d. I tried to not remove any code from v0.9.58 utils.c, i'm just add mat[12] = mat[8] and mat[13] = mat[9] like this:
break; } } else { /* under directx the R/Z coord can be used for translation, under opengl we use the Q coord instead */ mat[12] = mat[8]; mat[13] = mat[9]; if(!calculatedCoords) { switch(coordtype) { case WINED3DDECLTYPE_FLOAT1:
With that water flowing and portals also works good for me.
-
Milan Kostić -
Stefan Dösinger