Drawn area shrunk to 1/4 on macOS Catalina 10.15

[edonkeycoin]

• 1.60 Sunset build running on macOS Catalina 10.15 Beta (19A573a)
• Related discussion: N/A
• Observation: When redeclipse comes up the drawn area only takes up about a quarter of the window, in the lower left corner. The rest of the window is black.
• Expected result: I'd expect it to draw in the whole window.
• How to reproduce: Run redeclipse under macOS Catalina. Reproducible 100%.

Same build runs fine on Mojave on the same machine and monitor. Happens both with full screen and non-full screen. Changing the screen size in the config doesn't help.

2019-09-27 18:04.48 loading enet..
2019-09-27 18:04.48 loading game..
2019-09-27 18:04.48 version: 1.6.0-mac64- client (Sunset Edition) [0x763c3b6e]
2019-09-27 18:04.48 loading sdl..
2019-09-27 18:04.48 loading video..
2019-09-27 18:04.48 loading gl..
2019-09-27 18:04.48 renderer: AMD Radeon HD - FirePro D700 OpenGL Engine (ATI Technologies Inc.)
2019-09-27 18:04.48 driver: 4.1 ATI-3.0.67
2019-09-27 18:04.48 loading sound..
2019-09-27 18:04.48 allocated 32 of 32 sound channels
2019-09-27 18:04.48 loading defaults..
2019-09-27 18:04.48 loading world..
2019-09-27 18:04.48 loading config..
2019-09-27 18:04.48 configuration loaded
2019-09-27 18:04.48 loading required data..
2019-09-27 18:04.48 loading main..

[qreeves]

Are you using DPI scaling or something? I remember seeing somewhere they changed how that behaves in Catalina. Unfortunately, I can't test this myself as my Mac doesn't support anything later than High Sierra (10.13).

[qreeves]

Addendum: I should note that once the requirement to use a Developer ID (US$99/yr) to sign and notarize apps becomes mandatory, Red Eclipse will likely no longer run on macOS 10.15 or later at all. Apple have also deprecated OpenGL and will likely be removing support for it in later updates. As a result of these decisions by Apple, we will likely drop support for macOS entirely.

[edonkeycoin]

Thanks for the responses @qreeves.

I haven't intentionally made any DPI scaling changes. My desktop under Catalina looks the same as Mojave, as far as I can tell. It's a 4k Samsung monitor, in case that's relevant.

My Catalina machine is at the office so I can't drill into its settings just now. But I can this weekend or Monday.

On the notarization requirements, I agree that Apple is not making it easy for open source developers. But at least for the time being, users can still run any unsigned or non-notarized app by right clicking and explicitly opening it, or by clearing the quarantine xattr. Savvy users can build their own copies of the game and just run it, as well.

On the deprecation of OpenGL, Apple deprecated 32 bits 10 years ago. It's only just this year that Catalina will only run 64 bit apps.

I don't have a magic 8 ball that will tell you how long we have before OpenGL is removed. But given the massive pushback that that announcement has received, I would expect that it won't happen for at least 5 years (if ever).

So if the redeclipse team is willing, Apple could be a viable platform for many years.

Who knows, maybe Apple will add a free Open Source developer ID to qualifying projects. And maybe they'll have a change of heart moving from OpenGL to Metal. Unlikely, I agree, but you never can tell what might happen...

In any case, I want to keep playing. I've poked around at the sources in the debugger, but haven't yet figured out why the drawn area has shrunk. I'm unfamiliar with this code, but perhaps I can step through the debugger on Mojave and Catalina to see if I can spot a difference.

I'm hoping this issue is straightforward, and not buried in the SDL2 libraries...

[qreeves]

I appreciate your input. I bought a Mac Mini in 2010 to fix the issues with Apple deprecating stuff back then and continue producing official builds. I can't afford to buy another one just to get past macOS 10.13, and I don't think open source developers should be forced to pay for subscriptions in order to produce applications. Unfortunately, I'm not comfortable with a third party producing official builds either.

It is good to know that there is a way around the issue (for now), but I'm not sure if this helps with our eventual launch on Steam, as you don't exactly get the option to right click the app to open it there. This whole debacle was brought to my attention by Valve as they will be plastering warnings on any store fronts with macOS builds that don't support notarization to avoid users buying games they can't launch on their platform.

With regard to your issue, I've done a cursory Google search but haven't found anything of interest. I have a feeling it has to do with some sort of compositing or display scaling. When you get a chance, can you please try /fullscreendesktop 0 and see if that helps? If you're in the know about how to compile, etc, you might try adding some debugging to setupscreen() and find out what values you get from SDL's display queries.

