Problem with timers and FPS

Started by
12 comments, last by Etus 21 years, 2 months ago
quote:Original post by orbano
the other way is to keep watching fps, and calling the update routine if needed (e.g. in every 3th frame. i think its better in action oriented games where high framerate is essential)

If nothing is updated, why rendering again the same image ?


----
David Sporn AKA Sporniket
Advertisement
I suspect he means input, ai and physics updating, with object movement interpolated between rendered frames.
What I do, is I add a possibility for each ''animated'' object or objects to lock its updates. For example, I have a particle system, and I have a UpdateSystem function for it, where I check whether or not to update the system based on the time alredy passed. So, I can say, ''lock number of updates per second to 30'' for this particle system ,and it just do so. You can do similar thing (if you don''t know how, reply again with request or mail me to acolyte@ozforces.com.au and I''ll send you the code)

" Do we need us? "


Ionware Productions - Games and Game Tools Development

OK, folks, the "correct" method is this:

Find the number of milliseconds elapsed between the last frame and this frame. This will be the delta time (delta means "change in").

Say you have something traveling at a velocty of 0.2 (in units per millisecond) and its position is 80.0 (in units). We are pretending we are only in one dimention at the moment. When you get back to your update loop, you take the velocity and multiply it by the delta time value and add that to the posion. Say it took 50 milliseconds between frames, you would find that your new position would be 180.0 units.


What you should not do:

- don''t base your movement values off Frames per Second (or per millisecond or any other frames/time). Frames per time is a bad unit. It is better to use time per frame. This is because it requires a division (which takes a long time to process, relitivly) to convert ms/frame to frames/sec (most timers give results in elappsed time and not FPS). Then when you move things, you are using a division again to convert framse/sec to ms/frame.

ThePretender is basing his movement values off FPS. He says move more with a lower FPS, and move less with a higher FPS. The way to achive that is to use a division. At best two unnessary divisions per frame, at worst, potentialy hundreds (objects updated + 1).

- Don''t do updates only on every n''th frame.

First of all, you are duplicating the functionality of vSync (verticle trace syncronisation). This is already included on the graphics card and can be turned on or off by either the user or the program. It is best to provide a default, but let the user decide.

Next, you will be waisting valuble cycles looping around waiting for the elapsed time to be big enough. Basicly vSync is tuned to give you the optimal frame rate without waisting peformance.

If you want to peform calculations that are not frame critical (eg: AI), then try multi-threading or do it every n''th frame if you must, just make sure your graphics and update (physics, etc) are opperating every frame and vSync will take care of the rest.

Also note that if you have a interpolation function, it can eaisly be slower than your normal physics functions, so it is worth while to do physics every frame and optomise the physics engine, rather than having two, half-optomised movement engines.


Hope you all got that.

Do not meddle in the affairs of moderators, for they are subtle and quick to anger.ANDREW RUSSELL STUDIOS
Cool Links :: [ GD | TG | MS | NeHe | PA | SA | M&S | TA | LiT | H*R ]
Got Clue? :: [ Start Here! | Google | MSDN | GameDev.net Reference | OGL v D3D | File Formats | Asking Questions | Go FAQ yourself ]

This topic is closed to new replies.

Advertisement