I'm curious, can you explain why they shouldn't be used at the same time? Is the adverse reaction between the two a bug? My assumption is that pygame.event.get() and pygame.event.pump() are the only ways to flush the event queue and so must be used at all times (where the latter has more or less identical implementation of the former). If this is the case, then it isn't clear to me when pygame.key.get_pressed() can be used at all.
On Thu, Apr 5, 2018 at 3:37 PM, René Dudfield <ren...@gmail.com> wrote: > Hello, > > pygame.key.get_pressed() shouldn't be used at the same time as > pygame.event.get(). > > Just use pygame.event.get() instead. > > > cheers, > > > > On Fri, Apr 6, 2018 at 3:03 AM, gmail aprekates <apreka...@gmail.com> > wrote: > >> Greeting to all from Greece. >> >> Trying to learn pygame i started with a simple >> rect moving with keys that i've read in >> :https://nerdparadise.com/programming/pygame/part1 >> >> The problem i get with the following code is that >> the rect moves as if i pressed a key more than one >> times. >> >> >> import pygame >> >> pygame.init() >> screen = pygame.display.set_mode((400, 300)) >> done = False >> is_blue = True >> x = 30 >> y = 30 >> n = 1 >> pygame.key.set_repeat() >> while not done: >> for event in pygame.event.get(): >> if event.type == pygame.QUIT: >> done = True >> if event.type == pygame.KEYDOWN and event.key == >> pygame.K_SPACE: >> is_blue = not is_blue >> pressed = pygame.key.get_pressed() >> if pressed[pygame.K_UP]: y -= 3 >> if pressed[pygame.K_DOWN]: y += 3 >> if pressed[pygame.K_LEFT]: x -= 3 >> if pressed[pygame.K_RIGHT]: x += 3 >> >> screen.fill((0, 0, 0)) >> >> if is_blue: color = (0, 128, 255) >> else: color = (255, 100, 0) >> pygame.draw.rect(screen, color, pygame.Rect(x, y, 60, 60)) >> >> pygame.display.flip() >> >> >> after a lot of testing i think pygame.key.get_pressed() works like that. >> it read kbd's state but that state has inertia! i mean it will keep its >> values for some time so if you call key.get.pressed() too soon you'll get >> again the same state . i tried to simulate same behavior in SDL2 but no >> lack. but if i looked correctly pygames's src it relies on SDL1. i dont >> know if that's related. >> >> So i'd like some feedback. I could correct the program with controling >> the frame rate with pygame.clock. >> >> But i'd like to understand why in a basic tutorial a function like >> key.get_pressed with >> plain semantics works so unpredictable. >> Ref pages say: >> >> ( >> pygame.key.get_pressed() >> get the state of all keyboard buttons >> get_pressed() -> bools >> >> Returns a sequence of boolean values representing the state of every key >> on the keyboard. Use the key constant values to index the array. A True >> value means the that button is pressed. >> ) >> But is vague how that 'state' is created , accessed and how it's changed. >> It 'feels' low level >> stuff that involves how keyboard driver works . >> >> Thanks. >> >> >> chomwitt >> > >
