Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

[Michael Mc Donnell]

On Thu, May 26, 2011 at 1:14 PM, Joris Huizer <joris_huizer at yahoo.com> wrote:
> On 05/26/2011 10:33 AM, Michael Mc Donnell wrote:
>> I've added some more tests to see if I could make it fail. Microsoft's
>> UpdateSemantics is not very picky. I can't get it to return anything
>> but D3D_OK except for when I pass a null pointer. My implementation
>> follows this behavior except for two cases: it returns E_FAIL when
>> passing an undefined type and when the offset is not 4 byte aligned.
>> This is because the values are checked inside vertexdeclaration_init.
>> So Wine is stricter. I don't think that it is necessarily a problem
>> because applications that pass bogus declarations like those will
>> likely not work anyway. My own tests with a small interactive demo
>> show that in those cases the application will crash with an access
>> violation when it tries to re-draw the scene.
>
> I don't know whether it applies here, but if I understand correctly,
>  there have been cases before that Wine must not be stricter than Windows.
> Tthe reason is that a program may 'depend' on a function crashing (it having
> an exception caught in that case).
> In such a situation, Wine's version of the function not crashing would cause
> a code path being executed
>  that normally never is (causing incorrect behavior even)
>
> Again I don't know whether it is relevant in this cause.

Yeah I'd prefer it too to be 100% compatible. However, I think it is
highly unlikely that any programs depend on an exception being thrown
by EndScene in a drawing method. But you never know, some people do
crazy things :-) I think the current implementation is good enough as
long as there is no evidence of programs depending on that behavior.

The problem is that UpdateSemantics in the d3dx9 library depends on
d3d9 and the error code is generated by vertexdeclaration_init in
d3d9. That means d3d9 would have to be changed to make it less picky.
That might on the other hand break other things that depend on it
being picky (I haven't looked at the tests in d3d9).

I thought of managing an array of D3DVERTEXELEMENT9 in ID3DXMeshImpl
instead of a IDirect3DVertexDeclaration9, and then have
ID3DXMeshImpl_DrawSubset call IDirect3DDevice9_CreateVertexDeclaration
just before IDirect3DDevice9_SetVertexDeclaration. But that would not
solve the problem as it would just shift the bad call to
ID3DXMeshImpl_DrawSubset and not result in an exception in EndScene.
It would also result in a lot of extra calls depending on the number
of subsets. So I can't see any good way around modifying d3d9, but
that might cause other problems as mentioned earlier.

So to recapitulate, I think the best solution is to ignore that little
difference until we see programs that depend on it.

Michael Mc Donnell