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.
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.
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…
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”.
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.
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.
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.
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:
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.
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