Now this code works because it correctly does his job for other values but with this vector:
0.000000f, 0.00000f, -0.1000000f
it does not work.
I have tried to not divide when both length is zero or the vec attribute is zero but still that error.
by the way could you try to avoid "double" ? using it will compute in a software mode (double are emulated through integer computation), which is probably not what you want.
Hi, well I did not cast anything before this, hoped it was the problem. If i don't use the casts it still works fine for theother values.
the sqrt command needs doubles so is there a better way to avoid the software mode ? (if i don't cast will that do the trick , like i did before trying to cast?)
I can't output the assembly code at this point because I never got the debugger to work.
k well I'm not into asm at all so i replaced my function for yours(I thought I should do that i guess)
and I get also errors with the FPU only now in compiler time:
/cygdrive/c/DOCUME~1/Reinier/LOCALS~1/Temp/ccERFXrw.s: Assembler messages:
/cygdrive/c/DOCUME~1/Reinier/LOCALS~1/Temp/ccERFXrw.s:328: Error: Improper VFPU register prefix 's'
/cygdrive/c/DOCUME~1/Reinier/LOCALS~1/Temp/ccERFXrw.s:328: Error: Improper VFPU register number (003)
/cygdrive/c/DOCUME~1/Reinier/LOCALS~1/Temp/ccERFXrw.s:328: Error: illegal operands `vmul.t'
maybe I should not have done that but I could not find a difference with the other code. hope this helps a bit :s
Ghoti wrote:k well I'm not into asm at all so i replaced my function for yours(I thought I should do that i guess)
and I get also errors with the FPU only now in compiler time:
/cygdrive/c/DOCUME~1/Reinier/LOCALS~1/Temp/ccERFXrw.s: Assembler messages:
/cygdrive/c/DOCUME~1/Reinier/LOCALS~1/Temp/ccERFXrw.s:328: Error: Improper VFPU register prefix 's'
/cygdrive/c/DOCUME~1/Reinier/LOCALS~1/Temp/ccERFXrw.s:328: Error: Improper VFPU register number (003)
/cygdrive/c/DOCUME~1/Reinier/LOCALS~1/Temp/ccERFXrw.s:328: Error: illegal operands `vmul.t'
maybe I should not have done that but I could not find a difference with the other code. hope this helps a bit :s
not vmul.t but vscl.t indeed
well this is just to tell you there is a libpspmath.zip which has a lot of function about 3d stuff and which are very quick.
and dont forget to enable VFPU in your thread if you plan to use them
Last edited by hlide on Sun Jul 29, 2007 8:28 am, edited 1 time in total.
replace LOG with the debug print function and cross the fingers to see where and why there is an exception. You should work this way if you cannot debug it.
I can only think the exception is an underflow, ie. vec.x is a very tiny number and when squared it underflows to 0. Perhaps the exception mask needs changing?
I can only think the exception is an underflow, ie. vec.x is a very tiny number and when squared it underflows to 0. Perhaps the exception mask needs changing?
Jim
ok.
just a thought : if 0.0 x -0.0 = -0.0 (X x -Y = -XY), what 0.0 + -0.0 gives us ? 0.0, -0.0 , NaN ? and sqrtf(-0.0) ?
for some reason, I suspect LOG (whatever you put in) has no time to display a message, so you should have a "pause" between each LOG (that is, press a key to continue) so you can have time to see a message before the next instruction crashes
Hi well, I have a toolclass for this with a lot of functions, writing to file, displaying debug info etc. but one function is to loop the debug info, so when you reach that function it goes into a loop, or well it should go into a loop. I have create the loop in front of thevariables and after the variables and before it does its work perfectly fine but right after the first line of code it crashes :(
EDIT:
if I do this:
sprintf(s, "x= %f y= %f z= %f", vec1.x, vec1.y, vec1.z);
it shows that but as soon as I change it into vec1.x*vec1.x in stead of just vec1.x then it crashes :s
vec1.x = 0.00000f , so since when can't i multiply somthing by zero, i though that you cannot divide by zero but multiply also ?
Of course you can multiply by zero, but is it really 0, or just 0 to 5 decimal places? Can you try using %g instead of %f?
If this "Status - 0x20008613" is your FPSCR, then that is showing a divide by zero exception.
<edit>I'm pretty sure it is, can you post the code with the "don't divide by zero" check in it that you are using?
Status is actually the MIPS SR reg, you should be able to dump the actual FPU status reg with the 'exprfpu' command. Of course the character codes after the FPU exception actually indicate what has happend. In this case they are I which is inexact operation, U which is underflow and V which is invalid operation. Basically you have a normalisation issue with one of your floats being too small and the fpu blows up :) Best way around this is normally to just disable fpu exceptions.