#17491 - mathieu - Tue Mar 09, 2004 3:35 pm
Hi, folks !
My question is a bit related to GBA development, but also a bit related to emulator development... So I guess "off-topic" is the best place. I was wondering if anyone knows up to how many keys-per-second can one press consecutively on a keypad. Even if you don't know, your experience of gamer may give you a thought that I'd love to hear.
#17493 - poslundc - Tue Mar 09, 2004 4:15 pm
It depends how quick your thumbs are. :P
Seriously, though, the GBA (like most game systems) isn't event-driven at a certain frequency. A key is either down or it is up. It is up to the game to decide how often it wants to check. Most GBA games run at 60 FPS and will check the state of the keys once each cycle, so that amounts to a rate of 60 times per second. There is nothing to stop the programmer from sitting in a tight loop that checks for a keypress on the order of millions of times per second, though.
Dan.
#17496 - mathieu - Tue Mar 09, 2004 4:38 pm
| Quote: |
| Seriously, though, the GBA (like most game systems) isn't event-driven at a certain frequency. |
Yep, but an emulator is - it would be too costly to checkout for a key change on the host system after each single native CPU instruction interpreted, just to simulate the "asynchronous" nature of the GBA keypad.
Refreshing the virtual GBA paddle at a rate of 60 times per second seems good enough. My thumbs ain't so fast ^_^ .
#17499 - ampz - Tue Mar 09, 2004 5:10 pm
| mathieu wrote: |
| Quote: | | Seriously, though, the GBA (like most game systems) isn't event-driven at a certain frequency. |
Yep, but an emulator is - it would be too costly to checkout for a key change on the host system after each single native CPU instruction interpreted, just to simulate the "asynchronous" nature of the GBA keypad. |
Why?
A emulator can certainly check the state of the keyboard keys when the GBA code reads the keypad IO register.
#17500 - poslundc - Tue Mar 09, 2004 5:27 pm
Of course, you also need to be able to handle keypad interrupts, which if you strictly want to follow the GBA's specification have to be tested for every cycle. This might be the kind of area where you can get away with doing a reduced-frequency check... I dunno.
Dan.
#17502 - tepples - Tue Mar 09, 2004 6:36 pm
| mathieu wrote: |
| it would be too costly to checkout for a key change on the host system after each single native CPU instruction interpreted |
Would it be too slow to call the host system's input polling on every emulated scanline where 0x04000130 is read, or on about a dozen random scanlines throughout the frame if keypress interrupts are enabled? Some programs use keypress interrupts with the timer to generate a random seed and may detect that all keypresses happen on the same scanline, interpreting it as "you are running this on an emulator, you dirty pirate". I'll have to check it against the Game Boy Player, which may in fact poll only once every frame. Does Windows itself have keypress interrupts, that is, can DirectInput unblock a thread immediately when the state of a key changes?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#17506 - ampz - Tue Mar 09, 2004 7:13 pm
| poslundc wrote: |
| Of course, you also need to be able to handle keypad interrupts, which if you strictly want to follow the GBA's specification have to be tested for every cycle. This might be the kind of area where you can get away with doing a reduced-frequency check... I dunno. |
Why?
The PC fires a interrupt when a key is pressed, the emulator can act on that interrupt.
#17510 - tepples - Tue Mar 09, 2004 7:33 pm
| ampz wrote: |
| poslundc wrote: | | Of course, you also need to be able to handle keypad interrupts, which if you strictly want to follow the GBA's specification have to be tested for every cycle. This might be the kind of area where you can get away with doing a reduced-frequency check... I dunno. |
Why?
The PC fires a interrupt when a key is pressed, the emulator can act on that interrupt. |
First off, the operating system may prevent an application from being able to see that interrupt.
Second, not everybody plays with a keyboard. I personally play with an N64 controller through a USB adapter. Are USB joystick devices able to send interrupts to the host PC, or do they have to be polled?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#17521 - Lupin - Tue Mar 09, 2004 8:54 pm
Why do we actually need the input interrupt?
I don't really understand for what i can use the input interrupt (other than getting key press events)...
#17528 - dagamer34 - Tue Mar 09, 2004 10:43 pm
Some games like MegaMan Battle Network don't actually poll the key register but instead wait for an interrupt to change the state of some variable in the ROM. If you look in VBA, it will generate a keypad interrupt if any key is pressed if you want to know.
It saves cycles and some battery power in the long run.
_________________
Little kids and Playstation 2's don't mix. :(
#17532 - Lupin - Tue Mar 09, 2004 11:06 pm
But how do i differentiate between key up and key down event?!
#17554 - poslundc - Wed Mar 10, 2004 3:48 am
| Lupin wrote: |
| But how do i differentiate between key up and key down event?! |
I'm fairly certain that the interrupts are triggered on key-down only.
Probably the most widespread/obvious use of the keypad interrupt (I'm only speculating, but it's an educated speculation) would be to do a soft reset on the A-B-Start-Select combination.
Dan.
#17605 - dagamer34 - Thu Mar 11, 2004 1:11 am
| poslundc wrote: |
| Probably the most widespread/obvious use of the keypad interrupt (I'm only speculating, but it's an educated speculation) would be to do a soft reset on the A-B-Start-Select combination. |
Yeah, he's right about that. Fire up any Nintendo-published game and if you look at the key interrupt register, it will be set to A+B+Start+Select. That way, games don't need to constantly check for it in the main loop.
_________________
Little kids and Playstation 2's don't mix. :(
#17635 - mathieu - Thu Mar 11, 2004 5:12 pm
| tepples wrote: |
| Does Windows itself have keypress interrupts, that is, can DirectInput unblock a thread immediately when the state of a key changes? |
I don't know a lot about windows/DX, as I am planning to work with Linux/SDL. Here keypresses are handled by "events" : define a thread that loops calling a function that waits for events (I presume this function is a sort of "system call" that halts the thread and waits for the system to send a wake on interrupt signal) and when an event is returned check its type, and do whatever you want with it.
I guess I can use that, using event-handlers to simulate the asynchronous peripherals (the keypad...), and a classical system of "I call you peripheral device simulation code every N cycles" for the synchronous ones (video, sound, and so on). But I can say good-bye to my idea of a common peripheral interface... Hard luck.
Thanks for your answers everyone, it's been really helpful :-).