Can anyone explain the basics of time based movement or give me some online tutorials on this. It's really annoying to see my game run 1000x faster on a friends comp whose fps exceeds the refresh rate. Thanks in advance

I don't know of any tutorials but I can give you an explaination of how I do it in my programs. I have only done some really simple 2D stuff, so keep that in mind.

The basic difference between a time-based movement and a frame-based movement is that, instead of giving your objects a certain distance/frame velocity, you give them a certain distant/second velocity. For 2D games, the distance is usually in pixels. For 3D games, I'm sure you can use whatever unit you like as long as you are consistent for all objects.

So in order to do this, you will need a way of keeping time, so that you know how much time has elapsed during each frame.

This depends on what language or API you are using. I use SDL because it's very easy to use, and SDL has SDL_GetTicks() function that will allow you to find out how much time (in milliseconds) have passed since some arbitrary point of time in the past (it could be the time at which the computer was turned on, or the time at which the program started -- I have no idea, and it's not important). If you are using Win32, I believe you will want to call GetTickCount(), which I'm fairly sure gives you the amount of milliseconds that have passed since Windows started.

If you call SDL_GetTicks() every frame, you can easily determine how many milliseconds have passed from one frame to the next. Simply check the current tick count and subtract it from the previous tick count. So, if at frame 12 the tick count is 2938 and at frame 13 the tick count is 2968, then you know that 30ms have passed since the last frame, and you can update your objects' positions accordingly.

If your object's velocities are in pixels per second, you will want to first calculate the number of milliseconds that passed since the last frame. Then, divide that by 1,000 to convert it to seconds. Then, multiply the velocities times the number of seconds to get the total amount of distance to travel (distance = velocity * time), and add that distance to their current positions to get the final position.

Aright, thanks man.

Time based movment! One of my favorite subjects!

In a traditional noob game, things are typicaly incrimented by a constant.

player.x += 10;player.y -= 10;

This is all fine and good until you have to deal with more complicated things such as physics, and sharing resources.

The objective is to get it to look something like this.

player.x = player.x + (time_incriment)*(x_velocity);player.y = player.y + (time_incriment)*(y_velocity);

This allows for a lot more realism and flexability. Typicaly, time_incriment is how long it takes to render a frame, however, we must elaborate on this.

One of the things that time based movment helps with is when the processor allocation varies. If your program gets prioity every 10ms, you need to treat it differently than if it got priority every 100ms. When we poll the timer to check how long it takes to process the frame, the time value is going to be different in each case.

If we take the direct time value, movement can still be choppy, say if somebody pops up on MSN while we are killing zombies, it's going to reduce our priority in the middle of the game, and it will take longer to render a frame. What we need to do is break down the frame into smaller frames before rendering, so that way, our time based objects don't do weird things, like fly through walls and such.

float t_time;                       //the time polled each roundconst float small_t = 0.0215f;      //the smallest possible timewhile(isRunning == true){ int incs;                          //how many times are we going to have to break the frame down? t_time = game.Poll_Time(); if(t_time < small_t)  incs = 1; else  incs = (int)(t_time)/(small_t); for(int i = 0; i <= incs; i += 1) {  game.UpdateObjects(small_t); } game.CheckInput(); game.Render();}

That crude piece of code demonstrates having a lowest possible time per frame, and prevents the time from becomming to large and unmanagable. This would even be able to handle delays up to a second or more. The only thing you need to be sure of is that it takes more time to render the scene, than it does to apply the physics to. Otherwise, you will need to tweak the formula some more. As long as rendering takes more time than running the physics, each time the loop is encountered it will take less time to catch up and run at optimal speed.

I hope that helped some. If I left anything out, let me know.