On Mon, 2006-11-13 at 13:23 -0800, Alan Wolfe wrote:
> 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?
Yes, the priority queue is IMHO the best way to go. Using a priority
queue and processing the items in it before each frame make sure that
everything that needs to be updated for that frame is updated. It also
allows things to update at what ever rate they need to update. It allows
for variable times between frames while keeping everything looking
right.
Here is an example that might help. Lets say you have a bullet in a gun.
When you fire the bullet it gets put in the priority queue with a time
of "right now". That will put it at or near the front of the queue. When
it is its time to update it will be at the front of the queue. So, the
update code runs its update method. The last thing in its update method
is a call to put it back in the queue with a time 10 milliseconds in the
future. That makes sure that its update method will be called again in
roughly 10 milliseconds.
The objects can keep track of the actual time and adjust their wait time
to keep close to the desired time.
Bob Pendleton
Bob Pendleton
>
>
> 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
>
>
>
--
+--------------------------------------+
+ 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
