--
TomW
Hi
You didnt misunderstand the problem. Your right, with timer triggerd
events it becomes the same as the update() approach. Only one thing:
with the update() approach it is more or less synchronous and with the
events aproach its more asynchronous. Many games are eventdriven, so
only something happens if an event is posted (it a sort of action and
reaction, or not?).
The overhad to implement such a system: I dont know how big it is and
how much it would slow things down. But I think it will not be much
slower as the update() aproach, because things are only done if an event
was posted. And its perhaps a bit more complicated to implement, thats
right, but Im not sure if it is more flexible or not. An obejct first
has to register to get the events it wants. Once done that it only
becomes the events it can handle. And now you can implement in the
eventhandling method what the object has to do and how to react. But I'm
a little affraid of the number of event it could exist in a single program.
If you want to add a new, lets say, control the only thing it has to do
is post events. Or network connection. Or any other object that triggers
an event.
I also have never implement such a system so I also only can guess how
it will be.
Perhaps a mixture of both aproaches could be used?
~DR0ID