Events and EventHandlers
BlitzMax Forums/BlitzMax Programming/Events and EventHandlers
| ||
| I've been reading up on Events and EventHooks and I'm a little confused about how this could be a more efficient method of coding. Every time an event is emitted, it seems it needs an event handler to determine what the EventID is and to act accordingly. Is there a way to eliminate the need for an EventHandler?! To have specific objects listening for specific events?! and eliminate the process of certain objects saying "Oh this events not for me" |
| ||
| If you don't like events then use messages maybe. You can send them directly to an object. Checkout the Blitzmax help or use the search here, there should be some examples around. |
| ||
| The purpose of an event handler is to hand out events as needed. There is no way for something just to "know" if something is appropriate without some sort of test on some level... even in environments that allow event targeting more "naturally" something somewhere still has to determine where things go... Perhaps the solution you're looking for is more structural, such as organizing your "receiver" types so it's easier to just hand a given event to the correct stack of destinations etc... perhaps you're trying to handle all events in each receiver, rather than a master handler that will distribute your events to just those destinations that need them... sample structure Handler parses new event. event is type "AoE damage" distribute event to each "badguy" object each badguy object parses event upon determining it's an AoE damage event, they check their distance from the source (eventx/y) and adjust HP as needed based on distance and damage (eventdata) Next event handler parses new event event type is player "thrust" as determined by keydown event distribute event to player object player parses event upon determining it's a thrust event the player's momentum is adjusted as needed. events aren't inherently better or worse than polled input, they're just a lot easier to make very flexible. polled input is dependent on repeated nested tested generally, and is usually tied directly to the game loop as a result. Events can happen any time, be stacked (such as multiple AoE's happening for different reasons and each will be handled in order) OR replace existing events, etc. it's a different way of managing things. If polled input and game logic are simple then polled input is probably faster because you need less overhead (such as managing the event que and parsing results) however when things get complicated events can be like types, they can save you a lot of time, and the minimal overhead might be more efficient than the fixed linear structure of a polled system etc... They can also allow you to unhook rendering from other things more easily. such as having renders triggered by a timer event, and caught by an event hook (so they happen as fast as possible when the event is triggered rather than sitting in the que waiting to be retrieved). |
   |