No, no, no. That is ick! A tight busy loop doing absolutely nothing worthwhile while so much else could be done. At the start of your application, set up these variables

DWORD FDesiredFrameRate = 30;DWORD FInterval = 1000 / FDesiredFrameRate;DWORD FLastUpdateTickCount = 0;DWORD FCurrentTickCount;

In your message loop

while (!FTerminated){  while (PeekMessage(FHandle, &Msg, PM_REMOVE))  {    // Get message and do message processing  }  FCurrentTickCount = GetTickCount();  if (FCurrentTickCount - FLastUpdateTickCount > FInterval)  {    float TimeSinceLastFrame = (float)(FCurrentTickCount - FLastUpdateTickCount) / 1000.0f;    UpdateGameLogic(TimeSinceLastFrame);    RenderGame();    FLastUpdateTickCount = FCurrentTickCount;  }}

Your game logic should take the time elapsed since the last frame to make any updates. Do not depend on your frame rate staying constant. If you rely on this, then Murphy''s Law implies that it will not happen as you expect it to. And of course, your rendering should be independent of game logic as well.

If you want a different frame rate, then change the value of FDesiredFrameRate and recalculate FInterval.


Steve ''Sly'' Williams
Tools Developer
Krome Studios

Do realize that you are using GetTickCount(), which is limited to the windows timer which has a resolution of roughly 55ms. Which only ticks 18.2 times per second.. In other words, using GetTickCount, you can only actually get 18.2 frames per second.

Look at QueryPerformanceFrequency and QueryPerformanceCounter to use instead.

There maybe good reasons to lock frames, multiplayer RTS for instance?

But unless you have a really good reason to do so, you should try to avoid it.

You need to parameterize everything using elapsed time.

Look-up QueryPerformanceCoutner on the msdn.microsoft.com website, in the library, under platform sdk, win32 api, reference, Alphabetically, Q

TimeSinceLastFrame is the amount of time that has elapsed since the last frame was rendered....

Do you know what velocity is?

You do want it to run on the same speed on all machines, but locking it is not the best way to do it. Fast computers will be limited to a low FPS and slow computers will still run at the wrong speed. You want to figure out how long it takes to get through each frame, and use that number to scale the speed in which every thing moves. I don''t remember the formula to do this is right now, but I''m sure you can find it somewhere. Sly has a good start, but it''s not complete. I remember calculating something in my code and multiplying things by it, like:

x += speed;
y -= speed*2;
z += speed/2;

It is something like that. Note that speed IS NOT the same as TimeSinceLastFrame, but is a function of it. I wish I coild remember what it was. This way the things move fast on a slow computer, and slow on a fast one. I hope you figure it out. Sorry I can''t be of more help to you. Don''t feel bad. I used to lock the FPS too.