| Summary: | macOS 10.14 (Mojave) opengl issues (SDL-1.2) | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Ozkan Sezer <sezeroz> |
| Component: | video | Assignee: | Sam Lantinga <slouken> |
| Status: | RESOLVED FIXED | QA Contact: | Sam Lantinga <slouken> |
| Severity: | normal | ||
| Priority: | P2 | CC: | alex, libsdl, murphy.mccauley |
| Version: | HG 1.2 | ||
| Hardware: | All | ||
| OS: | macOS 10.14 | ||
| Attachments: |
mojave updates from dosbox-x
Fix for latest MacOSX versions over latest 1.2 branch |
||
|
Description
Ozkan Sezer
2019-09-04 07:59:39 UTC
I don't build SDL apps on macOS myself, but two recent pieces of code I've written have run into this (or a related Mojave/SDL1.2 blank screen bug) for other users. I thought I'd share what I'd gleaned in case it's helpful. First, I notice the issue specifies OpenGL. Maybe that's a backend thing I'm not aware of or maybe there are multiple blank screen bugs related to Mojave, but this also occurs with applications that aren't (explicitly, anyway) doing anything with OpenGL. Second, the solution of building with an old SDK (e.g., the macOS 10.13 SDK from Xcode 10.1) resolves it (though it's a pain). Third, it looks like this came up in DOSBox-X and Jon Campbell patched the vendored SDL1.2 to fix it (I haven't tested this on my own applications). I'm not sure if there was an attempt to upstream this, but here's the commit and a related issue tracker entry where it's discussed: https://github.com/joncampbell123/dosbox-x/commit/fdf6061c05dcb35a1ea111ad5b75ade350059df3 https://github.com/joncampbell123/dosbox-x/issues/896 Fourth, lending credence to the idea that there may be multiple bugs at play here, some of the Mojave bug reports refer to a *black* screen, but others are less specific about "no video" or "blank screen" or the like. In the case of my applications, the result isn't black. It's light gray or something (possibly a default window background color?). Created attachment 3965 [details] mojave updates from dosbox-x As far as I can see, three additional changes are needed: https://github.com/joncampbell123/dosbox-x/commit/347ffff35507177a2004a62e28493126d5f4dc81 https://github.com/joncampbell123/dosbox-x/commit/53e3ab2306ba2f2724ca3cb9f2c27608313c1ea5 https://github.com/joncampbell123/dosbox-x/commit/2c683142151171ba28a603b0724b6663bcd8ed98 Attached a diff here for convenience. Those 'TODO's are a concern, though, it needs thorough review / testing who knows OSX well. (Also see: bug #3303) Created attachment 4288 [details]
Fix for latest MacOSX versions over latest 1.2 branch
Encountered a similar issue while trying to use/build FCEUX on the latest MacOSX (10.15.4 Catalina) - empty (gray) screens. FCEUX heavily depends on v1.2 (v2 support seems in very initial non-working phases). Got the latest SDL 1.2 branch and patched according to the patches in this ticket (made for DOSBox-X by Jon Campbell). Resulting libraries seems to work and solve the issue. Attaching my diffs/patch - maybe someone would find it useful and/or would want to incorporate into the official legacy code base to support the latest MacOSXs.
Patch added, thanks! https://hg.libsdl.org/SDL/rev/ab7529cb9558 The patch that was committed contains "TODO" and "HACK" comments as well as mismatched whitespace. Will this be cleaned up? I would like to apply this patch in MacPorts so that our Mojave and Catalina users can continue to enjoy libsdl1-based software even before you release version 1.2.16, however our maintainer of libsdl is concerned about the unfinished appearance of the patch. (In reply to Ryan Schmidt from comment #5) > The patch that was committed contains "TODO" and "HACK" comments as well as > mismatched whitespace. Will this be cleaned up? I would like to apply this > patch in MacPorts so that our Mojave and Catalina users can continue to > enjoy libsdl1-based software even before you release version 1.2.16, I don't think that there will be a 1.2.16 release any tine soon. > however > our maintainer of libsdl is concerned about the unfinished appearance of the > patch. If the unfinished appearance is only because of the whitespace mismatches, that can be rectified easily: otherwise please tell us whether the intended functionality is OK. > I don't think that there will be a 1.2.16 release any tine soon. I certainly don't know what the SDL developers' plans are, but it has been over 8 years since 1.2.15 was released and there have been over 250 commits to the SDL-1.2 branch since then. I have to believe that at least some of those commits have value, such as this one that makes SDL 1.2 work on Mojave and later. It shouldn't be unreasonable to expect or ask developers to timely release new versions of their software so that users and package management systems can update to those versions and benefit from those improvements. > If the unfinished appearance is only because of the whitespace > mismatches, that can be rectified easily: otherwise please tell > us whether the intended functionality is OK. Our libsdl maintainer expressed concern over the "TODO" comments. For example there is a block that reads: if (SDL_VideoSurface->flags & SDL_OPENGLBLIT) { // TODO } https://github.com/macports/macports-ports/pull/7314#discussion_r436392990 He didn't mention the "HACK" comments or the whitespace inconsistency, but I noticed them and wanted to point them out as well. The extent of my testing of the changes is that I was working on updating the game Race Into Space in MacPorts; found an issue on their issue tracker about it not working on Mojave and later; found this SDL bug report and the patch that claimed to fix it; verified that it fixed the issue for me in Mojave and Catalina; and I submitted the PR to get it added to libsdl in MacPorts. I didn't test any other SDL software with this patch, so that hardly constitutes thorough testing. And I've never looked at the SDL source code before, so I wouldn't be qualified to review the patch or make any guarantees about its correctness. FWIW I tidied up the whitespace: https://hg.libsdl.org/SDL/rev/1d55c02cc513 The changeset now corresponds to the patch from comment #2. |