Re: ID3DXBaseEffect::SetValue

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.

----- Reply message -----
De: "Rico Schüller" 
Para: "Luis Carlos Busquets Pérez" 
CC: 
Asunto: ID3DXBaseEffect::SetValue
Fecha: mar., feb. 7, 2012 10:03

Am 07.02.2012 06:02, schrieb Luis Carlos Busquets Pérez:
> - If the functions returns E_FAIL for a sample then
>  test_effect.c:1917: Test failed: Got result 80004005, expected 0 (D3D_OK)

I'll have a look at those.
> - For D3DXPT_VERTEXSHADER and D3DXPT_PIXELSHADER replying with E_FAIL
>
> avoids
>    test_effect.c:1812: Test failed: Got result 0, expected 0x80004005
> (E_FAIL)
>    test_effect.c:1814: Test failed: Got result 0, expected 0x80004005
> (E_FAIL)
>    test_effect.c:1881: Test failed: Got result 0, expected 0x80004005
> (E_FAIL)

Sure, that's not implemented, yet. You should get a FIXME for those cases.
> - If the function just sets the memory with the data for a bool then
>  test_effect.c:969: Test failed: Got 46, expected 1

In this case it may be required, that the input has to be converted 
before it is put into data. A solution would be to use Set*Array to set 
the values. In general, I think it's also fine to convert the values in 
get_int() and get_float() in the case of D3DXPT_BOOL with get_bool(data) 
- I'll send a patch for this. But I also think a test to show, that the 
value is converted while it is set, is still the way to go. Well 
SetValue isn't complete, yet.
> - Concerning textures, the compiler does not accept arrays of textures,
>
> so any change to a texture type should be just a change of the pointer
> to the texture at param->data (or NULL)

I didn't got the point. Only that it is impossible to declare texture 
arrays in effect files, which I could confirm.
Do you mean, that the HeapAlloc for the additional pointer for textures 
should be avoided? This could be done, it just needs separate handling 
for textures. As it is now, it mostly uses the same handling together 
with the shaders (e.g. IUnknown_Release(*(IUnknown **)param->data)).

Cheers
Rico