d3dx9_36: Implement D3DXSHRotate
kgbricola at web.de
Mon Sep 3 02:11:37 CDT 2012
On 02.09.2012 23:46, Nozomi Kodama wrote:
> For instance, D3DXSHAdd and D3DXSHDot accept order>D3DXSH_MAXORDER. So
> we must check whether it is acceptable for other D3DXSH functions to
> give such an order. If it is not acceptable, then we must know what the
> function returns.
Yes, they do and I agree with you. But why do you chose to try from 0 to
9 (<10) instead of 0-7 (<8) - which I think is enough and nothing more
changes? (It includes the first round of not touched values.) Asking the
other way around, why don't you try lets say till 1000? I guess the easy
answer is, because the output values won't be touched for orders >6. The
test results show the same for the tests 7-9 (and would til 1000) and
thus testing for 7 is enough, testing 8 and 9 brings no new information,
beside you would miss to test from 10 to open end.
> For the out of bound problem, I agree that we reach an out of bound. But
> it is not a problem, since for such an index, expected is defined by an
> other value.
> If there is a complaining compiler about this, I can modify the tests
I'm not sure if the compiler is complaining, but I think it's much
better to set it in the else case. You may get an unhandled exception
and this is not what the software should do in the first place, it
should run and not produce exceptions! :-)
The same is done in test_D3DXSHRotateZ, which I'm not happy about it.
More information about the wine-devel