Controlling the speed of a game

[SmegHead]

I'm writing a small game that uses the DelphiX Timer component to control the game loop. What do I need to do to make sure my games always display at the same frame rate regardless of the PC that it is running on? I have the program running on 2 different computers, one is a new monster machine and one is an older machine. It's almost impossible to play the game on the new machine because everything moves so quickly -- and the older machine is a little on the slow side.

Thanks,
Smeg

[Bobby]

what you have to do is set the interval of the dxtimer to a speed that both computers can do. If you set the interval to say 10, the fast computer can do that, but the slower one can not. So you have to use say 50 for the interval, so that both computers can handle running that fast, then your game will run the same speed.

[Alimonster]

You can use time-based, rather than frame-based, movement. This means that instead of moving x pixels per *frame*, you move (x pixels * time_passed) per frame. This adjusts the speed of the game dependent on the time, so that if a fast computer gets lots of updates, the characters will move slower each frame and will end up at the same point at as not-so-good computers. The main difference is that faster computers will get smoother movement.

For this to work, you'll have to have real numbers instead of integers for your movement speed/positions.

There are a couple of threads about this sort of thing in various forums: here (http://terraqueous.f2o.org/dgdev/viewtopic.php?t=93) and here (http://terraqueous.f2o.org/dgdev/viewtopic.php?t=63). There are plenty of links/info in those for you to look at. 8)

Locking the frame rate (giving the timer a value > 0) will work sometimes. It's certainly the easier solution. However, it has the disadvantage that too-slow computers will not be able to update quickly enough, so movement will not be at the same speed as with fast computers. Also, 50 is a bit low, since it equals 20 FPS (1000 milliseconds / 50 = 20FPS). You should probably aim for an interval of 33 (1000 / 33 = approx 30FPS).

[Stevie56]

The interface has a Frames property which can be used to adjust the interval of the timer.

const gameframerate=20; //set this to suit
procedure TForm1.DXTimerTimer(Sender: TObject; LagCount: Integer);
var frames:integer;
begin
if not DXDraw.CanDraw then exit; //locked
DXDraw.Viewport.ForceUpdate(0, 0, DXDraw.SurfaceWidth, DXDraw.SurfaceHeight);
frames:=DXTimer.FrameRate; //this is the machine-dependant data

DXDraw.Scene.Move(1.0);
DXDraw.Render;

if frames>gameframerate then inc(DXTimer.Interval) //slow down
else if frames<gameframerate then dec(DXTimer.interval); //speed up

DXDraw.Flip;

end;



Hope this helps.

[savage]

Hi Smeg,
I would agree with Alimonster and suggest going with a Time based movement system.


Lickety split Rimmer.

PS. There is a dire shortage of Red Dwarf episodes.

[Clootie]

Yep, time based movement system is the way to go.
And I would recomment decouple phisics calculation (movement etc.) from rendering. I.e. render as fast as you can, but recalculate you world state only fixed times per second and when rendering just lerp between last actual phisic state an predicted (or pre-last state and last state - if you phisics clock is above 20Hz peple will not findout it).

[kk]

I agree with the time based movement control. The only thing you have to do is to convert the velocity (or whatever) from a per second (or per hour) format into per frame-time format. While initializing multiply by frame time and when finalizing frame physics data multiply by the inverse of the frame time.

I agree with Clootie just partially. I have done several implementations of physics engines and I can tell you that there will be always a quadratic time paradox (a mathematical error) until you use a constant cycle time for physics engine (simulated and asynchronous to the graphics engine). But 20Hz is not enough. I would use like 50Hz. This means update each 20 milliseconds... I would even consider to simulate more often using shorter times if using step based physics engine (e.g. rigid body engine). A lot of engines, even commercial do not recognise the frame time variance in physics engine as a problem, but they should if the physical model is based on non-linear calculations as s = 1/2*a*t^2.

-kk
developer, pythianproject.org