Fullscreen / non-fullscreen issues

[MikeLorenz]

Hi all - I’m converting some SDL2 C code I wrote last month into MonoGame & I have a couple of issues/questions. I’m hoping someone with a bit more MG experience can help. (I’m developing in Visual Studio 2015 on Windows 10.)

Issue 1: In fullscreen mode the display seems slower/laggier than windowed mode. Not super-noticeable, but I can definitely see some image doubling or ghosting occasionally. Like when I rotate a blue sprite, I swear I can see a white version underneath sometimes that’s one frame behind. This mystifies me, although I suppose it could be my video card/driver. In windowed mode, the game is 100% solid with no weird visual stuff going on.

Issue 2: Windowed mode won’t cover the entire screen - it allows the taskbar to appear in front it of. In SDL2 windowed mode covers everything. Any way to get MG to do this too? I’m getting a little tired of playtesting & seeing that stupid taskbar.

Thanks!
Mike

[kennethsuda]

My test application using Windows 10 with DirectX goes to full screen just fine without a task bar. Doesn’t seem to lag or have artifacts at all. I am using MonoGame source from the develop branch that is semi current (week ago?). Same test app using UWP or Desktop GL works fine as well. You might compare your screen resolution to your draw resolution when going to full screen (for the artifacts). You might also add a frame rate counter to show if Draw is getting called enough. I started another topic asking for the proper way to make it be full screen, but no answer. Currently, I set full screen in the Game1 constructor after the call to GraphicsDeviceManager creation.

        public Game1 ()
        {
            graphics = new GraphicsDeviceManager (this);
            graphics.IsFullScreen = true;
            graphics.PreferredBackBufferWidth = GraphicsAdapter.DefaultAdapter.CurrentDisplayMode.Width;
            graphics.PreferredBackBufferHeight = GraphicsAdapter.DefaultAdapter.CurrentDisplayMode.Height;
            Content.RootDirectory = "Content";
        }

[MikeLorenz]

Thanks for answering. It does look like fullscreen mode is lower FPS but it’s actually not. Here’s my startup code plus some debug output I ran in both modes…

bool fullscreen = false;
int taskBarY = fullscreen ? 0 : 40;
graphics = new GraphicsDeviceManager(this);
graphics.PreferredBackBufferWidth = GraphicsAdapter.DefaultAdapter.CurrentDisplayMode.Width;
graphics.PreferredBackBufferHeight = GraphicsAdapter.DefaultAdapter.CurrentDisplayMode.Height - taskBarY;
graphics.IsFullScreen = fullscreen;
graphics.ApplyChanges();


**Fullscreen ON**
BackBuffer X,Y = 1920,1200
FPS: 59.935909051084

**Fullscreen OFF**
BackBuffer X,Y = 1920,1160
FPS: 59.9192124373762

I still don’t know why fullscreen looks so “off”. I have a feeling that even if I make a video of it, it wouldn’t capture the difference.

I’d say it was my video card, but everything works perfectly in my SDL2 project whether fullscreen or not. Hmm…

[kennethsuda]

I remember having bad luck with calling ApplyChanges in the constructor, so I don’t call it. You might also check the GraphicsDevice.PresentationParameters.BackBuffer* size when it gets to the Draw to see that it has the right sized back buffer to your preferred size. Depending on what version of various pieces you use, you may get different answers than “right”.

[MikeLorenz]

Thanks again for your replies. Sadly there’s no change with removing ApplyChanges. Verifying the backbuffer size was a good idea, though in this case it shows the expected size.

[kennethsuda]

I’m definitely not a super MG expert, so maybe one of them will answer. You might specify which template you used and which version of MG you are working with. I know I have seen changes the past couple months for back buffers and screen sizes.

[MikeLorenz]

Here’s something interesting. When I take a sprite and move it across the screen so it covers 3000+ pixels per second, and wrap it around so it’s constantly moving from left to right over and over again, it’s moving fast enough that I see several “ghost” images due to the 60Hz refresh rate. So far so good. But the ghost images look different in the two modes. Using an “x” to represent the sprite, it looks something like this:

NORMAL MODE
x    x    x    x    x    x    x    x    x    x    x    x    x

