mspaintmaestro: > I'm curious, can you explain why they shouldn't be used at the same time?
Iterating over the event queue will pump events, which will process/check key state (as you mentioned). This may lead to small differences between what your game logic gets when checking get_pressed or the event queue. Consider the situation where game logic is changed while iterating over the event loop, then checking get_pressed() at some other time. You may have caught a keypress during the event queue, but get_pressed will say the key is/was not pressed. So, you cannot make the assumption that each moethod will return the same result over the lifetime of a frame. Hope I explained it well enough. https://github.com/pygame/pygame/blob/master/src/event.c#L832 chomwitt: Please refer to the SDL documentation which defines the behavior of `get_pressed`: It explicitly states: "Gets a snapshot of the current keyboard state" http://sdl.beuc.net/sdl.wiki/SDL_GetKeyState And in pygame, which is a wrapper around it: https://github.com/pygame/pygame/blob/8aeb2f72047218043b2353dae4ccb288eaa5d814/src/key.c#L74-L104 > The case of state's duration be only the smalled time granularity the system supports would be impractical . Maybe you'd never catch the key pressed Yes. The state returned from get_pressed is based on data from the event queue. If you want higher resolution of time, then use the event queue method and poll more often. > How long is that duration ? and could be set by the programmer? The duration depends on how often you are checking the event queue. For a typical program, that is 60 times a second, or about 17ms. If you want more precision, then you will need to poll the event queue more often. On Thu, Apr 5, 2018 at 6:41 AM, <apreka...@gmail.com> wrote: > > > Τη Πέμπτη, 5 Απριλίου 2018 - 2:10:55 μ.μ. UTC+3, ο χρήστης Greg Ewing > έγραψε: >> >> >> ........ >> It returns a map telling you which keys are being >> held down at the moment you call it. That's what it >> means by 'state'. >> >> -- >> Greg >> > > I understand the semantics i think. But the devil ise hidden in the > details. > The point that made my curious and littlie anxious for the unpredictable > behavior of such > an introductory tutorial is what we mean by 'moment' . key.get_pressed() > will be called in moments A and B , and will return > that button UP is pressed. So button UP was pressed down both moments A > and B. The case of state's duration be only the > smalled time granularity the system supports would be impractical . Maybe > you'd never catch the key pressed. So you keep > the state for some duration. How long is that duration ? and could be set > by the programmer? > > chomwitt >
