I am implementing a Keyboard class to extend the XNA keyboard class to work using events. I have got the basics working fine but I thought I would try and integrate it with the GameWindow code (Code here) which currently uses a simple input class to manage current and previous keyboard states.
The way their input with GameScreens work is they call HandleInput on the screen that has focus. Clearly this won't work in an event based system.
As far as I can see, I have two options. Either in the GameScreen class, when you register an event, the method called must first check if it is active before responding to the input. However, this potentially means many calls to empty functions and the user must remember to do this check with every event method.
The other option is the Window registers to a list of specified events on receiving focus and de-registers events when it looses focus. I think this solution is nicer, but I wasn't sure if there was a large performance cost to registering/deregistering.
Thanks,
[.net] Cost of registering and deregistering events
Perhaps a better way of looking at this rather than performance cost of registering/deregistering callbacks, is the cost per unit of real-world time. Focus switches occur very infrequently, and humans don't type very fast. If you're making a decision between a awkward implementation that executes in half the cycles, or a friendly implementation, those cycles get paid infrequently enough where you likely won't even notice the overhead. Thus, the real choice you're making is between friendly and awkward, and that choice is pretty obvious.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
