Application crashes/fails when full screen and you move another windows app on top of it

Windows
,
1

I created a fresh MONOGAME app using Visual Studio 2022. Total fresh, from scratch.

This is all I changed:
public Game1()
{
_graphics = new GraphicsDeviceManager(this);
Content.RootDirectory = “Content”;
IsMouseVisible = true;
_graphics.PreferredBackBufferWidth = 2560;
_graphics.PreferredBackBufferHeight = 1440;
Window.IsBorderless = true;
_graphics.IsFullScreen = true;
_graphics.HardwareModeSwitch = true;
_graphics.SynchronizeWithVerticalRetrace = true;
_graphics.ApplyChanges();
}

If you do the above, then run the code it should display a BLUE screen.

Now, take a window and DRAG another window across the blue screen. (your app is still running in Visual Studio)

What I get is the window you are trying to drag caused the monogame to kind of minimize and then it will show up as a white screen and it looks to have crashed.

Any ideas what is going on and more importantly how to fix it. My game is nearly complete and I was adding resolution switching to the game, which I got working well, but as I was testing it looks like monogame does not behave very well.

Thanks! Steve

2

if I change the Window.IsBorderLess=true to false, it functions but only if you are using the default resolution of the monitor. It still does not work correctly if you use a non-default resolution and I could sure use help trying to understand how to fix it.

If you change the code to the below, run, then move a window over the running game, it will fail. It does not really crash, but it does not recover and restore the proper resolution.

Th

    public Game1()
    {
        _graphics = new GraphicsDeviceManager(this);
        Content.RootDirectory = "Content";
        IsMouseVisible = true;
        _graphics.PreferredBackBufferWidth = 1600;
        _graphics.PreferredBackBufferHeight = 1200;
        Window.IsBorderless = false;
        _graphics.IsFullScreen = true;
        _graphics.HardwareModeSwitch = true;
        _graphics.SynchronizeWithVerticalRetrace = true;
        _graphics.ApplyChanges();
    }
4

This is an artifact of Windows draw rules and Monogame’s screen update code.

When a window’s display area is overwritten windows provides an invalidated rectangle message and the client is expected to redraw the effected portion.

In Monogame, the current screen only exists on the GPU. In order to restore the image Monogame must perform a complete Draw() call to restore the screen.

You can set Monogame to run when it does not have focus, but the cons outweigh the pros.

5

So it is not something that is fixed? I was looking at another game I have Terria, and when the window is dragged on top of it, it just minimizes itself - super clean.

Is there a work around? ifyou look at the example I provided, it doesn’t stop drawing so what keeps it from redrawing the screen.

6

To sum this up, I’ve finished my game (Galaxy Trek, on Steam & Epic Games if anybody cares!), but the Monogame framework has disappointed because it does not handle the entire FULL-Screen, Windowed, Borderless window thing gracefully.

It just does not work, if you move a window over the game AND the game is in the native resolution it will gracefully minimize itself. But if you change the resolution, which people do, and do the same thing, it will go white and crash and I can’t control it, which sucks.

If there is somebody out there who can actually fix it, here is how it should work:

Borderless FullScreen - mouse can move to and from the game to another application without any issues - the game should continue to play as one would expect in a full-screen borderless game. I can drag a window ontop of the game and it works and continues to run with no issues. It should not matter the resolution. IF the resolution is an issue, it should gracefully minimize itself.

FullScreen - if the game is bound by the fullscreen mode and again for any set resoution, and the person ALT+TABS out, the game should gracefully minimize itself and then upon the player clicking the icon, it should restore the game to its previous resolution without issues.

Windows - i think it actually will work if you just do it in windowed mode, but who wants to do that?

Free is cool, but if I had to pay a “fee” to get support or something, it would be worth it. I wish there was a mid-point. We have the high-end engines that want a piece of the action, you have Monogame which asks for nothing, but you can’t get support to help with things like this.

1 Like
7

If you use OpenGL it will behave better in some cases, but truthfully it isn’t great either.

I stuck with DirectX cause there are other issues with OpenGl that causes problems (for one when the app wasn’t active it would register mouse clicks in other monitors, for 2 the audio had issues)

It would be great if somebody would take the time to really look into the behaivor of monogame with switching windows, moving windows on top of the game, and stuff like that.

8

I remember having a similar issue with WindowsDX hardware mode full screen and deciding not to include it in my games. It seems there are a number of reported issues as well:

A few things I noted when testing it again just:

  • While no longer on screen the GameWindow.ClientBounds have a width and height value of zero.
  • When clicking on the game to restore it, System.Windows.Forms.Form fires the Resize event six times. FormWindowState.Minimized occurs twice followed by FormWindowState.Normal four times.
  • After restoring the game to the screen, GameWindow.ClientBounds values can be quite random resulting in an incorrect aspect ratio.
  • Once the resolution change flickering stops, manually setting GraphicsDeviceManager.PreferredBackBufferWidth/Height again and calling GraphicsDeviceManager.ApplyChanges correctly restores the screen.

These results might be very different for other devices though. I would recommend stepping through the source code if you get other results to find out where the differences are.