# How can I make my program to run at the same speed in 2 different PCs?

I found myself a problem while programming a little demo. First it was great running at 190 fps. I had a lot of fixed values that worked fine using this frame rate. Then I added some new cool effects that brought my frame rate down to 130. All went wrong, and I noticed that I had to change all fixed values to lower ones.

And what happens if I want to run this program in a Super-Geforce 3 Ultra Quattro? It would again be wrong!

How is this fixed? I actually found a way to handle this, but I dont know if its right: I made a little equation for a moving ball ->
PixPerSecond == CONSTANT_BALL_VELOCITY / CURRENT_FRAME_RATE. This is calculated each frame to keep a constant frame rate.

It’s ok or what?

Cya!

Here is more accurate move equation.
xt=x0+vx*(curtime-sttime)
,where xt- coordinate,sttime is time when object strted to move,curtime - current time, vx- moving vector(length per one unit of time), x0- starting point. It will work with ANY timing tricks.
Your equation is less accurate because periods between frames may be not equal.
I have also an equation for an object that has to reach a specific location in a specific period of time based only on current location of object. If needed…

Originally posted by RandyU:
I have also an equation for an object that has to reach a specific location in a specific period of time based only on current location of object. If needed…

Here it is.
First we’ll calculate dt - value that means path we must do on this frame in percent of total path to reach from current location:
DT = (curtime-ltime)/((starttime-curtime)+movtime);
where ltime - time of previous frame,
starttime- beginning of move
movtime - duration of movement
if you’re using float types you should check
if (dt>1) {dt=0.6} to prevent inaccuracy.
then
xt = xt+(tx-xt)*dt
where xt - current X coordinate
tx - where to reach
as you see,same about y and z coordinates
i use this equation for recoloring and resizing
i have also a jump equation… :->

fine, your equations are simple uniform movement equations from high school physics… now I have a question… how do I know:
-framerate
-time (to calculate how much something should move, that is)

and moreover… tho this is more windows programming question, I guess… right now I am using this shape for my program:

``````while(!done)
{
if (PeekMessage(&msg,NULL,0,0,PM_REMOVE))
{
if (msg.message==WM_QUIT)
{
done=TRUE;
}
else
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
else
{
MAIN LOOP
}
}

``````

this consumes all of the free cycles (althought it doesn’t starve the OS) and (since I dont know what I asked before) runs procesor-time based (this is, it doesnt know how much time has gone by, and therefor runs at different speeds depending on the hardware).

Is this (having added the time-based movement rather than using constants) the right way to do it?

Use the time between the start of the previous frame and the start of the current frame. Yes, it isn’t perfect as the new frame will likely be slower or faster but it averages out. The only real problem is when the framerate is extrmely low - can look rather ugly.

As far as the Windows code I’m not sure - there are so many ways. I’m not positive but I think you may lose some cycles if other messages are being handled. You might want to test to see what happens if you press and release the mouse button or a keyboard key repeatedly while it is running - I’m not sure if it will enter your main loop if you are pressing it fast enough… just looking at the pseudo-code you showed.

Personally (not that it is necessarily the best way) I have sent a user defined message (for drawing - NOT WM_PAINT) after each swap buffer call. This allows other messages to be handled properly and the app will get around to my drawing without causing issues elsewhere.

with Windows’ API GetLocalTime() or GetTickCount() should be enaugh then? and then I have to translate my consts to “degrees per sec” and “units per sec” right?