[Solved] Input tied to frame rate.

[Strikerklm96]

I have my physics engine, which always updates at 60Hz.
Then I have my Window, which can be a variable FPS with setFrameRate.
As it stands, the game will reach the physics update and do a physics calculation as many times as it needs until it has reached the number of updates expected. (so if you are running at 30 fps, it will update 2 times, 20 fps, 3 times, ect.)
The problem is that player input, and the rest of my game loop, seems to be tied to frame rate. The physics input needs input from the keyboard each update, because if you press UP, you need to accelerate each update. If someone sets their frame rate to 30 fps, the physics engine is still at 60HZ, but now only half of those ticks are getting player input and accelerating the player.

Possible solutions I have thought of:
1. Ideally I can get player input independently of frame rate. This would be great!
2. Force the same rate for everything. This is bad if someones computer just can't keep up. Then that person couldn't play with someone else, cause their game would constantly be behind.
3. Record the players input, and keep it until we get new input, and have each physics tick act on whatever information was recorded. This is better than 2, but not better than 1.

The real problem is I don't understand how sf::event and sf::Keyboard are tied to the window. Do they only get updated each frame, or are they a continuous and independent from it?

[Laurent]

sf::Keyboard directly reads the keyboard state, it is not tied to windows.

But I don't understand your problem. At worst you'll get some lag right after pressing the key, but once it's down the physics engine know that the player is accelerating and there's no reason to skip anything.

[Strikerklm96]

Ok, thats good to know. The issue is that right now, when I check for input, it will tell the physics to accelerate on the next physics tick. But if you do two physics ticks right in a row, the second tick wont have any forces involved from player input. The keyboard thing solves it though, so thanks.

[Strikerklm96]

Do the functions associated with Mouse read immediately from the mouse state?
So these:
sf::Mouse::
isButtonPressed();
getPosition();
getPosition(const Window& relativeTo);

Thanks again.

[Ixrec]

Well, you can see there's no window involved in any of those calls, so that's a pretty big hint.

And you should always try checking the documentation for questions about specific classes/functions: http://sfml-dev.org/documentation/2.1/classsf_1_1Mouse.php#details

This class allows users to query the mouse state at any time and directly, without having to deal with a window and its events.

[wintertime]

Nothing is preventing you to poll for input events once per call to update, by moving it into the inner loop, and then setting/resetting the acceleration only on keydown/keyup events, without automatically resetting it every update.

[Strikerklm96]

Nothing is preventing you to poll for input events once per call to update, by moving it into the inner loop, and then setting/resetting the acceleration only on keydown/keyup events, without automatically resetting it every update.

Nothing is preventing me, except it is a pain to have to store the states of tons of keys (these keys do more than just accelerate).
It's easiest to just repoll the keyboard and mouse right before each physics update. So it's easiest and achieves the best results, since it better simulates a continuous physics simulation.

[wintertime]

I would value correctness over a convenience of not having to add a few variables. The problem with checking the current status of keyboard/mouse is that its from a single point in time, that is dependent on the random time fluctuations of the update loop, and asking for 2 keys they would already be checked on a slightly different point in time. With events the whole timespan is covered without the chance of missing keypresses in some cases.
For many things its actually better to only react to changes, so there would be no need to remember the status. For other things it may be better to only remember what should be done (for example, accelerate) and give this info to other parts of your game, otherwise too many parts have to know about keys and how they are translated.