[edonkeycoin]

Those are all good points. I hadn't thought about the Steam angle. What a mess...

I've got some contacts at Apple. I can bring up these issues and see if it goes anywhere.

On the problem itself, I did try it with fullscreen off (and on) and it didn't matter.

I tried stepping through setupscreen yesterday, but didn't really know what I was looking at. As mentioned earlier, think I'll try again but take notes of the values on Mojave and Catalina to see if I can spot any differences.

[qreeves]

It really does sound like the issues I had on Windows 7+ with DPI scaling, which required us to add a manifest stating the application was "DPI aware" (it isn't, this setting just stops the OS from doing DPI scaling and lets the app handle it itself). You could try throwing SDL_WINDOW_ALLOW_HIGHDPI into the window flags along with NSHighResolutionCapable in the app bundle Info.plist.

Documentation for SDL_CreateWindow may shed some light on this:

On Apple's OS X you must set the NSHighResolutionCapable Info.plist property to YES, otherwise you will not receive a High DPI OpenGL canvas.

If the window is created with the SDL_WINDOW_ALLOW_HIGHDPI flag, its size in pixels may differ from its size in screen coordinates on platforms with high-DPI support (e.g. iOS and Mac OS X). Use SDL_GetWindowSize() to query the client area's size in screen coordinates, and SDL_GL_GetDrawableSize() or SDL_GetRendererOutputSize() to query the drawable size in pixels.

And I also found these:

• https://nlguillemot.wordpress.com/2016/12/11/high-dpi-rendering/
• Correct out-of-the-box HiDPI support in SDL, GLFW and Android apps mosra/magnum#243
• GUI is blurry when using retina displays buggins/dlangui#72

If there's anything I can do to help, let me know. I might be able to replicate this on my mini by using custom scaling.

[edonkeycoin]

Thanks for the suggestions.

I tried adding the SDL_WINDOW_ALLOW_HIGHDPI flag to the SDL_CreateWindow call and the NSHighResolutionCapable to the info plist. Unfortunately I still see the same problem.

I also tried a clean rebuild in case the OS was caching something about the app's capabilities.

I'll follow those links to see if there are further hints.

[edonkeycoin]

I ended up working around this by forcing NSHighResolutionCapable to false in the plist. Apparently Catalina defaults NSHighResolutionCapable to true now.

Here's the post from the ioquake3 repo that gave me the hint to try this:

ioquake/ioq3#422 (comment)

It also discusses longer term solutions that would probably be applicable to redeclipse.

[qreeves]

Ah, perfect. Figures Ryan would know what to do. Really appreciate the work you put in here.

[qreeves]

OK, so I've pushed some changes to the development version that I hope fixes the issue, but as you're aware I can't really test it. If you can't create your own app bundle from our repository, I'll update you when I create the release candidate bundles so we can test it prior to the full release.

[edonkeycoin]

Thanks! I should be able to build with your changes this week when I'm back at the office. I'll let you know how it turns out.

[edonkeycoin]

My forked copy of redeclipse (based on 1.6.0) is really old and heavily modified. I tried merging in your changes but wasn't successful.

I tried a fresh build from the GitHub sources (verifying that your latest changes are there). But it won't run because it's missing certain dylibs, like libsteam_api.dylib (which I cut out of my fork because steam support is not needed).

Would it make sense for you to post your built redeclipse package (like via dropbox or something)? Once I have a working package, it should be straightforward to for me to drop in any new app binary built from the git sources.

Please let me know if you have another suggestion. Sorry that I'm a bit of a noob with this project.

[qreeves]

If you have Steam, I can give you a key for our pre-release access there. Just shoot me an email or jump on our Discord and ask me there. Failing that, I might be able to prepare a proper build. Unfortunately, you can't just drop a binary from the development version into the stable version as v2.0 is a complete overhaul of the game.

[qreeves]

I uploaded a bundle:

• https://drive.google.com/file/d/12-UBfGzTdop43sHROS9AKgznvHzKBcNF/view?usp=sharing

[edonkeycoin]

Sorry for the delay. Stuff going on at work...

I managed to try your bundle. Unfortunately there seems to be an issue with the redeclipse script. It ends up thinking that REDECLIPSE_HOME should be "home", then gets an error because it doesn't exist.

I worked around it by cd'ing the the app's Resources folder and ran the redeclipse_universal binary directly from there.

Unfortunately it still only displays a quarter of the screen in a larger window. I also tried my debug version built a couple of days ago (including your latest high res changes) and it fails in the same way.

Note that I also hid my /Library/Application Support/Red Eclipse folder and let it regenerate the default configs on the outside chance that that was related. But that didn't help.

Is there anything else that you'd like me to try?

[qreeves]

Yeah, as far as I know, if you do it that way then it won't evaluate Info.plist.

In that resources folder, rename Contents/MacOS/redeclipse to Contents/MacOS/redeclipse.tmp and then Contents/MacOS/redeclipse_universal to Contents/MacOS/redeclipse. That should run the binary directly when you double click the app bundle, skipping the script hacks.

[edonkeycoin]

I tried that (or something very much like it) first, but then the app can't find its own resource folder.

That's why I cd'd to the Resource sub directory first.

Is there a plan to move away from the scripted startup? In my fork of 1.6.0 I moved back to the approach where the main executable is the Mach-O app, and the build itself installs the resources rather than have them downloaded by the script.

Self modifying apps are kind of odd, especially on the Mac where there's been an increasing focus on digital signing (for good or ill).

[qreeves]

I added support for finding the resource directory to the binary, so try this: https://github.com/redeclipse/deploy/raw/master/master/macos.tar.gz

[edonkeycoin]

Thanks!

I copied both new files to where I thought they should go:

Contents/Resources/redeclipse.sh
Contents/Resources/bin/update.sh
Contents/Resources/bin/redeclipse.app/Contents/MacOS/redeclipse_universal
Contents/MacOS/redeclipse_universal

But when I launch from the Finder it still pops up the Terminal with an error about the "home" directory:

cd "/private/var/folders/6j/44dl3fh97zq74j9k3__8m8080000gn/T/AppTranslocation/25AE08C7-216B-4DFD-9ADB-D79695053E8D/d/redeclipse 2.app/Contents/Resources"; ./redeclipse.sh ; exit

The default interactive shell is now zsh.
To update your account to use zsh, please run `chsh -s /bin/zsh`.
For more details, please visit https://support.apple.com/kb/HT208050.
boot:~ me$ cd "/private/var/folders/6j/44dl3fh97zq74j9k3__8m8080000gn/T/AppTranslocation/25AE08C7-216B-4DFD-9ADB-D79695053E8D/d/redeclipse 2.app/Contents/Resources"; ./redeclipse.sh ; exit

Can not write to the requested home directory: home
Please ensure the directory exists and is writable by the current user.


There was an error running Red Eclipse.

Sorry if I'm missing something obvious here...

[qreeves]

Haha, sorry, I should've specified that you're gonna want to do the switch around with redeclipse and redeclipse_universal again.

[edonkeycoin]

Doh! Now I get it. I mistakenly reverted those changes to get back to the original state.

So after copying in your new redeclipse_universal (md5: 58332629dfff3e472c8758c7b2482ded), I'm back to the "Could not find config directory" error dialog indicating that it can't find the Resources folder.

Just to be clear, this is precisely what I did:

1. Started over from your original posted bundle from 3 days ago.
2. Copied in your new redeclipse_universal (58332629dfff3e472c8758c7b2482ded), replacing the one in the Contents/MacOS folder.
3. Copied in the other changed scripts from your post from today (redeclipse.sh and update.sh), although I know they probably won't be called.
4. Did the redeclipse and redeclipse_universal switcharoo.

At this stage, effectively the fundamental change is to call your new Mach-O binary instead of the script, right?

[qreeves]

Yeah, we're trying to get the .app bundle to run without calling a script basically, as we need Info.plist to tell the OS that the app is high resolution capable, otherwise SDL can't initialise it properly. These stupid hoops just to do something simple is why I hate Apple.

It looks like I did the code modification incorrectly, and I'm hoping I can get this working without having to actually dig up my mac mini to hook it up to a monitor and plug in a keyboard/mouse. If this next attempt doesn't work though, I'll have to resort to that though, as this isn't fair on you.

Try to grab the file again and do the same process, then run the .app as the bundle (not the binary directly): https://github.com/redeclipse/deploy/raw/master/master/macos.tar.gz

[edonkeycoin]

Don't worry about me. Happy to help.

It got a little further. Now the dialog displays this message:

Cannot execute config/version.cfg

I've verified that that file does exist in Resources/config/version.cfg.

Note that I've got family stuff going on so I might not be able to do too much more tonight.

[qreeves]

I need to sleep anyway, I'll pull out the mini when I wake up, get this sorted, and get back to you. Thanks for your help 😄

[q009]

macOS is no longer supported, unfortunately will have to close this