Big NAN Troubles ...
Blitz3D Forums/Blitz3D Programming/Big NAN Troubles ...
| ||
| An Owner of a GeForce FX5600 reported a bugous behaviour of one of my products: While my App only does a: Text 0,0,EntityX(player,1)... His Machine sometimes writes "NAN" (not a number) to the screen, instead of the current position. It also seems like he was kicked out of his location without any reason after a mouse movement, and ends up in the darkes space (tho I use the MouseSpeed funtion only for rotation). I haven't be able to reproduce thie NAN thing on my machine, is this something GeForce specific, or maybe a Driver Version thing? Thanks. |
| ||
| As far as I can see, that Text command should never produce a NaN. :/ |
| ||
| Yeah, but entityX with a global transform might. Not enough information to say what is causing it, though I will hazard a guess that maybe it is the mouse driver. If for some insane reason mousespeed is returning NaN (or maybe infinity which would probably screw you up as well) at least it is something you can easily check for and reject if it occurs. |
| ||
| well, especially the EntityX() command shouldn't. can it be that some kind of division by near-zero that took place at an other place would force DX to return NaNs everywhere? |
| ||
| DJW - you mean if I use the Mousespeed for the rotation, it may give me a Nan in the Position? |
| ||
| Yes my point is the use of global will mean it has to use the global transform matrix. And if you start feeding that with Nan and infinity it gets very sick very quick. I have not actually tried rotateentity with Nan and Infinity, but I doubt it would be pretty. Not saying that is the reason though, it is just a guess. There could be other reasons, but since it does not occur on your machine and it does on his and this happens when he uses the mouse... |
| ||
| Thanks a lot. I'll check this out. I guess I got to find the source of the NaN first. Can be hard when it happens on someone elses machine only :/ |
| ||
| Yes, but... The only flaw to that idea though that just occured to me is that Mousespeed should only return an int, and so you can not get NaN or infinity out of it no matter how hard you try. :( |
| ||
I never had any problems with MouseSpeed, but I'll try it anyway.zero#=0.0 nan#=zero/zero if mouseXspeed()=nan then runtimeerror "gotcha, bugger!" or something like that. Well, infact I will also test other values with it, including the FpS calculation, that may do weird things when vsinc is deactivated and no geometry is loaded. |
| ||
| I got NaN's alot with my entity positioning over a networked game. It turned out i was accidentally, exponentially accelerating it :S |
| ||
| Are you feeding a raw mousespeed into rotateentity or are you scaling it first? Maybe the scalefactor is being set to zero for some reason producing Infinity. Not very likely though, grasping at straws now :) Anyway I have just confirmed that if say you are rotating a pivot which is the parent of player and you feed that Nan or Infinity then the global position of player will be reported as Nan as I suspected. So you may want to test for infinity as well, or at least division by zero. Ross has a point as well, look out for overflow producing Infinity. BTW. I think it was Michael Reitzenstein who posted a neat way to define NaN and Infinity as constants... Const Infinity# = (999.0)^(99999.0), NaN# = (-1.0)^(0.5) |
| ||
| Now I think it may have something to do with the FPS calculation. The current fps# is then used to create a movement speed factor to move things framerate independently. Now when the user is looking away from the scene, watching the dark nothing, and assuming he has - for some reason - deactivated VWait in the DX settings, the framerate may jump up to hundreds or even thousands (tho I use Flip True, but maybe the DX Settings affect this as well?). This probably may result in a NaN and explain why the mousemovement affects the position. Probably I will add a limiter, something like "if frametime < 10ms then wait for some time" to prevent this. Well at least it seems like I'm gonna hunt this bug down soonish. Those Constants didn't work for me, when I print them out, it only says 0.0 or 1.0, But when I use: global zero#=0.0 global nan#=zero/zero print nan surprisingly it wont result in a division by zero exception, but print "NaN" to the screen. so infact I can use it to effectively recognize a NaN. |
| ||
| Those Constants didn't work for me, when I print them out, it only says 0.0 or 1.0, But when I use: Hmm, now that is odd, they work here. Another mystery! Guess I will have to start using the other method again maybe this one is somehow CPU specific. (Edit - they seem to work fine here on Intel (Win 2004) and AMD (Win 98) processors ??). Anyway pleased to hear you may have found the source of the problem and it is not specifically related to the Gforce. As you say if they had disabled the wait for Vsync this will override Flip true and it will probably give some massive FPS when there is not much to be rendered. |
   |