How is userinput kept independent of FPS when using for example Java Slick 2D or .NET XNA framework?

I have written a few 2D games in the past using libraries such as LWJGL (with a Slick2D wrapper) and the XNA framework, but one thing i have never been able to grasp (or have the need to) is how the user input is kept constant, eq not dependent on FPS.

I'm looking for a more generic answer rather than framework specific. I underst开发者_高级运维and it has something to do with time measured between frame updates ?

Thank you

I can't speak for some of those other frameworks, but I know that XNA basically lets you poll the current input state (are the buttons up or down?) whenever you like. You usually do it each frame.

What this means is, if your player happens to be a ninja and can hit keys faster than 60FPS, it is possible that they may hit a key (or mouse button) between pollings and you miss it. In practice it is almost never an issue.

If it does bother you, the solution to this problem is to hook the Windows message pump and receive keyboard up/down events.

For general gameplay it is really not worth the effort. Usually the only time where you really must capture every keystroke is when the user is typing text. So rather than capture key up/down events, you capture character events (WM_CHAR). This means you won't miss a keypress. But the more important problem that this solves is that it offloads key-to-character translation to Windows - allowing it to handle key-repeat, keyboard layout, shifted characters, etc, for you - allowing your game to behave like any other Windows application.

(Of course, if you can get away with just using the polling-based framework input stuff - go with that - it's much easier to implement and less platform-specific.)

The above only matters when you are detecting distinct key presses (eg: tap to fire this gun), as opposed to holding keys down (eg: accelerate this vehicle).

The alternate interpretation of your question is you are suggesting that a key may come up half way through a frame - how do you account for that, in a game with a discrete time-step?

Generally you don't worry about it. Just as 60 frames per second is fast enough to discretely calculate your game state and appear smooth and continuous to a human, it's fast enough to accept input.

But what happens if you're not running at 60FPS? If you're running at 30FPS (as you might on a mobile platform), then it can make your inputs - particularly analogue inputs - feel much smoother if you poll them at 60FPS. The easiest way to do this is to simply do two Updates for each Draw - if your Update is not too taxing on the CPU.