FULLSCREEN MODE
xx        xx        xx        xx        xx        xx        xx

The doubled sprites are actually almost directly on top of one another, but just a pixel or two off.

I’ve verified that regardless of the mode, Draw and Update are both called ~60 times per second.

[MikeLorenz]

Thanks, Kenneth, I totally understand – I appreciate the time you’ve taken!

[MikeLorenz]

As I suspected, in fullscreen mode, although the average FPS is around 60, the actual delta seconds in each call to Draw is much different, and forms a pattern of pairs, ~1/30th of a second followed by ~1/1000 of a second. Here’s a sampling from one second:

delta = 0.040184
delta = 0.0003019
delta = 0.0261491
delta = 0.0004072
delta = 0.0329117
delta = 0.0003305
delta = 0.0331329
delta = 0.0165756
delta = 0.0003848
delta = 0.0329567
delta = 0.0003308
delta = 0.0329823
delta = 0.0003318
delta = 0.0332358
delta = 0.0006638
delta = 0.032774
delta = 0.0011218
delta = 0.0321017
delta = 0.0005156
delta = 0.0328896
delta = 0.0005346
delta = 0.0327538
delta = 0.0003448
delta = 0.0329662
delta = 0.0003143
delta = 0.0333641
delta = 0.0008894
delta = 0.0323405
delta = 0.0011
delta = 0.0321268
delta = 0.0005138
delta = 0.0328428
delta = 0.0005198
delta = 0.0328265
delta = 0.0002826
delta = 0.0330281
delta = 0.0003448
delta = 0.0329895
delta = 0.0003106
delta = 0.0330195
delta = 0.0003263
delta = 0.0330698
delta = 0.0002451
delta = 0.0331668
delta = 0.0003305
delta = 0.0330276
delta = 0.0003323
delta = 0.0330228
delta = 0.0008881
delta = 0.0324283
delta = 0.0003134
delta = 0.0331054
delta = 0.0003279
delta = 0.0329982
delta = 0.0003412
delta = 0.0330281
delta = 0.000301
delta = 0.0330864
delta = 0.0004163
delta = 0.0329515

No wonder my animation looks strange! Right now I’m just not familiar enough with MG to know why it’s happening, but I’m hoping I can do some digging.

[Alkher]

I confirm MG is slower in fullscreen than windowed (at least on Windows DX)

Incorrect Screen Resolution in DirectX Windows Project

I want the image to be stretched, I planned using Independant Resolution later I think 800x600 is now the minimum standard, or maybe 1024x768. But what I want for now, is see how fast my engine is in fullscreen: Windowed, an empty window is 350fps, when switching to fullscreen, it drops to 170fps… as it is rendering from 800x600 (windowed) to 1920x1080(fullscreen) All the “regular” display modes are in the list of the supporteddisplaymode of my card. When I play Painkiller for example, …

[MikeLorenz]

@Alkher

I confirm MG is slower in fullscreen than windowed (at least on Windows DX)

Thanks for that, Alkher. My project is OpenGL FWIW.

[Alkher]

OpenGL is slower than DX too

DirectX 50% faster than OpenGL ?

I cant provide a difinitive answer for you but I can say from what Ive seen from the OpenTK source not everything is done in the most optimal way (which monogame uses to handle the OpenGL stuff) and its possible that a good portion of its functionality that MonoGame uses(At the current release i believe utilizes game window?) ends up doing alot of extra unnecessary work to ensure no errors that directX may not exactly need to do.

[SpiceyWolf]

in most .net related cases that is true, not all cases though… if you “actually know how to use opengl the right way” you can make it work much faster than dx with the same quality.

[Alkher]

And with Dx12 and its multithreading its even faster. Nonetheless, I was saying that in relation to the issues with monogame, not to troll ^^

[SpiceyWolf]

Actually DX12 still has its problems… and DX12 being faster is only in relation to the GL that was competition to DX11, lol the Vulkan release outperforms dx12 and was released not long after dx12 release… The only issue of vulkan is getting it on machines as its taking forever for driver distributors to support it still.

Basicly Kronos is giving microsoft a slowly raised middle finger… xD