I started developing in Monogame because of what it sold itself as: a cross-platform solution that abstracts all of the graphics, audio, and input through its own interface. I’ve been trying to get the boilerplate graphics configuration out of the way, and I’ve reached the point where there are just too many problems for me to continue. Here’s a breakdown of just some of the roadblocks I’ve hit:
In Windows 10, I have 150% scaling on my 4k monitor. If I drag a Monogame window that has AllowUserResizing set to false to my other monitor without the scaling, it inexplicably grows vertically and horizontally as I drag to the point where it grows off the screen. No resizing allowed so I can’t fix it. I have to kill the app and switch to AllowUserResizing = true. My workaround was just to position the RenderTarget2D of my game inside the sizable window so it’s proportional and centered with black bars as needed. Weird.
If I have a RenderTarget2D with a DepthFormat that isn’t None (I want a stencil) and use any positive value for multisampling, the result is a blank output. The goofy workaround I found is to create a 1x1 size RenderTarget2D with a depth format that isn’t None and multisampling > 0 and not dispose it. I only discovered this workaround when I was changing resolutions and saw it would actually start rendering as long as I changed resolutions at least once (by pressing a switch keyboard key blindly since I had no graphics output). After experimenting I found that creating this dummy RenderTarget2D on Init gave me the results I needed (I’m using the OpenGL runtime for reference). I needed the dummy RT to have a depth buffer and multisampling or it wouldn’t do the trick, and if I immediately disposed of it after creation it still wouldn’t do the trick.
If I call clear with a color on a RenderTarget2D that isn’t set as the graphics device target, it just overlays the color at half transparency on the existing graphics data. Huh?!
If I try to use HardwareModeSwitch with a two-monitor setup, then changing the back buffer size results in a blank screen with no way I can find to fix it (alt-tabbing, toggling full screen twice, etc). If I hover the mouse over the task bar of the program I see in the preview that it’s actually running, and it’s consuming GPU and CPU resources. Just no display. If I turn one monitor off before-hand, it actually works, but it displays the output at a 1 to 1 pixel ratio with the monitors native resolution. So if my game is rendering in HardwareModeSwich at 720P to my 1080P monitor, it’s centered in the middle of the screen with a bunch of blank space around it. This is despite the fact that Monogame did indeed change the monitor screen resolution, and my GraphicsDevice.PresentationParameters.Bounds,Width, RenderTarget2D.Width, and GraphicsDevice.Adapter.CurrentDisplayMode.Width all say they’re 1280.
I really like the game design aspects of this framework, but I don’t think it’s wise to invest in a framework that seems to struggle so much with the basic setup of a game. I recognize the challenge faced in trying to make a cross-platform solution, but I’m wondering if these are problems others experience and deal with, or if the similar frameworks like FNA also have these issues? I’m wondering if I just switch to platform-specific solutions and keep the abstractions to graphics, audio and input in my own code base is a more reliable alternative.
Any insights would be appreciated. Has anyone here made the standard graphics UI with all the typical settings (VSync, FullScreen, Resolution, MSAA) and had it all work as expected? With the simple interface in Monogame for these features I had no idea I’d be spending so much time trying to get it to do what I want.
look around on this forum I have posted about how monogame handles resizing and moving windows.
If you have Monogame running windowed , it is fine. It is only if you turn off the border and get rid of the title bar you run into issues, which I have detailed and shown fixes for elsewhere.
Note windows 10 does not handle window scaling well, UE4 has problems with windows scaling as well and it is well beyond what Monogame can deal with short of ditching windows 10
I use many rendertargets both with and without depth buffers , and have no problems with multi-sampling. May be a OpenGL issue. I never use OpenGL, it’s deader than dody.
Don’t. Clearing a rendertarget that is not bound to a graphics device is dangerous
Never seen any problems with this either, I would swap to directx and see what happens
If you don’t like something Monogame does, then change it. The source code is available and you can grab a copy and change anything you want
Thanks for the review and tips. I’m going to check out FNA as I’ve heard it’s better geared to desktops and has a focus on stability and compatibility.
I have no interest in digging into the source. For my goals, that seems to defeat the purpose of picking this as a solution. To me, it seems like I picked a car whose power steering doesn’t work when the turn signal is on. I don’t want to spend time taking it apart if my priority is getting to work and learning my job. Time to try another car.
Yeah I’m also curious about this. From my laymans perspective OpenGl seems to have more of a future than dx with it’s wider compatibility as phones and tablets have become increasingly important markets…?
Just so you know, I did switch my project to DirectX and the hardware fullscreen mode issue went away. I’m happy that fixed it, but it’s worrying about stability across platforms. Unfortunately, changing to DirectX happened to break all my shaders though. After yet another 2 hours of debugging I found out that DirectX doesn’t respect pixel shader semantics and only considers the order of the output parameters of the vertex shader. Kill me.
Apple now make you use Metal, though in their typically helpful way they refuse to release c++ bindings for it. Objective C or Swift only.
Android is moving to Vulkan
Stadia is Vulkan only
Windows DX12
Even in UE4 you notice a massive improvement if you swap to DX12.
Across the board OpenGL seems to be a waste of development time. I see bugs in OpenGL renderers that have existed for ages and no one seems interested in fixing them, I see updates coming out in engines that feature changes for Vulkan, DX11, DX12 and none for OpenGL
It’s dying and IMHO you should be moving on and keeping your skills relevant by learning something new that is relevant to you
Yep even the main guys submitting for monogame are preping to move to vulcan in the future.
To be honest its a miracle to me that the hlsl can be converted as well as it does to open gl in the monogame shaders. But there are quirks and broken things for Dx as well.
Yea I get it. At the same time, I feel like I went to a dealership who told me they specialize in petrol cars, and when I brought it in later for service they said “why are you driving that piece of junk?!”.
To hopefully circumvent this issue, however, perhaps develop for Windows first, then find alternative ways for when porting to OGL… hopefully by that time, it will be running on Metal… not that I care much for OGL or whatever other platforms use… though I might be forced to port to Android soon for the Surface DUO…