Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

macOS builds should be set to open in low resolution #421

Closed
angstsmurf opened this issue May 14, 2021 · 9 comments
Closed

macOS builds should be set to open in low resolution #421

angstsmurf opened this issue May 14, 2021 · 9 comments
Milestone

Comments

@angstsmurf
Copy link
Contributor

By default, macOS builds will open in high resolution, which will cause the game to display in a small quarter-sized area at the bottom corner of the window (At least until somebody fixes #364.) The application can be set manually to open in low resolution in the Finder, but it would be better if this was set automatically by the build process. Is this possible?

This Stackoverflow answer mentions writing the command line argument -AppleMagnifiedMode YES into the NSUserDefaults “registration domain”.

@cspiegel cspiegel added this to the 2021 Release milestone May 18, 2021
@cspiegel
Copy link
Contributor

Since this change sounds like it has a fairly large impact, I'm adding it to the 2021 milestone, in the hopes it can be addressed before the next release. Unfortunately I'm of no help on this issue, with my lack of macOS knowledge.

@angstsmurf
Copy link
Contributor Author

To be fair, as it is trivial to fix this manually by checking a box on the application info window in Finder, I'd say it is more of a minor annoyance for people that build it themselves. On the other hand, it can be a major annoyance before you know about that checkbox.

@erkyrath
Copy link

erkyrath commented Aug 8, 2021

This is now in a funny state. If I run the app without the "low resolution" flag, each window opens with the quarter-sized text bug. (The other three quarters of the window is solid red.) However, if I resize the window, it redisplays correctly and then it's fine after that.

Setting the "low resolution" flag still avoids the problem. However, it seems like the app is almost figuring out its own resolution, so maybe there's a way to get the rest of the way.

(Tested with Chris's macos-cmake-dmg branch on MacOS 11.5.1.)

@cspiegel
Copy link
Contributor

cspiegel commented Aug 8, 2021

I have no insight into the source of the problem. There are a couple points worth mentioning, though:

  1. Gargoyle can be built against Qt on macOS (with some simple tweaking of the CMake files), and when built with Qt, there are no issues with the resolution, at least for me: it opens at the proper size.
  2. The current code has a lot of deprecation warnings in the macOS files. It may take years for Apple to actually remove the deprecated code, and it may be trivial to fix, but for the time being, there is at least the potential that Gargoyle will fail to build on future macOS versions.

From my perspective the ideal solution would be to use Qt on macOS as well. Not only would that "fix" this bug and remove the deprecated code, but it would also mean there's only one piece of code for doing all the drawing. However, the current Mac launcher is more complex than the Windows/Unix one: while those just effectively replace the launcher with the interpreter, the Mac version keeps the launcher alive and allows new interpreters to be spawned while existing ones are running. There's communication between the interpreter and launcher which would need to be replicated so the functionality stays the same, which means it won't be in the next release.

But if we continue to band-aid the current version for the time being, that might be good enough to get a proper replacement in. It all depends on how feasible it is using Qt to mimic the current behavior.

@cspiegel
Copy link
Contributor

cspiegel commented Nov 6, 2021

I created a branch (https://github.com/cspiegel/garglk/tree/macos-no-hires) which disables hires mode via the plist file.

When I run in my VM, though, the rendering looks different than with hires mode turned on (after slightly resizing the window per Zarf's comment). With hires disabled, the text is slightly jagged. With hires enabled, the text is slightly blurry.

Is this an artifact of my VM and scaling, or is this something that happens on a real Mac? I'm not sure which one is better, honestly.

If "hires + resizing" is superior on real Macs, then a better solution is probably needed, even if it's as hacky as "resize by one pixel on startup" or something equally awful.

@angstsmurf
Copy link
Contributor Author

angstsmurf commented Nov 6, 2021

On a real Mac with a Retina screen, the lores mode looks sharper (and nicer, in my opinion) than the hires + resizing. I guess it would not be much point trying to screenshot the difference, but it might be that on a sufficiently high resolution screen, the jagged edges are too small to see and no longer a problem. (Edited for clarity.)

EDIT: Note that I'm talking about the in-game text here, not the window title, which obviously is a lot sharper in hires.

@cspiegel
Copy link
Contributor

cspiegel commented Nov 6, 2021

Ok, I've got a pull request for this at #550 now.

@cspiegel
Copy link
Contributor

cspiegel commented Nov 7, 2021

Merged. If it looks good to you, feel free to close this issue.

@angstsmurf
Copy link
Contributor Author

Looks good!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants