   Resources on Frames Per Second
  I am trying to setup my own rendering engine. But before I do. I am trying to find some good resources on the understanding of Frames Per Second. When I mean Frames Per Second, I mean creating frames that run at the same pace on all computers. I need a better understanding on how that is done so if someone can either point me to some good resources, or explain, that will be greatly beneficial. Cause I have not ran into any tutorials that break that down.   
  Read the Gaffer on Games Physics Article, especially part II which addresses your question about regulating frame rate: Fix Your Timestep.I found the article really helpful.   ;  There seems to be little point. Your game should run as well as the machine it's running on allows it to.If you must lock to a consistant framerate then your options are:Run on and optimize for a single (or very few) known platform(s) -- the console approach.Lock the framerate down, which will either 1) require that the ability of more powerful machines are wasted (greatest common denominator) or 2) eliminate all down-spec customers from your user base.Its far better to just let the game run balls-out at whatever graphical settings the player chooses. Those with weaker machines know well enough what features to disable (or can determine, experimentally) or tune down in order to get framerates they can live with. They know they don't have the most bad-ass rig, so the've already set their own expectations accordingly.Now, you certainly can, and should, run logic independant of graphics whether logic is at a fixed timestep or a separate, dynamic timestep (fixed is easier to deal with, and in general has greater stability).   ;Quote:Original post by RavyneThere seems to be little point. Your game should run as well as the machine it's running on allows it to.If you must lock to a consistant framerate then your options are:Run on and optimize for a single (or very few) known platform(s) -- the console approach.Lock the framerate down, which will either 1) require that the ability of more powerful machines are wasted (greatest common denominator) or 2) eliminate all down-spec customers from your user base.Its far better to just let the game run balls-out at whatever graphical settings the player chooses. Those with weaker machines know well enough what features to disable (or can determine, experimentally) or tune down in order to get framerates they can live with. They know they don't have the most bad-ass rig, so the've already set their own expectations accordingly.Now, you certainly can, and should, run logic independant of graphics whether logic is at a fixed timestep or a separate, dynamic timestep (fixed is easier to deal with, and in general has greater stability).Well I am not talking about in regards to how fast objects are rendered on the screen. I am talking about in regards to movement and animation in the game. If I don't set a restraint on the positioning of objects in the game. Then people with faster computers will see objects move faster then people with slower machinesIn this case, I wouldn't go by the cpu tick to move objects. Instead, I would go by the delta time. If the delta time is longer, then I would move the object along a farther distance. if it is shorter, then I would move the object along a shorter distance.of course I will let performance and algorithms go balls out. But as far as movement and animation is concerned. I wouldn't want to do that. ;  Well, there are kind of two approaches when it comes to logic/physics timesteps.1) You use some accurate timer to give you an accurate read of the time delta, and make all your computations time-based. I would say that most games do this.2) You use some fixed timestep that gives you enough accuracy, and which you can calculate quickly enough to give a desirable update frequency. Forza, for instance, calculates physics at a fixed rate of 600 Hz -- so there are 10-20 "physics frames" for every video frame, at least that's what I've read. The trouble of course is that you have to be 100% certain you can achieve those calculations before the frame is due (idealy) or you have to double-buffer object state and render in a separate thread.   ;Quote:Original post by numerical25Well, there are kind of two approaches when it comes to logic/physics timesteps.1) You use some accurate timer to give you an accurate read of the time delta, and make all your computations time-based. I would say that most games do this.2) You use some fixed timestep that gives you enough accuracy, and which you can calculate quickly enough to give a desirable update frequency. Forza, for instance, calculates physics at a fixed rate of 600 Hz -- so there are 10-20 "physics frames" for every video frame, at least that's what I've read. The trouble of course is that you have to be 100% certain you can achieve those calculations before the frame is due (idealy) or you have to double-buffer object state and render in a separate thread.O ok. Well I am starting to here the word time step alot so I am guessing that is the magic word. I guess I can do more research on that but thanks anyways, I think the delta time is waht I am going for.@signal_ and thanks for the link probably going to read more into that later   ;  By making your animations and movement time based, variable frame rates will no longer be a problem   ;Quote:Original post by Aerodactyl55By making your animations and movement time based, variable frame rates will no longer be a problemI second that the timing of key-framed animations (and the like) should be based on frames. But the numerical methods used in physical simulation often require a fixed timestep for the purpose of stability. So when using physics there is a challenge in integrating a fixed timestep simulation with a variable timestep rendering.   ;  Using a variable timestep for physics is almost always a horrible idea.Ideally, both physics and logic should happen at a fixed timestep. That way, you can test it on one machine, and avoid worrying about obscure race conditions on other machines.   