Re: Event handling

[Bert Peers <rat@larian.com>]

Pierre Phaneuf wrote:

> That idea is from the Java 1.1 event model. It is a generalized version
> 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,
or are sink and emitter both subscribing to a generic queue
thing which accepts emitter's stuff and waits for a
"Heartbeat" call to flush the stuff to the sink ?  In the latter
case both are the same, you just replace one queue with
several.  I guess.

> The downside is that it adds bookkeeping, emitter keeping tab of all the
> sinks they must send events to, sinks remembering to unsubscribe
> themselves in due time (usually in the destructor)...

This would probably mean making every emitter derived from a base
emitter class, which is probably a hacked up (so to speak) queue.
Which means option 1 and option 2 above are really the same..

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

Yes, but would you want that ?  Out Of Order is the hot thing
everywhere, why not in the event loop :)

> But the most innovative idea in the Carmack rant was to make
> *everything* into an event, including time, so that just recording the
> events occuring would enable perfect demo recording, unlike Doom (which
> could get "out of sync"). You could even automate testing using this,
> and you're not even forced to follow real-time, you can make testing a
> batch job!

We're using this technique, but it doesn't really have to do anything
with emitter/sink versus single-queue.  Basically any scheme were
the client is a "dumb terminal" thing (as in Quake) is ready for this :
just replace the communication with the server with a stub that
replays what came back from the server when actual play was
going on.  If you squeeze *everything* through the server,
including mousemoves you also get the right look-at in FPS
or mouse moves in select-and-click 2D games.

> For example, say you emit a "time tick" event every 10 ms. In
> a real game, the tick would happen every 10 ms, as supposed to, but you
> could batch-test games by simply sending them as fast as possible, with
> the necessary input in between the ticks. The game would go very fast,
> but the game would be identical to when it was recorded, just faster!

Another advantage we discovered is that if you're careful what you
log, you can start kicking out components and still have the playback
going correctly.  As a trivial example, you should be able to kick
out the sound playing module and still see the right visuals, you just
replace the sound lib with a stub that ignores those replayed server
events which consider sound.  The same is possible for graphics
output or even some AI (client side server predicition etc, it can
get compilcated).  Which is very very handy if the game dumps
core in frame 174635.  Kick out modules until it doesn't crash
anymore !

Bert
--

-=<Short Controlled Bursts>=-