[gameprogrammer] Re: Fixed Rate Logic

This is a good way to handle updates, but here are a couple of small 
observations:

1)  You are correct in assuming that all updates should not happen in the same 
loop.  Instead each individual object or group of objects should be updated 
with their own update time.  This will help prevent bottlenecks (spuratic 
behaviors).

2)  You can also update on the total amount of time that has passed.  I assume 
that you move the bullet X distance every time you call UpdateLogic().  You can 
simply move the bullet TimeSinceLastFrame/50*X (As long as you convert 
everything to float percision).  This way you do not need to track the 
underrun.  Location should also be based on float percision also.

3)  This is minor, but you should put some assert or loop exit code in your 
loop so that you do not exercise the loop endlessly in a programming error.

4)  And make sure you have proper pause/resume code around all timer functions. 
 Otherwise things will go wild if you task out, or bring up any dialog boxes.

5)  As far as what is reasonable it depends on what you are talking about, 
abient or non-esentail gameplay objects can often be updated much less.  Items 
that move faster generally should be updated more.  Depending on your screen 
refresh / render rate you may want some things updated 30x or 60x/sec.  In 
either event I do not recommend a point collision system, but if you must, then 
at least interpolate along the movement path and check for collisions, it will 
be faster than a rendering hit check.

6)  On a pc you will likely not get percision below 20ms (depends on the 
machine), so don't bother going below that.

Overall this will give you better results than other methods that typcially can 
loose percision with movement calculations.

----- Original Message ----
From: Alan Wolfe <alan.wolfe@xxxxxxxxx>
To: gameprogrammer@xxxxxxxxxxxxx
Sent: Saturday, November 11, 2006 3:37:15 PM
Subject: [gameprogrammer] Fixed Rate Logic


Hi Everyone!
 
In my current project I'm about to start migrating my fixed rate logic code.
 
The system that's currently in place measures the time in miliseconds between 
frames and then uses that number in all the physics calculations (like gravity, 
momentum etc).  This leads to really sporadic results where you can't duplicate 
skill jumps except by luck and also when you lag, things go crazy!  For the 
most part though, it works fairly decently. 
 
The system that I want to move to is instead to keep track of how many 
miliseconds between frames and then when that number got above some threshhold 
(like lets say 50 miliseconds?) then it will call the LogicUpdate() function. 
 
More specifically something like this (pseudocode):
 
TotalTime+=TimeSinceLastFrame;
 
while(TotalTime>50)
{
  UpdateLogic();
  TotalTime-=50;
}
 
I know people on this list have dealt with these things before so I was 
wondering, are there any pitfalls I should know about?
 
One thing I am concerned about is I'm wondering if different things should have 
different logic update rates?  For instance a bullet should maybe be updated 
every 10 miliseconds while an enemy should be updated every 50?  Or is this a 
needless worry and things should run fine if they are all updating at the same 
rate? 
 
Also I was wondering, what is a reasonable update rate?
 
Thanks a bunch, I'm a noob to this fixed rate logic stuff so any help is much 
appreciated! (:
 
Alan


 
____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com

Other related posts: