Quote Originally Posted by WILL
So in your honest opinion you think that the only way to break the game cycle limit past the monitor's refresh rate is to go multi-threaded?
Not what I meant - I meant to avoid wasting CPU time that could be better spent elsewhere on faster machines, and prevent the game from running slower on slower machines.

If the machine isn't fast enough to run the game at 60fps, you should be dropping frames but still have the game run as fast as on any other computer. This is how the big name 3d games all work - the game doesn't slow down just because it's not fast enough, it just starts dropping frames - likewise the game doesn't speed up just because it can render 120fps... you have to scale your movement to the time available.

Multithreading is a simple way to do it, and takes advantage of the new multi-core machines, or even older multi-processor machines, but it's certainly not the only way... You could set up a timer, then when you go to update your movement you scale it to the time elapsed since the last time your movement was done. Delphi's TTimer object is ideal for both approaches... If you set it to 60 times a second and handled all movement in the onTimer method, problem solved (I'd actually run 240 there so as to allow faster FPS to have something to draw). You could even set the timer to say... 512 times a second, just increment a byte timer in your ontimer method, and scale movement based on how many 'ticks' have gone by at render time.

The key is to make 100% sure the game runs at the same speed regardless of the hardware it's on or how complex a scene is... and refresh rate doesn't do that.