Racing game timer

just use something like this:





May not be pure, but you should get the idea.

that idea is horrible! imho.

do something more like this:
every time you update the game stuff, store the timeGetTime() in a variable. then, when u update the game next time, see how much time has elapsed and scale your movements and stuff accordingly.

Won''t that still lead to differences in behavior? If your AI updates every frame, I don''t think you can get uniform behavior independant of frame rates. Perhaps you could look at updating your cars'' AI based upon the total amount of motion that has occurred in the game?

It certainly will lead to inconsistencies in behaviour not to mention the extra amount of logic and calculations you'll have to put in there to make sure every thing happens exactly the same way.

But then again, everyone has there own way of doing things and one way is not necessarily the best way. It depends exactly what you want to achieve.


Also remember that no-one is forcing you to put everything inside that timer, you can choose what you put in! Just a hint

[edited by - redgenie on October 22, 2002 2:53:39 PM]

static float last_time = GetTime();
float cur_time = GetTime(); // current time in seconds

float delta_time = cur_time - last_time;

const float step = 0.01f; // movement every 10ms

if(delta_time>0.0f)
{
    while(delte_time>step)
    {
        Update(step);
        delta_time -= step;
    }
    Update(delta_time);
}

last_time = cur_time;

 

This is how I do it in my 3d racing. like

For every game you make, you should try make a releastic universe which means it must have these SI units:
m - Space
kg - Mass , not so important
s - time very important
C - electric charge, no need for this one

ok, the one your intrested in is m & s, for you racing game. You need define what a meter is in your 3D world, this is just a bit of trial and improvement. Once you have it:
define Meter value

Then for every car you set its velocity & accelrating in meters per second, as some sort of const. If you were doing realstic physics model you would mass to come to conclusion about there velocity constants etc.

Anyways, every time the physics functions are called they are passed a variable(delta) which is the change in time since the last physics call in seconds. Since all your velocity units and accelartion units are in meters per second. Just multiply the const velocity speed for the car by the chage in time to get how far the car has come, e.g.:

const int MaxVelocity = 60,000 ms(60 Km)

void Physics(int delta)
{
int MyPosition+=delta*MaxVelocity
}

lets say you are getting 2 fps, therfore the physics function is being called every 1/2 a second:
=0.5*60,000
=30,000

so this model, is actully frame rate dependant wheither the computer is going 700 fps to 3 seconds a frame the physics will work.

hope this helped: Iain

That will work if you move straight.
But think about 2fps when you are turning to right. 50fps your car goes along the road, but 2fps you find yourself bottom the ditch.
You need to split that 0.5s into smaller steps like I showed above

Did you use Direct X for the graphics?

What has the rendering API have to do with the physics?

All you must do is make the logic run at a constant rate independent of the framerate.

It runs every X milliseconds.

If it hasn''t been x millis, skip it. Render.
x millis, run it. Render.
4x millis, run it four times. Render.

Get the idea?

>If it hasn't been x millis, skip it. Render.
>x millis, run it. Render.
>4x millis, run it four times. Render.

This is really fine. This is what I'm doing in my own racing game. There's only a small difference..

In the case you render a frame without running the simulation, it would be really important for the renderer to linearly interpolate the position of the moving object (along its velocity) according to the time passed since the last fixed timestep.

It should look much smoother since vehicles will move every frame. But the calculated position by the renderer is only an approximation it does not really move the body for the simulation. The simulation always move the vehicle with proper physics. If you do not interpolate between frames it will be jerky.

And with the fixed timestep scheme, you almost get instant replay for free if you take some care. : )

[edited by - nosfy on October 24, 2002 8:56:11 AM]

Im using opengl. The game is almost finished and is runs at 86 fps in my computer. what i think i will do is to keep the logic
running at a certain speed. and render the scene multipling the data by a timerfactor (like deyja´s way). This is how i tried to explain, but i think it was not clear.
Thanks for all the answers.

quote:

---

Original post by stefu
That will work if you move straight.
But think about 2fps when you are turning to right. 50fps your car goes along the road, but 2fps you find yourself bottom the ditch.
You need to split that 0.5s into smaller steps like I showed above

---

As long as your simulation / game / etc is independant of your rendering the car would be in the same position after the same amount of time. Wizard has it right. You should just render the current state of the simulation. The simulation should not care in the slightest how many frames per second there are, only with how much time has passed since the last iteration in the simulation.

I agree. But my way doing it is very very very simple and for my needs currently it works very best well.