   Game Loops - Frame Rate Independance, Whats the best method?
  Hi, I am using C++ and windows xp os.I have a game loop I am using, but it is standard, so I want to make it frame rate independant or time based. I want to make it have a max frames per second. Updates to be updated every x frames. Rendering to be done every y frames. Also it would be nice to have it run smoother on old machines by skipping frames and take advantage on newer machines by rendering more etc.I have seen many examples as a result of searching the forums and have noticed that there appear to be different types eg Euler Game Loop and Canonical Game Loop. What are the differences, advantages and disadvantages between these types.Anyway, any suggestions on what would be an ideal game loop to use?   
  When you update a game update it in steps by multiplying it by the amount of seconds that have passed (even if it is less than one). that will take care of all of your in-game frame rate independence.In order to make a game run better on a older machine just have different options that can be set reducing (or increasing on better machines) qualities.Capping frame-rate can be done with VSync. It caps it at the monitors refresh rate (IIRC) and is good for quality (yet can also be bad for it).   ;  This example made sense to me:http://www.gaffer.org/game-physics/fix-your-timestep/   ;  @haphazardlynamed: Thanks for the link! I've been thinking about this for a while now, and was going to post and ask, but you answered it already! The article at the link was very thorough and useful.   ;  Following on from what KodeNerd said, this article explains in depth the advantagtes and disadvantages to locking a game to the refresh rate. 30 Frames per Second vs. 60 Frames per Second;  That was a very good read NewBreed, thanks.   ;  Each subsystem in my games has its own system. The game loop itself only passes the number of milliseconds that have gone by since the last incrementation of the main loop.My .md2 characters run at 30fps. If 30n milliseconds have passed since the last refresh of the models, then the models are moved by the equivilant of n frames in one go. Characters appear smooth enough. Input from mouse and keyboard are done once per frame, up to 120fps, which is the cap for the main loop. The number is so high because the input system is non cpu intensive.Physics and rendering are done at up to 60fps. The physics system will perform n steps per frame, where n == framerate / 60, is a natural number, and <= 4 (if game is running at 60/4 frames per second, 15, the jerky motion of objects disquises the slowdown of the physics system). Sprites update their image at up to 15fps, but move at up to 60fps, since they are dependent on the physics system. The slowest system is dumping the message log to file, which happens once every 30 seconds. You've probably noticed by now that all these numbers are divisible by 15, which is deliberate.I decided on this menagerie of different methods after some weeks of frustration trying to have a single system for everything.[btw]My own research and experimentation (sounds really sophisticated, but its not) into the framerate issue demonstrates that, with animated images with blurred borders with their are surroundings, differences in frame rate are indistinguishable above 24. However, players aiming with a mouse and keyboard find game frame rates lower than 90 to be irritating. This subject is so fascinating I may experiment further and publish my results, but probably nobody would be interested.[/btw]