VOGONS


Black screen and freezing in macOS

Topic actions

First post, by almeath

User metadata
Rank Newbie
Rank
Newbie

I am not sure if this is a potential bug or just a problem that Apple introduced in the latest version of Mojave, so I would like to seek opinions.

When I purchased a game from GOG using their DOSBox wrapper (Warcraft), I noticed that when exiting the application in full screen mode, a black screen and freeze up (i.e spinning pinwheel) would occur. It affected my older iMac (2013 Core i7 Haswell with Nvidia graphics). It happens in Mojave 10.14.6 but not in 10.13 or earlier. It does not occur when the application is run in windowed mode.

To see if this was a DOSBox issue, I extracted the game from the GOG application wrapper, and tried running it directly from DOSBox 0.74-3. The same problem occurred when exiting from full screen. In fact, just opening DOSBOx and then using “exit” command caused the same freeze up.

I then repeated the test with an SVN build of 0.75 and got the same results. Works in High Sierra and earlier, but freezes in Mojave.

To further complicate the situation, I found that this issue does not occur at all on my 2019 5k iMac that has a Core i9 with AMD graphics, also on Mojave 10.14.6.

As I have narrowed down the issue to (apparently) particular hardware, I was hoping someone might have some suggestions as to what could potentially be causing this issue.

I did check that SDL 1.25 and the latest build of version 2 were on both of my iMacs, and I tested in fresh installs of macOS too.

Reply 1 of 22, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Does switching back to windowed mode work ? (so does going to fullscreen trigger it, or does shutting down from fullscreen trigger it)

Water flows down the stream
How to ask questions the smart way!

Reply 2 of 22, by almeath

User metadata
Rank Newbie
Rank
Newbie
Qbix wrote:

Does switching back to windowed mode work ? (so does going to fullscreen trigger it, or does shutting down from fullscreen trigger it)

The freeze up will occur when:

1. Starting in full screen mode and then exiting DOSBox.
2. Starting in windowed mode, switching to full screen mode, and then exiting DOSBox.
3. Starting in windowed mode, switching to full screen mode, and then switching back to windowed mode. When pressing option-return the screen goes black and presents the spinning pinwheel.

The only method that avoids the freezing is starting up in windowed mode and remaining in it until exiting DOSBox.

Reply 3 of 22, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

ah, so it is the switching back from fullscreen to windowed.

Does the selected output have an influence ?

Does 0.74-2 work ? (as that one is 64 bit compatible as well)

Water flows down the stream
How to ask questions the smart way!

Reply 4 of 22, by almeath

User metadata
Rank Newbie
Rank
Newbie
Qbix wrote:

ah, so it is the switching back from fullscreen to windowed.

Does the selected output have an influence ?

Does 0.74-2 work ? (as that one is 64 bit compatible as well)

I performed further testing in several versions of DOSBox, consisting of starting in windowed mode, switching to full screen with option-return, and then switching back to windowed mode (all while at the main DOS prompt).

I tested 0.75b1, 0.74-3, 0.74-2 and 0.74-1.

The same freeze up happened in all of them, when going back to windowed mode from full screen mode.

Interestingly, the problem did not occur if I used “surface” or “overlay” settings. It only occurs when using “opengl” or “openglnb”.

Since I never had any issues with any version of DOSBox until Mojave 10.14.6, it is looking like a bug introduced by Apple, which seemingly only affects certain hardware.

Reply 5 of 22, by ShovelKnight

User metadata
Rank Oldbie
Rank
Oldbie

Apple really hates Nvidia and they have progressively broken compatibility with Nvidia graphics in later versions of macOS.

I can’t play anything on my MacBook Pro 2012 with GT650M anymore, even the games that were working splendidly previously (such as Tropico 4 and Civilization V) are now crashing constantly.

Reply 6 of 22, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author
almeath wrote:

Interestingly, the problem did not occur if I used “surface” or “overlay” settings. It only occurs when using “opengl” or “openglnb”.

Since I never had any issues with any version of DOSBox until Mojave 10.14.6, it is looking like a bug introduced by Apple, which seemingly only affects certain hardware.

Thanks for trying. Could you see if setting fullresolution=0x0 changes things ? (or fullresolution=your desktop resolution)
It's somewhat unfortunate, as in 0.74-3 opengl is the default on Mac.

