Different between sf::Event::KeyPressed and sf::Keyboard::isKeyPressed(...)

[MichX]

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

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]

Thanks a lot @G.
I will try to understand what u said ;-)

[Jesper Juhl]

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]

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.

[Jesper Juhl]

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]

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 

[zsbzsb]

Oh, that's true. Rarely very useful though 

It is the best way in most circumstances to handle this. In fact this is the way the SFML Game Development book handles it.

[Nexus]

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

[wintertime]

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]

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.

[zsbzsb]

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

[Hapax]

[some good points]

Hear, hear!