DESKTOPGL - Black screen on MacOS

We have a game that has already been launched for a while, and that currently runs normally on Windows and Linux:

But when running on MacOS, it only displays a black screen, despite textures loading successfully, audio playing in the background and it responding to input.

The game renders using the DESKTOPGL graphics pipeline of monogame. While trying to figure out why this is happening, we saved the contents of the render target to an image to see if it was being drawn correctly. It shows the image of the game perfectly, but still, it seems it never ends up on the screen. Calling GraphicsDevice.Clear( still yields a black screen too.

For context, this is our draw loop:

protected override void Draw(GameTime gameTime)
    //This is responsable to fill the render textures, and it does it without any problems


    SpriteBatch.Begin(SpriteSortMode.Deferred, null, SamplerState.PointClamp, null, null, null, Resolution.GetTransformationMatrix());

    SpriteBatch.Draw(FinalRenderTarget, Vector2.Zero, Color.White);
    SpriteBatch.Draw(HudRenderTarget, Vector2.Zero, Color.White);



We tried updating the libs and dependencies that monogame and desktopgl need for MacOS, but to no avail. We also tried compiling the latest version of SDL to MacOS, since it seemed the black screen issue was reported in some boards as a problem with SDL.

This started happening sometime after we upgraded from monogame 3.5 to 3.7.1. Previously, the game displayed correctly on Mac and Linux.

At this moment, we are running out of ideas of why it is not showing up on screen, so we’re looking for help from someone more experienced or that has run into this issue.

I’ve also a problem when using RenderTargets on MacOs. If I don’t use them, the game renders where it should, but as soon as I once call the SetRenderTarget to some texture, even if I immediately call SetRenderTarget(null) again, the game will render in the bottom left corner of the screen.

I’ve found this issue on GitHub which describes similar symptoms, however I’m not entirely sure it’s really related

Github Issue #4802 (not allowed to submit links for whatever reason)

out of curiosity.
Could you try adding this before the SpriteBatch.Begin?

It’s just some ugly workaround but for me it helps to at least get it rendered properly for now. Still unsure WHY I have to do this

    int retinaFactor = 2; // TODO: where to get proper factor from?
    Viewport oldViewport = Graphics.GraphicsDevice.Viewport;
    Viewport newViewport = new Viewport( 0, - oldViewport.Height, oldViewport.Width * retinaFactor, oldViewport.Height * retinaFactor );
    Graphics.GraphicsDevice.Viewport = newViewport;
    float pixelScale = MathF.Min( newViewport.Width / ( float ) FinalRenderTarget.Width, newViewport.Height / ( float ) FinalRenderTarget.Height );
    // and then draw your SpriteBatch using the pixelScale as scale parameter

I am running into the exact same issue. Only on OSX. Windows and Linux work great.

I was running into the same problem on MacOS DesktopGL project when everything was working fine on my code-sharing WindowsDX project: Render targets were being rendered to, but the screen was always black, no matter what I tried, except for maybe a frame or two right when the game first launched.

I eventually discovered that setting the GraphicsProfile of the GraphicsDeviceManager to GraphicsProfile.HiDef seemed to be causing the black screen issue. I was setting the GraphicsProfile to HiDef somewhere in my game’s Initialize()/LoadContent() setup.

Looking at MonoGame’s DesktopGL source code, it appears that it defaults to using GraphicsProfile.Reach, and a new GraphicsDevice is created when it detects that the GraphicsProfile has changed.

I tried moving the code that changes the profile to HiDef from the Initialize()/LoadContent() methods to the constructor of my class that inherits from the MonoGame Game class, and that seems to have fixed it for me!

I’m not sure if others were still hitting this issue or not, but I hope this helps someone, as I found this to be a very frustrating issue that was not at all simple to debug.