Water flows down the stream
How to ask questions the smart way!

Reply 7 of 22, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

are you compiling yourself? I have to test with my builds bit there was a problem when you compiled SDL on Mojave. My builds are done on OS X 10.11 which should work.
Also latest svn in my sig

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox

Reply 8 of 22, by almeath

User metadata
Rank Newbie
Rank
Newbie
Qbix wrote:

Thanks for trying. Could you see if setting fullresolution=0x0 changes things ? (or fullresolution=your desktop resolution)
It's somewhat unfortunate, as in 0.74-3 opengl is the default on Mac.

I tried all of the same tests with the native screen resolution of 2560x1440 and also “desktop”. I then tried the 0x0 you suggested. Unfortunately those had no impact on the results.

I suppose Apple could have broken something in their Nvidia drivers in Mojave in the update from 10.14.5 to 10.14.6. There is no way to know for sure because they have not allowed Nvidia to release web drivers for any version of Mojave.

Reply 9 of 22, by almeath

User metadata
Rank Newbie
Rank
Newbie
Dominus wrote:

are you compiling yourself? I have to test with my builds bit there was a problem when you compiled SDL on Mojave. My builds are done on OS X 10.11 which should work.
Also latest svn in my sig

No, I tested with the precompiled downloads on sourceforge. I will do some more tests with your SVN and also have a go at compiling in Mojave.

Reply 11 of 22, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

If you self compile, make sure you grab the latest mercurial of SDL 1.2x

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox

Reply 12 of 22, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

Are you sure the fullscreen changes are taking effect when using opengl? If 0x0 or resolution specified then it shouldn't switch to real fullscreen so that should be noticeable.

It is pretty ridiculous with the Nividia and Apple situation. At least with a desktop you can swap out the card.

DOSBox Compilation Guides
DosBox Feature Request Thread
PC Game Compatibility List
How To Ask Questions The Smart Way
Running DRM games offline

Reply 13 of 22, by almeath

User metadata
Rank Newbie
Rank
Newbie

I don’t know if this is normal behavior, but whether or not I use 2560x1440, or 0x0, or desktop, I am finding that option-return takes me into what appears to be normal full screen mode, with proper scaling to the native desktop resolution. It appears to be the same whether I use opengl or surface/overlay settings. This is occurring with 0.74-2 through to 0.75b1.

Reply 14 of 22, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

except it hangs when you return back if you use opengl right.

I think the only thing we can do is try to debug it, to see where it hangs. Either with adding log messages or running an actual debugger.

Water flows down the stream
How to ask questions the smart way!

Reply 15 of 22, by almeath

User metadata
Rank Newbie
Rank
Newbie
Qbix wrote:

except it hangs when you return back if you use opengl right.

I think the only thing we can do is try to debug it, to see where it hangs. Either with adding log messages or running an actual debugger.

Yes, that’s right. The core issue is the freeze when switching back, but only with opengl.

I will gather what logs I can and report back.

Reply 16 of 22, by almeath

User metadata
Rank Newbie
Rank
Newbie

I have not yet had time to debug, but interestingly, the problem does not occur in the latest DOSBox-X. I might go with that as a work-around for the time being and wait to see if DOSBox 0.75 fixes this when released.

Reply 17 of 22, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

AFAIK, -X switched to SDL2. This makes it more likely to be a SDL issue

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox

Reply 18 of 22, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

@almeath can you try this build? (edit: build removed, please use the SDL2 build in my signature)
It's a several revisions old SVN built against SDL2. If that works, I can do more up to date ones in the future.

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox

Reply 19 of 22, by almeath

User metadata
Rank Newbie
Rank
Newbie
Dominus wrote:

@almeath can you try this build? (edit: build removed, please use the SDL2 build in my signature)
It's a several revisions old SVN built against SDL2. If that works, I can do more up to date ones in the future.

Not only does that fix the problem, but the performance is far superior to the SDL 1 builds, and it fixed some strange audio glitches I was getting in some games. 😀

Is there any chance you can do parallel SDL 1 and 2 builds in your SVN releases, similar to the DOSBox-X releases? Some people may get better compatibility from SDL 1, but on newer Macs it seems SDL 2 is the best option. It would be good to be able to choose between the two.