I'll just also add, that a fair rule of thumb for a modern operating system, is that you should not assume that your input is faster than say 125hz on usb. That give you a minimum of about 8ms. That may be an ideal number, and it would probably be better to assume your inputs are at least 10ms or older, and any presses faster than that will be lost. SDL's timer is also limited to 10ms intervals, but i'm not sure if that affects the pooling or not. For games, pygame is fine with these limitations. I wouldn't run a real-time robot on the platform, however. :D
On Fri, Apr 6, 2018 at 12:56 PM, Leif Theden <leif.the...@gmail.com> wrote: > 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/8aeb2f72047218043b2353dae4ccb2 > 88eaa5d814/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 >> > >
