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