Re: [pygame] multiple key downs

[Fred Burton <flbl@go.wifl.at.org>]

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 *
>
> pygame.init()
>
> size = width, height = 400, 300
> screen = pygame.display.set_mode(size)
>
> while 1:
>
> for event in pygame.event.get():  
>  if event.type == pygame.QUIT:
>   sys.exit()
>  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?
>
> -austin
>
>  
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...  ^_^)