[gameprogrammer] Re: Fixed Rate Logic
- From: "Alan Wolfe" <alan.wolfe@xxxxxxxxx>
- To: gameprogrammer@xxxxxxxxxxxxx
- Date: Mon, 13 Nov 2006 13:23:01 -0800
Ah thank you so much for the information on the heap queue, that makes alot
of sense.
where you said "This can work. I have used it in some special cases"
I thought that was the ideal setup, is there a better way to handle things?
On 11/13/06, Bob Pendleton <bob@xxxxxxxxxxxxx> wrote:
On Sat, 2006-11-11 at 12:37 -0800, Alan Wolfe wrote:
> 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;
> }
>
This can work. I have used it in some special cases.
> 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?
What ever is appropriate. As you said, a bullet may need to be update
every 10 milliseconds while and enemy may only need to update ever 50
ms. What you want is called a priority queue (also called a heap
because, IIRC it works by using a heap sort algorithm). You assign each
action a time when it is supposed to happen. Updating a bullet is one of
those things. The items will come out of the queue in time order. So,
when ever you have time to do an update you just process all things that
are in the queue that should have happened by now and you are done. Do
that every frame and you are sure that everything that needed to get
done for that frame was done.
Bob Pendleton
>
> Thanks a bunch, I'm a noob to this fixed rate logic stuff so any help
> is much appreciated! (:
>
> Alan
--
+--------------------------------------+
+ Bob Pendleton: writer and programmer +
+ email: Bob@xxxxxxxxxxxxx +
+ web: www.GameProgrammer.com +
+ www.Wise2Food.com +
+ nutrient info on 7,000+ common foods +
+--------------------------------------+
---------------------
To unsubscribe go to http://gameprogrammer.com/mailinglist.html
- Follow-Ups:
- [gameprogrammer] Re: Fixed Rate Logic
- From: Bob Pendleton
- References:
- [gameprogrammer] Fixed Rate Logic
- From: Alan Wolfe
- [gameprogrammer] Re: Fixed Rate Logic
- From: Bob Pendleton
Other related posts:
- » [gameprogrammer] Fixed Rate Logic
- » [gameprogrammer] Re: Fixed Rate Logic
- » [gameprogrammer] Re: Fixed Rate Logic
- » [gameprogrammer] Re: Fixed Rate Logic
- » [gameprogrammer] Re: Fixed Rate Logic
- » [gameprogrammer] Re: Fixed Rate Logic
- » [gameprogrammer] Re: Fixed Rate Logic
- » [gameprogrammer] Re: Fixed Rate Logic
- » [gameprogrammer] Re: Fixed Rate Logic
- » [gameprogrammer] Re: Fixed Rate Logic
- » [gameprogrammer] Re: Fixed Rate Logic
- » [gameprogrammer] Re: Fixed Rate Logic
- » [gameprogrammer] Re: Fixed Rate Logic
- » [gameprogrammer] Re: Fixed Rate Logic
- » [gameprogrammer] Re: Fixed Rate Logic
- » [gameprogrammer] Re: Fixed Rate Logic
On Sat, 2006-11-11 at 12:37 -0800, Alan Wolfe wrote:
> 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;
> }
>
This can work. I have used it in some special cases.
> 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?
What ever is appropriate. As you said, a bullet may need to be update
every 10 milliseconds while and enemy may only need to update ever 50
ms. What you want is called a priority queue (also called a heap
because, IIRC it works by using a heap sort algorithm). You assign each
action a time when it is supposed to happen. Updating a bullet is one of
those things. The items will come out of the queue in time order. So,
when ever you have time to do an update you just process all things that
are in the queue that should have happened by now and you are done. Do
that every frame and you are sure that everything that needed to get
done for that frame was done.
Bob Pendleton
>
> Thanks a bunch, I'm a noob to this fixed rate logic stuff so any help
> is much appreciated! (:
>
> Alan
--
+--------------------------------------+
+ Bob Pendleton: writer and programmer +
+ email: Bob@xxxxxxxxxxxxx +
+ web: www.GameProgrammer.com +
+ www.Wise2Food.com +
+ nutrient info on 7,000+ common foods +
+--------------------------------------+
---------------------
To unsubscribe go to http://gameprogrammer.com/mailinglist.html
- [gameprogrammer] Re: Fixed Rate Logic
- From: Bob Pendleton
- [gameprogrammer] Fixed Rate Logic
- From: Alan Wolfe
- [gameprogrammer] Re: Fixed Rate Logic
- From: Bob Pendleton