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


Speed Difference on Different CPUS

Recommended Posts

I am expeiencing a problem with my OpenGL programs. When run on a faster CPU, my game runs considerably faster than on a slower CPU. This would be a great thing, except, certain computations take place each frame. At the speeds that this runs on a fast CPU, it is impossible to play the game, it is just way to fast... Is there anyway I can use to slow this down or limit the FPS? Thanks in advance, Joe

Share this post

Link to post
Share on other sites
You can limit the framerate by setting up a timer and only calling the logic and rendering functions so many times per second. That would so what you want and it''s fairly easy but it''s generally considered a bad idea.

Instead, change your program''s philosophy some. Instead of saying: I want to rotate this cube 5 degrees every frame (so if someone''s getting over 100 FPS, it''s spinning like crazy), decide that you want the cube to rotate 180 degrees per second. In other words, use velocities. Then in your main loop, get the amount of time that passed since the last time a frame was displayed and figure out how much things should move based on that.

This way, the game runs at the same speed regardless of how many FPS you''re getting. It''s just that on slower computers, the animation will be choppy while on extremely fast computers, the animation will be very smooth.

Look up stuff on achieving framerate independence. I think there might even be an article about it on GameDev somewhere...


Share this post

Link to post
Share on other sites
The best way to resolve this issue is to treat your object updates on a per second basis as opposed to per frame. This solution actually helps ease your understanding of how your physics calculations will relate to reality. If you look at any physics book you will see that all units that relate to the change in an object''s state are seated in a per second basis.

Velocity is measured as meters per second (m/s), Acceleration as meters per second squared. You can also think of it as meters per second per second (m/s^2). Right now, I would assume that your program handles things on a frame dependant time unit, and is using ambiguous spatial units.

This problem seems a bit tricky to solve seeing that a game operates on an infinite loop, and at whatever rate the loop updates dictates the rate of the game. The solution lies in finding a way to find out how much time has elapsed since the last frame, and using this information to update your world appropriately.

Windows has many timers availble to do this, you can use the WM_TIMER message and use this to update your game, but you''ll end up with crazy synchronization issues seeing that your game updates and rendering code will be in different threads. Also, the WM_TIMER isn''t very accurate, and the message to update maybe old by the time the CPU has gone idle, so what to do?

Look into high preformance timers. Windows has one and it is extremely accurate. You can query these times on every frame and determine how much time has gone by since the last scene rendering and use this, which will be in terms of seconds, to update your world.


while(true) {

secondsPast = GetElapseTime();


UpdateWorld() will look something like this.

void UpdateWorld(float dTime) {

for(int i = 0; i < ObjectsCount; i++) {

AllObjects.x += AllObjects[i].velocity.x * dTime;
AllObjects[i].y += AllObjects[i].velocity.y * dTime;
AllObjects[i].z += AllObjects[i].velocity.z * dTime;



Off course, there is a bit more work to be done here seeing that the velocity is not updated. But, since the velocity is assumed to be meters per second, and we are telling our UpdateWorld function how many seconds have gone by, the object''s positions will be updated on a per second basis, which on all machines regardless of speed will produce movement at the same rate.

Here is a link to a Gamasutra article on creating a game engine that allows for reproducible behavior, or replays. This may seem a bit off topic, but actually, this system requires that a very accurate timing algorithm be in place, and so it is described in this article as well:

There are other issues here, however. If a machine is really slow, and it take a whole second to draw a frame, then the update of velocity may become inaccurate. This can be solved in a number of way,a nd some of them are addressed in the link I gave you.

I hope this helps... Good Luck.

Share this post

Link to post
Share on other sites