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