• ### Popular Now

• 13
• 18
• 19
• 27
• 10

#### Archived

This topic is now archived and is closed to further replies.

# floats and updates serious problem

This topic is 5982 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Ok, some of my update routines for frame cycling and movement update used DWORD comming out from a call to "LastTime - timeGetTime()"; but just today I changed all this routins to used FLOATs "(LastTime - timeGetTime())*0.001f) because I''m using another aproach for smooth movement. The problem is that for example: void CBaseSprite::CycleFrame(float* _pfElapsedTime) { if ( (*_pfElapsedTime) >= m_fAnimInterval) { if (FCurrentAnimation->Order == NULL) FFrameNbr++; ... As you can see, every time the elapsed time goes over the frame time interval, the frame is changed; however, when my program is in free running it takes years to change the FFrameNbr property, but if I''m going step by step things work OK. m_fAnimInterval its equal to 0.060f (60 ms), so I''m sure that I''m not comparing against incredible high values, as it looks on free-running. So, What is going on here!!!??????? /\ /__\ C.Z. Hagen

##### Share on other sites
If I understand you right you went from using
LastTime - timeGetTime()
to
LastTime - timeGetTime()*0.001f
Is that right?

If so then it makes sense that it is taking a long time for things to happen. You''re greatly redusing the value returned by timeGetTime(). Pluse if I remember correctly DWORDs are 64 bit ints and don''t have any decimal places, so if you are assigning the bottom equasion to a DWORD the result will be 0 for a long time.

Jason Mickela
ICQ : 873518
E-Mail: jmickela@sbcglobal.net
------------------------------
"Evil attacks from all sides
but the greatest evil attacks
from within." Me
------------------------------

##### Share on other sites
He does seem to have parentheses in the correct location, so that can''t be it.

Also, DWORDS are 32bit, but I assume he put the result in a float, especially considering the fact that the CycleFrame function has a float parameter.

I think the problem lies in the actual computation:
(LastTime - timeGetTime())*0.001f)
Since timeGetTime () will return a bigger value than LastTime, this results in a negative number. Oops.

If this was a typo, it might also be that you''re not accumulating the differences, but just taking the difference from the last frame. The correct way to do this would be something like this:

  DWORD lastTime;DWORD curTime = timeGetTime ();float timeElapsed = 0;float frameTime;for (;;){ lastTime = curTime; curTime = timeGetTime (); frameTime = (curTime - lastTime) * 0.001f; timeElapsed += frameTime; if (timeElapsed > 0.060f) { timeElapsed -= 0.060f; }}

But I must say I really don''t see the point of converting to float in this way. You''re not increasing the resolution of the timer at all and by using float you lose both accuracy and speed. timeGetTime is pretty inaccurate anyway. Look up the QueryPerformanceCounter function, which has a much higher resolution.

##### Share on other sites
thanks!

Yes I had a misstype there,
and also I was not adding the last time value.

/\
/__\ C.Z. Hagen