#23797 - benjamin - Wed Jul 21, 2004 10:05 pm
I've seen a lot of examples that use polling (each frame I guess?) to check the bits in the input register in order to determine if input has been triggered by a user pressing any of the 10 buttons.
However, isn't it also possible to use interrupts to handle input (lower latency and more immediate response?).
Which is more desirable? I imagine that interrupts would be quicker to respond but use up many cycles to switch between user and interupt cpu modes..
When do you use on or the other, or do you always use just one of these two techniques?
#23799 - Touchstone - Wed Jul 21, 2004 10:14 pm
I think (but I'm not sure, it's been years since i did any gba programming) that you have to register a key that will respond to the interrupt request. For example, you register that when the user press A+B your interrupt is called.
I'm almost sure it's not like in Java or Windows for instance where you get a callback each time a key is pressed.
If a game would need more frequence sampling of the keys than per frame I guess they could do it more often, like twice or four times per frame, but I'm not sure how often the hardware is actually updating it's keystate register. Besides, the game probably doesn't do any actual game update more often then per frame so sampling more often would only help catch really fast presses, i.e. quicker than 1/60'th of a second.
_________________
You can't beat our meat
#23800 - poslundc - Wed Jul 21, 2004 10:59 pm
Most games only use the keyboard interrupt for detecting the reset-game key combination (A+B+Start+Select) and waking up from sleep mode.
An interrupt-driven input model is rather unpractical for most GBA games. Check the state of the keys once per frame and determine a course of action based on the keys every frame - that's the finite state machine way.
Interrupts don't happen particularly fast, either; you could wind up stealing a lot of processor time from the GBA.
Dan.
#23808 - tepples - Thu Jul 22, 2004 12:08 am
| Touchstone wrote: |
| I'm almost sure it's not like in Java or Windows for instance where you get a callback each time a key is pressed. |
You can set the joypad interrupt register into OR mode, where you get an interrupt every time any one of the chosen keys goes down. However, you do have to pay attention to debouncing the keys.
| Quote: |
| I'm not sure how often the hardware is actually updating it's keystate register. |
It seems to poll after just about every CPU cycle.
| Quote: |
| sampling more often would only help catch really fast presses, i.e. quicker than 1/60'th of a second. |
Canonical examples being a music game or a fighting game (Z-motion dragon punch anyone?).
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#23873 - sgeos - Fri Jul 23, 2004 9:44 am
One could set up an interrupt driven input list/queue that contains key press/release info and timing information. This is probably only useful for a fighting game, otherwise polling once a frame is probably more than enough.
I poll once every frame (if I care about input) and update press/release variables. The press variable contains the number of frames the key has been down.
-Brendan
#23881 - benjamin - Fri Jul 23, 2004 2:08 pm
It seems like for complexity's sake, interrupts don't make any sense.
However, if you were to count cycles, wouldn't interrupts be more conservative, since you're only using them when the input is actually made, vs. polling every frame?
Is there a concensus that commercial games mostly use polling?
#23884 - torne - Fri Jul 23, 2004 2:26 pm
Every commercial game I've disassembled uses polling (and that's quite a few). Polling once per frame takes a pittance of CPU cycles and is never, ever going to be a performance problem; you don't even have to do it during the vblank, if you are short on vblank cycles. Doing something so simple 60 times per second is hardly a bother at all on any processor made in the last fifteen years. =)
#23885 - poslundc - Fri Jul 23, 2004 2:43 pm
| benjamin wrote: |
| However, if you were to count cycles, wouldn't interrupts be more conservative, since you're only using them when the input is actually made, vs. polling every frame? |
In the realm of the theoretical?
You could theoretically monopolize the CPU by reentering the interrupt handler so long as the necessary keypress is being held down. Think about when you hold down the reset combination on most games: the game freezes up while it's being held, because the interrupt is resetting the game, then as soon as the interrupt exits it detects the keypress and loads back up again. No time for the CPU to do anything else.
Which means you need to be crafty with interrupts to get them working for generic input in the first place. But this is like using a hammer to pound in a screw when compared to just polling the keystate.
Dan.
#23892 - benjamin - Fri Jul 23, 2004 4:54 pm
Are you saying that holding down a key would fire continuous interrupts if you were handling key input with intterupts and not polling?
#23894 - poslundc - Fri Jul 23, 2004 6:04 pm
It depends on whether the interrupt fires only on the key-down or if it continues to trigger while the key is being held, I suppose. I don't know which it is.
Dan.
#23896 - Miked0801 - Fri Jul 23, 2004 6:32 pm
I'm pretty sure keypad int is edge down driver. Personally, I just poll - much cleaner.