Re: [pygame] pygame.key.get_pressed() works unpredictably

[Leif Theden]

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  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,  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
>>
>
>

Re: [pygame] pygame.key.get_pressed() works unpredictably

[Leif Theden]

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,  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
>

Re: [pygame] pygame.key.get_pressed() works unpredictably

[aprekates]

Τη Πέμπτη, 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

Re: [pygame] pygame.key.get_pressed() works unpredictably

[Greg Ewing]

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 step each time you
press a key, it would be better not to use get_keys
at all, and just drive it from key events, the way
you're handling the space key.

But is vague how that 'state' is created, accessed and how it's 
changed.


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

Re: [pygame] pygame.key.get_pressed() works unpredictably

[mspaintmaes...@gmail.com]

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  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 
> 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 onSDL1. 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
>>
>
>

Re: [pygame] pygame.key.get_pressed() works unpredictably

[René Dudfield]

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 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 onSDL1. 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
>

[pygame] pygame.key.get_pressed() works unpredictably

[gmail aprekates]

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 onSDL1. 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