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
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
Τη Πέμπτη, 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
gmail aprekates wrote:
The problem i get with the following code is that
the rect moves as if i pressed a key more than one
times.
For me, it works the way I would expect from the code,
i.e. the rect continues to move as long as an arrow key
is held down.
If instead you want it to move one
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
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 wrote:
> Greeting to all from Greece.
>
> Trying to learn pygame i started with a
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