Part of it could be do to your processor speed, but mostly it comes
down to the fact SFML uses an event driven keyboard input system.
There are two types of input systems. The first is the direct input
system used by DirectX and the second is the more common event driven
With DirectX DirectInput when the library is properly initialized it
acquires direct and exclusive access to the keyboard, mouse, joystick,
whatever. As a result the program has direct access to and full
control of the keyboard while the program is in the foreground. It can
poll the state of the keyboard say 50 times a second, store the state
of the keyboard in a buffer, and act upon one or more keyboard
commands at the same time. This is obviously much faster because the
program doesn't have to wait on the operating system like Windows to
dispatch the state of the keyboard through various levels until the
application is signaled with a key down or key up message.
With an event driven system such as that SFML uses the operating
system has control of the keyboard, mouse, etc and is in charge of key
down and key up events. It stores these events in a message queue
where it is later dispatched to whatever application happens to be
waiting for a key down or key up event. In normal day to day
applications like Notepad nobody seams to notice that this is
happening because speed isn't critical to using the application. In
games though the event driven system is more noticable because people
expect lightning fast performance, reaction times, etc but often have
to wait for the operating system to catch up and process all of their
key presses and releases at a rate higher than it was designed to do.
For example, I've seen or heard of gamers that bang there keyboards
hundreds of times a second trying to get the program to react faster.
The problem with that approach is unknown to them they are making
matters worse by flooding the message queue with more events to
process and dispatch. That kind of behavior slows the input down
rather than speeds it up, because they aren't giving the OS time to
catch up with there rapidfire key presses and releases.
A case in point. i'm sure you have seen times where Angela is walking
or running in the game and the game will freeze for half a second or
so and continue. This is in part do to the fact the game is trying to
poll the message queue for input messages, but the operating system is
delayed do to trying to catch up with x number of events being
processed at once.
The solution, which I have introduced in beta 16, is to slow the
application down and have it poll the message queue maybe 40 times a
second instead of 50 times a second or whatever. That way the
application will give the CPU some breathing time to process the queue
without constantly sending and recieving messages it can't keep up
with. Plus I have decided to drop some events that are unnecessary
repetes. I think you will find beta 16 has a smoother input system
simply because I've backed off on sending and recieving input events
at a pace the OS can't cope with and handle.
So the short answer is the input is a bit slower because we don't have
direct access to the keyboard. We have to poll the operating system
itself for what the keyboard is doing, and that isn't the quickest and
most reliable way to get input It just happens to be the most
practical when multiple operating systems are involved.
On 10/17/10, Kevin Weispfennig <weis...@googlemail.com> wrote:
> I am wondering... Just curious, what makes the arrow keys so non-responcive
> in the main menu? Not that I have a problem with it, which I don't, but I
> am just wondering as to why this is...
Gamers mailing list __ Gamers@audyssey.org
If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org.
You can make changes or update your subscription via the web, at
All messages are archived and can be searched and read at
If you have any questions or concerns regarding the management of the list,
please send E-mail to gamers-ow...@audyssey.org.