[gameprogrammer] Re: Fixed Rate Logic

oh ok makes sense

I just gotta make sure events don't take longer than their "rate of
fire" if they are continually added to the queue it sounds like

fun stuff!!

On 12/6/06, David Olofson <david@xxxxxxxxxxx> wrote:

On Thursday 07 December 2006 01:23, Alan Wolfe wrote:
> 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're forgetting that this processing is happening a lot faster than
real time. If it isn't, you're going to have quite some trouble
squeezing any rendering and other work into the main loop. ;-)

What happens in this 1 ms rate example is indeed that the event
respons enqueues another event that is processed immediately - but
*only* as long as the generated event has a timestamp < now!

The first event that lands beyond the current frame will break the
feedback loop, as that event won't be handled until the next frame,
which also means the handler won't get a chance to enqueue any more
events until the next frame.


//David Olofson - Programmer, Composer, Open Source Advocate

.-------  http://olofson.net - Games, SDL examples  -------.
|        http://zeespace.net - 2.5D rendering engine       |
|       http://audiality.org - Music/audio engine          |
|     http://eel.olofson.net - Real time scripting         |
'--  http://www.reologica.se - Rheology instrumentation  --'

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





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

Other related posts: