[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] multiple key downs

Austin Haas wrote:

I am having trouble receiving input from certain keys, after I have other keys held down. For example, if I hold down 'w', then I will not be able to receive 's' events, but I can receive every other key. There seems to be a pattern with keys that are directly above other keys, like 'q' to 'a' and 'e' to 'd'.

I am running this on Linux, but I tested on my WinXP machine to verify. On XP, I only have a problem if I hold down more than one key first. For instance, if I am holding down two keys, then certain keys wont register.

my script:
import sys,pygame
from pygame.locals import *


size = width, height = 400, 300
screen = pygame.display.set_mode(size)

while 1:

for event in pygame.event.get(): if event.type == pygame.QUIT:
elif event.type == KEYDOWN:
print event.key


I couldn't find any info about this in the docs or mail list. Has anyone else had issues with this, or is there a better way to catch simultaneous keys?


Re: Linux vs XP test

Was this tried on the same machine (with the same keyboard) or on different machines?

It may be related (somewhat) to the internal wiring of the keyboard (how the keys are arranged so that they can be scanned efficiently).
(Then again it might be *fun with drivers* ^_^)

I seem to remember on some keyboards that if I used the directional arrows on the numberpad with numlock turned off, it would give the keycode for the button and also the keycode for left-shift. (Since some stuff use left-shift as secondary fire, I had to make sure that num-lock was on when i wanted to use the numpad for moving...)

(On older systems, sometimes the keys were more or less arranged in a simple grid. Pressing any one key would connect one row to one column. If the machine drove the rows and looked at the columns, it could see which key was pressed. However, for some combinations of keypresses, it was not possible for the keyboard scanning (hardware) to tell which keys were pressed.

For example, imagine 3 keys in an L shape:
\ 0 1 2 3 4
0 O O O O O
1 O X O O O
2 O X X O O
3 O O O O O

Designating rows with R# and columns with C# the three keys connect respectively (C1,R1) (C1,R2) (C2,R2).
However, the actual effect in that simple keyboard is that all of (C1, C2, R1, R2) are connected together! (so it can't tell which three buttons are down, only two...)

Er... an even simpler effect would be if two buttons on the same column were pressed assuming that the machine drives rows, two rows would be shorted together through that column...

Some keyboards dealt with these problems by adding a diode to every keyswitch.

Some dealt with this by making it less of a grid (more rows, or more columns) and sometimes moving them around so that you are less likely to press two on the same (column?) at a time.

(Assuming touch typists, you wouldn't get two on a keyboard column since a single finger is assigned to work a single column) (but anyways... ^_^)