d3dx9_36 [patch 5/5, try 3]: Implement D3DXSHEvalSphericalLight
Rico Schüller
kgbricola at web.de
Wed Oct 10 14:51:49 CDT 2012
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
More information about the wine-devel
mailing list