d3dx9_36 [patch 5/5, try 3]: Implement D3DXSHEvalSphericalLight

[Rico Schüller]

On 10.10.2012 09:49, Nozomi Kodama wrote:
> math.c:2994: Test failed: Red: case 9, order 7: expected[10] = 0.000000,
> received -134495294795062701298349336420239278080.000000
> math.c:2994: Test failed: Red: case 9, order 7: expected[15] = 0.000000,
> received -131556728585661638158151798785793064960.000000
But the values are different each time? So no app could depend on the 
returned values? Does this implementation return the same values? Is 
everyone else ok with accessing the array out of bounds?

>
> +    for (i = 0; i < order ; i++)
>
> +        scale = cap[i] * coeff[i];
>
> +        for (order = D3DXSH_MINORDER ; order <= D3DXSH_MAXORDER; order++)
Spaces. These are also in the D3DXSHEvalConeLight patch.

Is there a point against using the same coeff variables in 
D3DXSHEvalConeLight and D3DXSHEvalSphericalLight? Maybe they should be 
static or the capintegral simply should integrate the multiplication if 
the capintegral function is only used in these two functions. I think 
there is no need to add the same variables twice.

 > +        2.0f * sqrtf(D3DX_PI / 7.0f), 2.0f / 3.0f * sqrtf(D3DX_PI), 
2.0f * sqrt (D3DX_PI / 11.0f) };
sqrtf .... These are also in the D3DXSHEvalConeLight patch. Does the 
compiler optimize the function call away to a constant value? If not it 
may be better to use something like 1.7724538509f for sqrtf(pi)...

Cheers
Rico