Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Different between sf::Event::KeyPressed and sf::Keyboard::isKeyPressed(...)  (Read 11312 times)

0 Members and 1 Guest are viewing this topic.

MichX

  • Newbie
  • *
  • Posts: 9
    • View Profile
Hi,
Could anyone explain me what is a different between check event by KeyPressed and check the same event by isKeyPressed outside the loop of events?
I mean when should i use first method and when secound?
When i tried check differences the results were the same so I don't understand it ;/
best regards!

G.

  • Hero Member
  • *****
  • Posts: 1532
    • View Profile
The KeyPressed event is triggered at the moment a key is pressed. It doesn't care how long the key is pressed, it only cares about the moment a key is pressed.

isKeyPressed doesn't care about the moment a key is pressed, it only cares about whether the key is currently pressed or not.

Use the event when you want to trigger something when a key is pressed.
Use real time inputs (sf::Keyboard, Mouse, etc.) when you want to get the state of something.

Note that the KeyPressed event may be repeated when you hold a key, at a frequency defined by your OS. You can however disable this behavior with the sf::Window::setKeyRepeatEnabled function.

MichX

  • Newbie
  • *
  • Posts: 9
    • View Profile
Thanks a lot @G.
I will try to understand what u said ;-)

Jesper Juhl

  • Hero Member
  • *****
  • Posts: 1405
    • View Profile
    • Email
It's really very simple.
When you press a key an event is put into a queue and waits there until you empty the queue by calling waitEvent() or pollEvent() , at which time you then notice that a key was pressed some time in the past (usually a few ms ago if you process the event queue every frame).
On the other hand, isKeyPressed() checks if the key is in fact pressed this very instant. So if the user pressed and released the key a few ms previously but is not holding the key down right now then you won't notice.

Hapax

  • Hero Member
  • *****
  • Posts: 3043
  • My number of posts is shown in hexadecimal.
    • View Profile
One other thing to note is that by using the KeyPressed event, there is no way to know if that key is currently being pressed. For example, if you need to know that the key specifically isn't being pressed, you would need to use isKeyPressed for that.
Selba Ward - SFML drawables
Kairos - Timing Library
Rectangular Boundary Collision - Rectangular SAT Collision

@Hapaxiation - Hapaxia on Twitter

Jesper Juhl

  • Hero Member
  • *****
  • Posts: 1405
    • View Profile
    • Email
Well, you also get key released events, so it is perfectly possible to keep track of whether a key is still pressed (modulo some event delivery/processing time, but that's negligible).

Hapax

  • Hero Member
  • *****
  • Posts: 3043
  • My number of posts is shown in hexadecimal.
    • View Profile
Well, you also get key released events, so it is perfectly possible to keep track of whether a key is still pressed (modulo some event delivery/processing time, but that's negligible).
Oh, that's true. Rarely very useful though  :P
Selba Ward - SFML drawables
Kairos - Timing Library
Rectangular Boundary Collision - Rectangular SAT Collision

@Hapaxiation - Hapaxia on Twitter

zsbzsb

  • Hero Member
  • *****
  • Posts: 1409
  • Active Maintainer of CSFML/SFML.NET
    • View Profile
    • My little corner...
    • Email
Oh, that's true. Rarely very useful though  :P

It is the best way in most circumstances to handle this. In fact this is the way the SFML Game Development book handles it.
Motion / MotionNET - Complete video / audio playback for SFML / SFML.NET

NetEXT - An SFML.NET Extension Library based on Thor

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6259
  • Thor Developer
    • View Profile
    • Bromeon
As SFML provides real-time input out of the box, I would say it (and not events) is the default approach to query the real-time input state. Otherwise you constantly have to write abstractions on top of it, and the differences are only notable in few scenarios.

The SFML Game Development book only does it that way in the beginning, so that the start is kept simple and we don't have to explain the difference between real-time and event-based input in the first chapter ;)
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development: first SFML book

wintertime

  • Sr. Member
  • ****
  • Posts: 254
    • View Profile
The problem with asking the current status is loosing information about keypresses and short keyreleases inbetween testing. Thats why the events are imo the correct way of handling it. They are provided always, so throwing them away and then asking for nearly equivalent information with worse accuracy is feeling awkward.
Directly testing the status may look easier for a beginner, but once they are understanding events they are not more difficult. Having to constantly check about 100 keys one by one when most often none is pressed is useless busywork and checking each key at a different time seems also kind of wrong.

Hapax

  • Hero Member
  • *****
  • Posts: 3043
  • My number of posts is shown in hexadecimal.
    • View Profile
Re: Different between sf::Event::KeyPressed and sf::Keyboard::isKeyPressed(...)
« Reply #10 on: February 11, 2014, 05:19:43 pm »
That's true for a lot of situations. However, sometimes you need to test what is going on right now, rather than what has happened in the past.
Selba Ward - SFML drawables
Kairos - Timing Library
Rectangular Boundary Collision - Rectangular SAT Collision

@Hapaxiation - Hapaxia on Twitter

zsbzsb

  • Hero Member
  • *****
  • Posts: 1409
  • Active Maintainer of CSFML/SFML.NET
    • View Profile
    • My little corner...
    • Email
Re: Different between sf::Event::KeyPressed and sf::Keyboard::isKeyPressed(...)
« Reply #11 on: February 11, 2014, 05:59:44 pm »
Lets be clear on this. sf::Event::KeyPressed is event based and only happens only when a key is pressed. sf::Keyboard::isKeyPressed(...) is realtime based and will let you know what is pressed.

Now each method has pros and cons and should be used when appropriate.

I will try to list of the pros and cons of each method, if anyone has anything else to add then say it. :)

Events
Pros
  • Useful for single actions
  • Only fires when a window has focus
  • Determine with close accuracy exactly when a key is pressed/released
Cons
  • Can not determine current key state unless flags are kept

Realtime
Pros
  • Useful for movement when keys are held down - no need to track state of keys
  • Determine at anytime the state of a key
Cons
  • Need to track window focus or else code will keep on preforming actions based on key state
  • Possible to miss key state changes
  • Unable to know if a key changes states in fast sequence
« Last Edit: February 15, 2014, 01:04:07 am by zsbzsb »
Motion / MotionNET - Complete video / audio playback for SFML / SFML.NET

NetEXT - An SFML.NET Extension Library based on Thor

Hapax

  • Hero Member
  • *****
  • Posts: 3043
  • My number of posts is shown in hexadecimal.
    • View Profile
Selba Ward - SFML drawables
Kairos - Timing Library
Rectangular Boundary Collision - Rectangular SAT Collision

@Hapaxiation - Hapaxia on Twitter

 

anything