Re: Event handling

[Pierre Phaneuf <pp@ludusdesign.com>]

Christian Reiniger wrote:

> >Interesting.  Where's the heartbeat then ?  Not the timeflow,
> >but the "check for waiting events"...  Is it the emitter's reponsibility
> >to track the subscribers and push the events out to them,
> 
> Yep. The emitter generates some event and sends it to the subscribed sinks.
> That's somehow interrupt-like instead of the polling main loop thing.

Yes, exactly.

> >> Interestingly, I am reversing from my idea and no longer think it is
> >> good for games. That emitter/sink model is excellent, but it lacks
> >> serialization of events, since they don't go thru a single event queue.
> 
> Depends. Even in a game there are types of events that just don't need to
> be serialized "globally". E.g. if the player opens a door, that door would
> send out some "Action" event to the attached trap, an "play sound dooropen"
> event to the sound system and an "object visible state change" one to the
> gfx and AI systems so they can do the proper animating and visibility
> recalculation.
> These events have to be synced with each other (which is usually the case),
> but not with other events in the game.
> 
> So you have effectively many small event queues, each containing some
> related events.

Yes, interesting point.

I overgeneralized a bit what Carmack said. He was speaking strictly
about *input* events. Given that you do include the correct things as
"input events" (like he said, time is very useful when considered as
input, just like network, mouse or keyboard), you do not need to journal
other events.

How about this:

A queue class, with a "subscribe" method that let "event sink" objects
register with them and receive their events. That's enough abstract
objects to do most everything.

The real work would be implementing the diverse sinks. For example, the
input queue could be both a queue and a sink, subscribed to the
"network", "time", "mouse" and "keyboard" queues, and the journalling
object would be subscribed to that input queue, getting everything of
interest.

It would be good to reduce the number of times the message goes from
queue to queue, of course. But consider that in conventional cascading
event models, a completely ignored event can cascade all the way to the
root of the object tree without doing anything useful, which is a big
lossage.

-- 
Pierre Phaneuf
Ludus Design, http://ludusdesign.com/
.