Re: Event handling

[Christian Reiniger <warewolf@mayn.de>]

Bert Peers wrote:

>> of what you said. Instead of processing everything in the main loop
>> (with something like a giant switch statement), sinks subscribe to
>> emitters, which will send events directly to the interested sinks.
>
>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.

>> 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.

Cu
	Christian
--

Install once, run forever. Linux.