[PATCH 02/10] d3dx9/tests: Add test for effect parameter block.

[Paul Gofman]

On 11/12/19 21:50, Matteo Bruni wrote:
> On Thu, Nov 7, 2019 at 10:18 PM Paul Gofman <gofmanp at gmail.com> wrote:
>
>> +    /* Child parameters and array members are recorded separately (the whole parameter is not
>> +     * updated when parameter block is applied).
>> +     * Setting the same float value does not affect dirty state, but parameter is still
>> +     * recorded to parameter block.
>> +     * Setting shared parameter through effect2 is not recorded to effect parameter block. */
>> +    hr = effect->lpVtbl->SetFloat(effect, "arr2[0]", 92.0f);
>> +    ok(hr == D3D_OK, "Got unexpected hr %#x.\n", hr);
>> +    hr = effect->lpVtbl->SetFloat(effect, "ts1[0].fv", 28.0f);
>> +    ok(hr == D3D_OK, "Got unexpected hr %#x.\n", hr);
>> +    float_array[0] = -29.0f;
>> +    hr = effect->lpVtbl->SetFloatArray(effect, "ts1[0].v2", float_array, 1);
>> +    ok(hr == D3D_OK, "Got unexpected hr %#x.\n", hr);
> That reminds me of something maybe worth testing: I couldn't manage to
> have SetArrayRange() ever do anything. Maybe it actually does
> something with parameter blocks? Not holding my breath for that...
SetArrayRange() is currently not implemented, so involving it in
parameters block test would make things very complicated for testing
parameters blocks. Should not that testing go separately, if we decide
to implement SetArrayRange()? I did not encounter an app using it so far.
>
>> +    /* Object reference is not increased when object gets to parameter block
>> +     * but is also not lost when object is reset in effect parameter.
>> +     * Maybe native d3dx is using some copy on write strategy. */
>> +    IDirect3DTexture9_AddRef(texture);
>> +    refcount = IDirect3DTexture9_Release(texture);
>> +    ok(refcount == 2, "Got unexpected refcount %u.\n", refcount);
> Or stuff might just break if the texture is released while still in a
> parameter block. It should be possible to test it.


The test shows that native d3dx is not loosing reference when the
texture is left in the parameter block only. Do you mean additionally
testing a specific case deleting parameter block with texture still set
to effect parameter? In case it will really loose it, I suggest to still
keep the reference in our implementation.