Joined: 09 May 2006
Location: Under hill, over dale
The game loop example you posted doesn't do this. It couples state updates with redrawing as tightly as possible: the frame rate is fixed and that the game speed is the same as the redraw speed. With such a game loop, naïvely getting rid of the 30 frames-per-second cap would mean that the game could suddenly run twice as fast, or even shift between half as fast and twice as fast or so (I am already getting motion sick ).
Actually, the game loop posted takes the time difference into account, and uses that in the update calculations... therefore the frames-per-second can vary, but the animations, physical movements, etc will be adjusted to how long its been since the last call.
Unless you are referring to the fact that the Physics/states are dealt with 'in the game loop' at all, as opposed to being dealt with separately in another thread which the game loop only queries when its time to redraw. Of course, that brings into it all kinds of fun with threads and volatile data, and can potentially make things distinctly unstable - not to knock it though, well-written multi-threading such things to keep them separate can given many benefits.