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
\$\begingroup\$
\$\endgroup\$
3
asked Oct 7 '13 at 13:46
-
1\$\begingroup\$ Seems a little broad of a question, but generally the choice is based on the needs of the game/app. If the requirement is "when the X key/button/etc is down, fire thrusters", then polling. If the requirement is "when the X key/button/etc is pressed, toggle thrusters", then events. EDIT: text entry - always events. \$\endgroup\$ – PlayDeezGames Oct 7 '13 at 13:50
-
1\$\begingroup\$ Like @PlayDeezGames said, it really depends on how your game is built. You'll know what type of input events you want for your game after doing a bit more research and/or development for you game. That's why this isn't a very good question for this site. \$\endgroup\$ – TheNickmaster21 Oct 7 '13 at 14:35
-
\$\begingroup\$ How exactly does this differ from the linked question? \$\endgroup\$ – Anko Dec 14 '14 at 20:51
Add a comment
|
\$\begingroup\$
\$\endgroup\$
8
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
-
\$\begingroup\$ "Behind the scenes, typically input is polled anyway, just by the os behind your back ;)" That is false. \$\endgroup\$ – Adrian Maire Oct 8 '13 at 8:19
-
-
\$\begingroup\$ Don't they use hardware interrupts @MattD? \$\endgroup\$ – Vaughan Hilts Oct 9 '13 at 1:59
-
\$\begingroup\$ edwardbosworth.com/CPSC5155/PH4/Ch06/… This file explain basics I/O mechanisms. \$\endgroup\$ – Adrian Maire Oct 9 '13 at 6:47
-
3\$\begingroup\$ Aren't interrupts just polling at the microcode level? \$\endgroup\$ – Incredulous Monk Oct 16 '13 at 23:10
\$\begingroup\$
\$\endgroup\$
Polling mechanism
The software check for a condition repeated times until something is ready.
E.g. Childs in a car:
Child: Did we arrived yet?
Mom: No;
Child: Did we arrived yet?
Mom: No;
.... (repeat many times)
Child: Did we arrived yet?
Mom: Yes
Events
The condition itself is able to inform the software when it is ready.
E.g. Childs in a car:
Mom: I will tell you when we arrive
Child: Ok, I am going to read in the while
... (child reading silently)
Mom: We arrived!
Child: Great!
Events mechanism is superior to polling: due to several reasons:
- The CPU does not spend time in checking the condition
- The CPU can do something else in the while
- The latency between the moment when the condition has changed and the software reaction is shorter: in the polling, the worse case is the delay between polling, while in the event mechanism, the minimum latency could theoretically become close to zero.
There are a few benefits for the poll mechanism:
- Require much simpler hardware, which is not a concern in Gaming.
- The software does not require event loop, which is simpler.
Summary: As all game platforms have support for events, you should use them always.
Why to use both
I do not know about any real situation in which polling is recommended in game development.
Obviously, polling is extremely important in other fields, for example signal sampling.
\$\begingroup\$
\$\endgroup\$
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.
