I experiences this issue with my game. So to diagnose the issue I created a new project.
So a clean new Windows Universal Monogame project (monogame version 3.6.0.1625)
And in the constructor, I changed to look like this.
public Game1()
{
graphics = new GraphicsDeviceManager(this);
graphics.ToggleFullScreen();
graphics.ApplyChanges();
Content.RootDirectory = "Content";
}
In the update method, I write this.
protected override void Update(GameTime gameTime)
{
// TODO: Add your update logic here
// TODO: Add your update logic here
var keyboardState = Keyboard.GetState();
var mouseState = Mouse.GetState();
if (mouseState.LeftButton == ButtonState.Pressed)
{
System.Diagnostics.Debug.WriteLine("L-Mouse-pressed");
}
if (mouseState.LeftButton == ButtonState.Released)
{
System.Diagnostics.Debug.WriteLine("L-Mouse-released");
}
if (keyboardState.IsKeyDown(Keys.Down))
{
System.Diagnostics.Debug.WriteLine("Down-Down");
}
if (keyboardState.IsKeyUp(Keys.Down))
{
System.Diagnostics.Debug.WriteLine("Down-Up");
}
if (keyboardState.IsKeyDown(Keys.F) && _previousKeyboardState.IsKeyUp(Keys.F))
{
graphics.ToggleFullScreen();
}
_previousKeyboardState = keyboardState;
base.Update(gameTime);
}
The following is what I noticed.
When pressing down for like 4 seconds and then release it, it keeps getting the keyboard state with down button still being pressed. Until I interrupt it with another signal.
If I keep the mouse button pressed for longer than 4 seconds this does not happen.
When I start the game in windowed mode or I toggle it to windowed mode from an initial fullscreen and then go to full screen back again, this case of getting stuck in a state that down is pressed after being pressed for longer than 4 seconds does not occur.
I donāt think Iām doing anything wrong.
Does anyone else have this problem?
Is it me.
If not is this bug known? Couldnāt find anything recent about this on the web.
Isnāt it easier with a KeyDown only if you want to go down while it is pressed and stop as soon as it is released?
If you wanna test when it is down and up, you usually use this to limit the movement at sayā¦ 1 case down
Ik donāt think I correctly understand your suggestion.
But the problem is, if you start the program in fullscreen mode. The release of a button is not detected if the key was pressed for longer than 4 seconds. This Does not occur after the screen has been in windowed mode once.
In my sample code you can see that I try to detect when the down key is released
if (keyboardState.IsKeyUp(Keys.Down))
{
System.Diagnostics.Debug.WriteLine("Down-Up");
}
But in the visual studio debug output It keeps printing āDown-Downā. Until I pres another button of change the screen to windowed mode. In this case with the letter āFā.
I created a new āMonoGame Windows 10 Universal Projectā.
If I start the project in full screen mode, the keyboard input initially works fine, but the key presses become delayed over time. After about a minute the keyboard is unresponsive.
e.g.
Initially, If I hold the Left arrow for a second and then hold Right for a second, the keyboard state will immediately reflect that Iāve released Left and Iām now pressing Right.
After 30 seconds or so, if I hold Left for a second and then hold Right, the keyboard state will continue to show that Iām pressing Left for some time before finally showing that Iām actually pressing Right now. After releasing Right, the keyboard state continues to show that Iām pressing Right for some seconds before reflecting that Iāve actually released it.
After a minute or so, the keyboard state is so delayed itās essentially hung.
No other aspect of the game is affected by the delay, only the keyboard state.
Starting Not in Fullscreen (ie. running windowed) the keyboard state is not affected and everything works as expected.
Youāre right, it is still happening for me too, just a lot less severe.
It seems to run fine for a few seconds and then stick for a bit (0.5 seconds?) and then ācatch-upā and run fine for a bit again before once again sticking. It never completely hangs like it does on the release builds.
Although, more worrying with the new develop builds is the random āhangā on startup
This is interesting. Iāve encountered similar keyboard input issues as well. However, gamepad input is also 100% responsive while the keyboard input issues are occurring. Iām not sure that mine are related to the full screen setting, but I will check in a while. Iāve made at least one post here about the issues Iāve encountered, but no one ever responded
A little bit of an update on thisā¦ so I removed the graphics.IsFullScreen = true setting from my Game1 constructor and I saw a differenceā¦ they keyboard input is now more responsive and it takes longer until it starts becoming unresponsive. It also seems to shift between unresponsiveness and being responsive. Soā¦ somewhat improved, but still far from ideal. Has anyone else made any progress on this?
This might go all the way down to Windows.UI.Core. I noticed this problem a few months ago in a Win2D project when using CoreWindow functions. Now I just started a MonoGame skeleton project and noticed stuck keys again. A github search shows that MonoGame uses the Windows.UI.Core functions for reading the keyboard.
A possible workaround is to delay full screen until after you call the base class in the first Update():
Set graphics.IsFullScreen = false; in the constructor.
Keep track of the number of update calls or create a bool for this then in Update():.