[PATCH] WineD3D: Remove an unneeded atifs hack=0A=

Stefan Doesinger stefan at codeweavers.com
Tue Jul 1 17:18:29 CDT 2008


=0A=
The atifs fragment processing implementation doesn't borrow a pixel =
shader=0A=
implementation from anywhere. It was a hack during development, but =
never needed=0A=
---=0A=
 dlls/wined3d/ati_fragment_shader.c |   13 -------------=0A=
 1 files changed, 0 insertions(+), 13 deletions(-)=0A=
=0A=
diff --git a/dlls/wined3d/ati_fragment_shader.c =
b/dlls/wined3d/ati_fragment_shader.c=0A=
index e722f05..99f1fd4 100644=0A=
--- a/dlls/wined3d/ati_fragment_shader.c=0A=
+++ b/dlls/wined3d/ati_fragment_shader.c=0A=
@@ -850,19 +850,6 @@ static void set_bumpmat(DWORD state, =
IWineD3DStateBlockImpl *stateblock, WineD3D=0A=
     mat[1][1] =3D (mat[1][1] + 1.0) * 0.5;=0A=
     =
GL_EXTCALL(glSetFragmentShaderConstantATI(ATI_FFP_CONST_BUMPMAT(stage), =
(float *) mat));=0A=
     =
checkGLcall("glSetFragmentShaderConstantATI(ATI_FFP_CONST_BUMPMAT(stage),=
 mat)");=0A=
-=0A=
-    /* FIXME: This should go away=0A=
-     * This is currently needed because atifs borrows a pixel shader =
implementation=0A=
-     * from somewhere else, but consumes bump map matrix change events. =
The other pixel=0A=
-     * shader implementation may need notification about the change to =
update the texbem=0A=
-     * constants. Once ATIFS supports real shaders on its own, and =
GLSL/ARB have a replacement=0A=
-     * pipeline this call can go away=0A=
-     *=0A=
-     * FIXME2: Even considering this workaround calling FFPStateTable =
directly isn't nice=0A=
-     * as well. Better would be to call the model's table we inherit =
from, but currently=0A=
-     * it is always the FFP table, and as soon as this changes we can =
remove the call anyway=0A=
-     */=0A=
-    FFPStateTable[state].apply(state, stateblock, context);=0A=
 }=0A=
 #undef GLINFO_LOCATION=0A=
 =0A=
-- =0A=
1.5.4.5=0A=
=0A=

------=_NextPart_000_0061_01C8E026.A091FC00--




More information about the wine-patches mailing list