[gameprogrammer] Re: Fixed Rate Logic

Doh!

oh man, end of the day lul made me brain dead...or your just really smart.

thanks, that would indeed keep things from locking up while still
updating everything necesary.

how about this then...

lets say you have an event that's meant to fire every 1ms (yeah
overkill but stay with me on this one) and lets say it was last
scheduled to fire at 1050 miliseconds and then it ran and when it was
finished, and it's time to go back into the queue while the current
time is 1070 miliseconds it seems like the "most right" thing to do
would be to put it in at 1051 miliseconds (this is an extreme case of
course) but logically it seems better, if not less realistic to put it
at 1071.

What do you guys think?

On 12/6/06, Dave Slutzkin <daveslutzkin@xxxxxxxxxxx> wrote:

On Wed, 6 Dec 2006 16:23:16 -0800, "Alan Wolfe" <alan.wolfe@xxxxxxxxx>
said:
> hmm ok
>
> what i had figured for processing the event queue was something like...
>
>
> while( !GameOver)
> {
>   while(eventqueue && eventqueue->fire < Now())
>   {
>     //process one event
>   }
>   //render everything
> }
>
> if you had an event in there that had a firing rate of 1ms and put
> itself back into the queue every time it ran, im assuming the
> processing of that event would take > 1 ms and so then you'd be caught
> in a loop forever.

You'd probably want to put a render event on the queue as well, rather
than treating it as special.  Enqueued with variable delay depending on
what you need to maintain a decent framerate.

Dave.
--
 Dave Slutzkin
 Melbourne, Australia
 daveslutzkin@xxxxxxxxxxx


---------------------
To unsubscribe go to http://gameprogrammer.com/mailinglist.html





---------------------
To unsubscribe go to http://gameprogrammer.com/mailinglist.html

Other related posts: