Keyboard input, caused by mouse

Windows UWP
1

All keystrokes in my UWP 10 game are delayed by mouse input. It has two effects:

  1. When holding any key, the input continues after I physically release. This ends when I stop moving the mouse around quickly.

  2. When I press a key, while moving the mouse around quickly, the input is not received until I stop moving the mouse around.

This is event that is firing late.

window.KeyDown += CoreWindow_KeyDown;

What’s the cause? How can get instant keyboard state?

2

For a normal windows game, I use something like

Keystate currentState = keyboard.getstate();

If (currentstate.iskeydown(keys.F)
{
//FIRE!!!
}

3

That’s backed by

List _keys;

Which is populated by:

Microsoft.Xna.Framework.Input.Keyboard.SetKeys(List keys)

And the incoming value keys comes the events in InputEvent.cs, where the events are firing late.

4

Sounds like maybe only 1 event is consumed each frame… Can you open an issue on GitHub @MuletTheGreat?

5

If you are working from source try this patch:

Optionally, apply this one too that removes the slow lock() on every input event.
https://github.com/MonoGame/MonoGame/pull/5158/commits/80130b920322bde0d2e60a77917429ed3c294c81

Note that CoreIndependentInputSource was broken from day one on tablets/Touch and I still don’t use it on published games because it kills GPU performance. If you have some time please vote on uservoice to get it fixed.
https://wpdev.uservoice.com/forums/110705-universal-windows-platform/suggestions/16521550-fix-coreindependentinputsource

6

I’ve opened an issue.

7

If I attach to either the CoreWindow OR the CoreIndependentInputSource, the issue persists.

If I change WorkItemOptions from TimeSliced to none, the issue is not as bad (although bad enough to prevent shipping)

It seems we need a way to get background input, like with the CoreIndependentInputSource. Perhaps marshalling out to the actual device, bypassing the UWP Routed window events?

8

Can you comment out the line TouchQueue.ProcessQueued();
from https://github.com/MonoGame/MonoGame/blob/7c3d6870a38f8a5e479e64d935d692f2610e1cda/MonoGame.Framework/WindowsUniversal/UAPGamePlatform.cs#L153
?
Or better yet, use a Stopwatch to measure how much time the main thread is spending in it.

9

I commented it out, and the bug still happens. Here’s some samples of my timing:

Touch Queue : 0.0012
Touch Queue : 0.0012
Touch Queue : 0.0015
Touch Queue : 0.0015
Touch Queue : 0.0021
Touch Queue : 0.0021
Touch Queue : 0.0012
Touch Queue : 0.0012
Touch Queue : 0.0012
Touch Queue : 0.0024
Touch Queue : 0.0021
Touch Queue : 0.0009
Touch Queue : 0.0021
Touch Queue : 0.0012
Touch Queue : 0.0024
Touch Queue : 0.0012
Touch Queue : 0.0015

I just threw this into Debug.Writeline, in BeforeUpdate(). It’s in milliseconds.

My naïve stopwatch and writeline made the input issue much worse, if that’s helpful to know.

10

That’s strange. If you have your mouse events to CoreIndependentInputSource and TouchQueue.ProcessQueued() doesn’t slow the main thread significantly, then I don’t know why still keyboard events are queue up. (maybe a bug with latest Win10?)

Can you post a test project somewhere that demonstrates the problem?
Also try one last thing. turn of V-Sync and fixedTimestep to see if that helps to keep the message queue empty. Put those lines in your Game1() constructor.

    this.IsFixedTimeStep = false;
    this.graphics.SynchronizeWithVerticalRetrace = false;
11

Here’s another approach to to solve the issue.
I manage to lower the priority of Tick event which makes the game process all other events (input/rotation/etc) before drawing the next frame.

12

I know this may sound strange but if you have a extra keyboard plug it in and try it and see if the issue disappears! Just to make sure this isn’t a specific hardware thing.

When xna was around i found the many joys of getting hours of headaches trying to solve something that turned out to be a individual keyboard hardware quirk.

13

@willmotil
I can reproduce the bug. Others reported similar problems.

I think that CompositionTarget.Rendering has a higher priority than input on the latest W10.
On W8.1 projects works alright with mouse+keyboard, but CompositionTarget.Rendering has other issues there, especial on mobile phones, with touch lag, rotation lag and even the event stop firing and freeze the game when under heavy load.