I noticed people use both - but is there any empirical evidence when it's better to use one over the other?
This is related but not quite a 'why use either' or even 'why use both': Polling vs event driven input
I noticed people use both - but is there any empirical evidence when it's better to use one over the other? This is related but not quite a 'why use either' or even 'why use both': Polling vs event driven input |
|||||||||
|
Behind the scenes, typically input is polled anyway, just by the os behind your back ;) Regardless, even if you poll you're going to need to package state changes up in some way in order to use that information elsewhere in your game. And odds on you're going to package that up in an event. So realistically, going straight to events is going to save you the headache of state management and get you to where you need to go faster. Be aware, that you dont want to be sending "button down!" or "user pressed A" events into your game, you want to re-interpret those using your keymapping and translate them into actual things like "the user jumped" or "start the game". This will let you swap out controllers/input schemes/etc |
|||||||||||||||||||||
|
Event system is superior to Polling. The polling is a old technic that use innecesary CPU to test inputs. the event mechanism is better but more complex and require special hardware. As all game platforms have support for events, you should use them always. You may transform the input state to a "state" variable value to test if you really require to poll it. Events:
Polling:
|
|||
|
The issue of input events versus input polling is a matter of fidelity in most situations, and indeed, the reality is that one is simply a layer of abstraction built on top of another. Using input API's to directly read memory from a particular device gives you the option to control precisely how often you are reading input from a particular device, and in situations where you are attempting to simulate an analog/continuous function (driving/flying for instance) this is quite important. On the other hand, events tend to simulate discrete actions, and they work better for on/off type behaviors. Many systems use combinations of the two, based on their needs. |
|||
|