Concerning the vertrd a picel shadet, the truth is that sin e very soon in the history of d3dx the functions ID3DXEffect::SetPixelShader and ID3DXEffect::DetVertexShader wete removed. So actually it does not seem that you can change them. Because of that, the MS implementation replies with D3DERR_INVALIDCALL and their implementation in SetValue is straight.<br><br>----- Reply message -----<br>De: "Rico Schüller" <kgbricola@web.de><br>Para: "Luis Carlos Busquets Pérez" <luis.busquets@ilidium.com><br>CC: <wine-devel@winehq.org><br>Asunto: ID3DXBaseEffect::SetValue<br>Fecha: mar., feb. 7, 2012 10:03<br><br><br>Am 07.02.2012 06:02, schrieb Luis Carlos Busquets Pérez:<br>> 1. If the functions returns E_FAIL for a sample then<br>>     test_effect.c:1917: Test failed: Got result 80004005, expected 0 (D3D_OK)<br>I'll have a look at those.<br>> 2. For D3DXPT_VERTEXSHADER and D3DXPT_PIXELSHADER replying with E_FAIL<br>> avoids<br>>    test_effect.c:1812: Test failed: Got result 0, expected 0x80004005<br>> (E_FAIL)<br>>    test_effect.c:1814: Test failed: Got result 0, expected 0x80004005<br>> (E_FAIL)<br>>    test_effect.c:1881: Test failed: Got result 0, expected 0x80004005<br>> (E_FAIL)<br>Sure, that's not implemented, yet. You should get a FIXME for those cases.<br>> 3. If the function just sets the memory with the data for a bool then<br>>     test_effect.c:969: Test failed: Got 46, expected 1<br>In this case it may be required, that the input has to be converted <br>before it is put into data. A solution would be to use Set*Array to set <br>the values. In general, I think it's also fine to convert the values in <br>get_int() and get_float() in the case of D3DXPT_BOOL with get_bool(data) <br>- I'll send a patch for this. But I also think a test to show, that the <br>value is converted while it is set, is still the way to go. Well <br>SetValue isn't complete, yet.<br>> 5. Concerning textures, the compiler does not accept arrays of textures,<br>> so any change to a texture type should be just a change of the pointer<br>> to the texture at param->data (or NULL)<br>I didn't got the point. Only that it is impossible to declare texture <br>arrays in effect files, which I could confirm.<br>Do you mean, that the HeapAlloc for the additional pointer for textures <br>should be avoided? This could be done, it just needs separate handling <br>for textures. As it is now, it mostly uses the same handling together <br>with the shaders (e.g. IUnknown_Release(*(IUnknown **)param->data)).<br><br>Cheers<br>Rico<br>