#### Archived

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

# Using frametime in moving calculations

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

## Recommended Posts

I''ve got a little problem with this frametime thingie. I made a timer that uses PerformanceCounter, so it should give quite accurate results. Now when ever I do a moving calculation, I do it like this: x = vx * frametime * pixelspersec But I noticed that with fps over 1000 the movement is much, much quicker than when the fps is under 100. But shouldn''t that frametime just avoid that? At the moment I have all the game logic in one single thread. Does that affect it? I can''t figure out any decent solution for this, and I wouldn''t like to limit the fps... Thanks for any hints.

##### Share on other sites
Limiting FPS wouldn''t work either, because then people with crappy video cards would still move slower. Anyhow, try displaying the frametime variable and see how it works out. Maybe it''s not being calculated correctly.

##### Share on other sites
Yea, the problem might lie in my algorithm, but I''m not sure. I made my current timer based on one article at gamasutra, but I can''t find it anymore. Does anyone know good examples how to implement a timer? I shouldn''t be that hard anyway, here''s my:

void CTimer::Frame(){	m_dFrameEnd = GetTime() // Returns double using PerformanceCounter	m_dFrametime = m_dFrameEnd - m_dFrameStart; 	m_dFrameStart = m_dFrameEnd;	m_dFps = 1.0 / m_dFrametime;}

##### Share on other sites
I do something like this (and all numbers are approximate):

MoveMe() {
1. If 50 ms haven''t elapsed, come back later
2. moveFactor *= elapsedTime / 50;
3. position += moveFactor;
}

So basically every 50 ms, move the appropriate amount. If for some reason the framerate is really slow, moveFactor gets larger by the appropriate percentage.

Why step #1? Without it, my guy would go flying across the screen at light speed if the monitor was doing 120 fps. It''s essentially a "speed limit."

##### Share on other sites
Here's the code I use in my game bro:

quote:

void Algorithm::CalculateFrameRate()
{
static float CurrentTime = timeGetTime () * 0.001f; // Multiplyed by 0.001 so CurrentTime is in seconds
static float FrameTime = 0.0f;
static float LastTime = 0.0f;
static int FPS = 0;

DeltaFrame = CurrentTime - FrameTime; // DeltaFrame is a float data member in the Algorithm class
FrameTime = CurrentTime;
FPS++;

if(CurrentTime - LastTime > 1.0f ) // If a second has past
{
LastTime = CurrentTime;
FPS = 0;
}
} // End of function

Basically that produces DeltaFrame properly, then to do time-based movement I just multiply the position addition (woohoo that rhymed) by DeltaFrame.

IE:

Pos.x = Pos.x + Velocity * DeltaFrame;

PS as you noticed that function also calculates the current FPS.
----------

If you got any questions I'll check back the thread later today so feel free, g'luck.

[edited by - Enokh on October 17, 2003 2:24:36 AM]

##### Share on other sites
Hi. What''s cool with me is that I seldom have much to give apart from links, but I always have good links (and without their URL''s), but though, you should check an article that came in GameDev about this, they''re quite well documented. Hope it''ll help. ;-)

Prog, Hex & Rock''n''Roll :
I don''t like the Prog but the Prog likes me.
Some nice poetry to sweeten your spirit and relax a bit before programming

##### Share on other sites
Just a bit of warning, I tried to paste in the timer code from the GD article.. it was really choppy and "off" so I made my own and it works much better.. (you really can''t use it like they say you can..)

1. 1
Rutin
19
2. 2
3. 3
JoeJ
16
4. 4
5. 5

• 27
• 20
• 13
• 13
• 17
• ### Forum Statistics

• Total Topics
631700
• Total Posts
3001791
×