Event system ideas

Nectar · Post by **Nectar** » Sat Jun 03, 2006 10:23 am

So i've finished my event system for my project, and it works fine..

There are two basic methods for injecting events into the sytem, timed events (that happen based on a timer), or static events (ie, software generated events for spawning NPCs, or keyboard events that kind of thing).

The static event system I think is fine, but I'm hung up on the timed system.. Currently, it runs through every second, and all the events have a second accuracy as well. Basically, I'm undecided on if the timer should have better accuracy or not..

But if it has better accuracy, say every half second, that means that the system will be processing through the events twice a second. With say 100 events, that could chew alot of time i think.
But with less accuracy, it means that the event system is limited in what it can do.

Any ideas? Which is better, accuracy or speed?

Klasker · Post by **Klasker** » Sat Jun 03, 2006 1:24 pm

In my opinion, standardizing timed events to a fixed interval is a bad move. Maybe you should look into a way to use arbitrary time intervals. I don't know how your event system works so there is little advice I can give about the actual implementation.

Kidinnu · Post by **Kidinnu** » Sat Jun 03, 2006 1:25 pm

Umm, one of the classic ways to do this would be closer to:

* keep the list of events sorted for which comes soonest; this is O(nlogn) and probably performs much better than that, depending on the exact distribution of event times you've got.

* you're probably not going to want to set an interrupt timer, so just check once per frame to see if the first event in the queue is due. if it is, execute it and check the next.

This ties the variable overhead to the event *generation*, not the event handling.

The accuracy/speed tradeoff really depends on the kinds of events you're using in your system, but I think you're making a much coarser-granularity system than you need to.

hybrid · Post by **hybrid** » Sat Jun 03, 2006 1:25 pm

I think your style of processing timed events is not good at all. Why do you poll all events just to see that every some seconds just one of the events happens? Polling is only good if most of the events happen all the time.
A typical way of processing timed events is to store the events on a time line. Then you just have to check whether the first event happened. Insertion can be done with binary search so it shoudl be quite fast. And inserting periodical events can be done just after processing the last (and only) event of that type in the queue.

Nectar · Post by **Nectar** » Sat Jun 03, 2006 1:44 pm

hmm,
I think the best way to go would be to use the time line idea, i'm a little concerned though that the tree would become side heavy, in that if I add events linearly (ie, first event is 5 seconds, second is 7, etc) then it looses efficency, but I doubt it would be worse than the current implementation

To be honest, i'm not sure if I need timed events much so I'll probably only have 10 or so active at any one point, compared to the static events.

I'll have to see what kind of tasks i'm using this for. Mabye then I can see the best route to go

stodge · Post by **stodge** » Sun Jun 04, 2006 7:42 pm

Set a bunch of timers, and only decrement the one that is due to expire first. When it expires check for any others that have expired. Action them.

When you schedule a new timer, if it's due to expire before the one you're currently decrementing, replace it with the new one.