I have a bunch of debugging tools assigned to function keys. They are very randomly unresponsive. They always work, but once I notice they become unresponsive I have to hold down the key in order for it to register. This does not occur 100% of the time. The other interesting thing is that while this is happening game pad input is completely unaffected. I’m using KeyboardState and checking current input (pressed) and previous input (released). I’m using the current development build of MonoGame, Visual Studio 2017, and this occurs on both my Windows (Direct X) project and Open GL project.
I’ve set break points and verified the key presses simply do not register when this starts occurring. Here’s another interesting tidbit: I have one line of code that simultaneously checks the Esc key and the Back button on the controller (they are in and OR statement). I’ve noticed that the the Back button has been unresponsive at times as well. Any other game pad input (which is never checked in conjunction with keyboard input) is always 100% responsive.
What’s your framerate like when it becomes unresponsive? Is it maybe lower than when it’s more responsive?
You are querying the keyboard state once every frame. A keypress will only be recognized, if the key is down, at the exact moment the keyboard state is queried. When your framerate is low, the keyboard state is queried less often, so there’s a higher chance of missing a keystroke, especially when it’s very short. One way to deal with that situation, is to make sure your framerate is high. I know, easier said than done.
The standard keyboard input method is not ideal for text input for example. MonoGame offers a different method, that’s mainly intended for text input. This method does not have the problem of missing keystrokes.
I think it would be nice if the standard input method also behaved like that, meaning that it never misses a keystroke completely. I don’t know how hard that would be to implement. The same goes for mouse clicks and controller input.
I still haven’t made any headway with this. The function keys and esc key are very responsive when I initially run the game, but after it’s been running a minute or two they become randomly unresponsive. Holding them down until they decide to register works (it only takes a second or less). The game’s frame rate is an unwavering 60fps and controller input is completely responsive at all times. I’ve tested on two different PC’s and the issue is present on both… No one else has encountered this? Based on some research I’ve done I’m wondering if it could be because the game is running in windowed mode. Apparently, Stardew Valley had issues with keyboard input as well and some Steam users commented about running in full screen to fix. I can’t test that right now though.
If it’s not the framerate, then I really don’t know what else could cause this.
Did you already try with another project, like a small input test, or a MonoGame sample? Is the problem specific to your project, or does it happen with any project?
I’ll have to do some more testing. I suspect it has to do with how I’ve implemented my Update() and Draw() loop. I’m using isFixedTimeStep = true, but I override base.Draw() so that it’s never called. I then call call my Draw() at the end of each Update(). FixedTimeStep does not call call Draw() after each Update() by design. This gets rid of the hitching that’s often seen when when using the built-in fixed time step.
However, this implementation causes isRunningSlowly to be constantly set to true even though my Update() -> Draw() cycle is only 6ms. I have tried to remedy this by setting isRunningSlowly to false at the beginning of each Update() and Draw() call. If this is indeed the culprit then it is weird it impacts keyboard input, but not game pad input. However, I don’t know what is going on under the hood with the fixed time step implementation, so anything is possible.
I’ll undo the base.Draw() override and run the fixed time step mode it’s intended way and see if I encounter the same issue. If not, then I’ll know what the issue is (and I’m back to square one as far as running fixed time step mode, but correcting the hitching…).
If I undo the base.Draw() override and run fixed time step mode it’s intended way then keyboard input is fine. So, my guess would be that keyboard input is affected since isRunningSlowly is constantly ‘true’ when I override base.Draw() and call the main Draw method at the end of my Update(). Kind of a bummer as I can’t have keyboard input affected. Otherwise, this ‘hack’ performed extremely well (as long as you keep your Update/Draw cycle well under 16.6667ms).