macOS WIP

Help test release candidates for the next release
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

macOS WIP

Post by Z-Man »

So yeah! It very much looks possible!

Technologies used:
homebrew to install the library and build dependencies
the regular unix autotools build process with a tiny tweak for OpenGL
dylibbundler to pack the required libraries into the app bundle and rewrite the executable to use those
create-dmg to pack a functional dmg (hdiutil would do fine, too)
The extra tools are on homebrew, so that's convenient.

The resources (Icons, metadata) were already in our git repository, the script src/macosx/build_bundle.sh does the work.

Well, and then you need a Mac...
Doing the real builds on a VM is out of the question; running macOS on non-Apple hardware against Apple's license (I'm morally flexible when it comes to dev and testing). Like it or don't. It's also against Apple's license to run too many virtual machines on one box, so renting a build machine, like we have for the other builds, is not an affordable option. Buying a machine just to do builds would be a silly proliferation of electronic junk, and inconvenient to boot.

Luckily, there are GitHub actions, and they can run on macOS. So this relatively simple action builds a client.

First build: armagetronad-0.2.8.3.7_alpha_z1600.dmg
It's from 0.2.8.3, so don't expect too much. Please test whether it works for you.

It's built on Catalina, so probably does not work on anything earlier, and is for Intel 64 bit only. Universal arm/intel binaries are not technically possible right now with this; either GitHub would need to provide Arm hardware or homebrew would need to enable cross compilation.
It's also unsigned. I hope that doesn't cause problems.

Integrating this somehow with the other builds is going to be a big Rube Goldberg Machine of Pain. I may resort to only manually triggering and uploading builds from time to time.
User avatar
voodoo
Core Dumper
Posts: 124
Joined: Wed Sep 27, 2006 11:51 am

Re: macOS WIP

Post by voodoo »

Good news. That would ease compilation on Mac.

I gave it a try on a MBP 15" 2018. It seems to handle "retina" resolution incorrectly. 2 different cases happened:
- In fullscreen mode, default resolution is desktop and it is the only one not working properly. Any other resolution works fine for me.
- in windowed mode, all resolution have the same issue. It looks like the rendering does not take into account the Retina display.

I'll try to compile from source when I save time.

Appart from that, no issue in game.
You do not have the required permissions to view the files attached to this post.
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Re: macOS WIP

Post by Z-Man »

Interesting. On Windows, we had similar problems: https://gitlab.com/armagetronad/armaget ... /issues/33
The solution there was to simply tell the system we're querying each screen's DPI setting and scale our stuff accordingly. Which we don't, but we're sort of doing the right things anyway (not completely; if you drag a window from a low-DPI to high-DPI screen, its pixel size is supposed to increase to keep the real size constant). If we don't, Windows is trying to do smart things that don't work with SDL and OpenGL. Maybe it's similar here; macOS lies to older applications about window sizes, lets them render at a lower resolution, and then scales the result up. The lie works, the upscaling does not. If we get it to not lie, all should be fine.


A quick google digs up this: https://stackoverflow.com/questions/185 ... retina-mac
To create a retina window, pass a flag SDL_WINDOW_ALLOW_HIGHDPI into SDL_CreateWindow().
May be SDL2 only, but worth a shot. Maybe that would also fix the Windows problems without changes in the metadata.
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Re: macOS WIP

Post by Z-Man »

Yeah, that flag is only there since SDL 2.0.1, and you then have to use two different functions to get your resolution; the regular ones will give sizes in points, only the new ones in pixels.

When you set a window size, is the size given in pixels or points? So, if you set an 800x600 Window, do you get a Window of 800x600 pixels on screen or one blown up to 1600x1200 pixels?

The only thing I came across would be the thing we did on Windows, given by the link above: In Plist.info you can set NSHighResolutionCapable. I did this in this build: https://sourceforge.net/projects/armage ... _z1621.dmg
Please test. I tried what I could, but I could not get a simulated retina display going in the virtual machine.

If that doesn't work, I wrote down the compilation steps I'm taking on the wiki. Those instructions should already work for all branches (minus the dmg creation, that's still in the merge train), so if you want to take a shot at SDL_WINDOW_ALLOW_HIGHDPI on trunk, you can.
User avatar
voodoo
Core Dumper
Posts: 124
Joined: Wed Sep 27, 2006 11:51 am

Re: macOS WIP

Post by voodoo »

When I set 640x480 as in the screenshot, the resulting window size in pixel is obviously doubled. And indeed, when I set a very high resolution, the window does not fit on screen at all. So the rendering is done in pixel while the window size is not.

Sadly, the new build does not fix the issue.
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Re: macOS WIP

Post by Z-Man »

Well, it might have been the other way round; when we request 800x600, we get 800x600 pixels and render to 400x300.

Anyway, try again: https://download.armagetronad.org/stagi ... _z1625.dmg

This time, I set NSHighResolutionCapable to False. Best case result would be that when you request an 800x600 window, you get a 1600x1200 one, we render 800x600 and that gets blown up to the whole window size by the system.

If that does not work, can you go into the app bundle, edit Plist.info and remove these two lines:

Code: Select all

	<key>NSPrincipalClass</key>
	<string>NSApplication</string>
Other than those two, I'm out of ideas. Looking arond the web, I only find people trying with SDL 1 and giving up:
https://forums.libsdl.org/viewtopic.php?p=33639
https://gist.github.com/vectorstorm/5340842

On 0.4 with SDL2, this seems to be properly solvable, though. One more reason to get that done.
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Re: macOS WIP

Post by Z-Man »

Another build to try in addition to the one from the last post:
https://download.armagetronad.org/stagi ... _z5072.dmg
This one is from 0.4 where we do use SDL 2 (Based on voodoo's own work, IIRC). Essentially, it changes some things with initialization and for all OpenGL relevant coordinates, uses the output of SDL_GL_GetDrawableSize. I can only test it as a mock.

And oddly, while just CTRL/right click open on the previous app bundle allowed me to run the game, with this one, I had to open its contents and also do the same thing on the launcher script. Signing these is going to be mandatory. Joy.

And since that is going to throw money into the jaws of Apple, and I'm without a usable laptop for quite a lot of years, and I don't very much like the build ping-pong to GitHub, I'm considering getting a used MacBook. I'm hovering over either a MacBook Pro or MacBook Air (8 GB!) from 2015. Apparently, later models all have the not-so-great keyboard from the MacBook (2015 and later). The Pro would be more powerful and has better chances of being supported a bit longer, but the hardware of the Air seems to be more robust (No Retina -> no Staingate). I expect both to fall out of support from Apple rather sooner than later; but no problem, both run Linux fine now and it's not against the TOS to run a macOS VM inside Linux running on a Mac :) That would be enough for building, and a buildbot does not need all of the security fixes. It's going to be a bit tough running a VM on 8GB, maybe I can nab a 16 GB Pro.
Thoughts on the hardware choice?
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Re: macOS WIP

Post by Z-Man »

Z-Man wrote: Thu Feb 18, 2021 10:52 pmmaybe I can nab a 16 GB Pro.
Turns out, I can! 512 GB SSD, too, and a fresh battery. This should do fine for years, and it only cost an arm and half a leg. (520 Euro instead of the 400 I used to aim for with past used notebooks, seems fair) <happy dance>

Edit: The two tests didn't work for me. The 0.2.8 one just shows the usual error, the 0.4 one tries to open a window several times, then crashes. Oh well, I'm sure glad I should be able to iterate on these locally.
User avatar
delinquent
Match Winner
Posts: 760
Joined: Sat Jul 07, 2012 3:07 am

Re: macOS WIP

Post by delinquent »

Bear in mind, the compat layer for the M1 based macs is flaky at best. I wouldn't even bother trying to build for it right now, especially since their market share will be minimal for some time yet.
User avatar
voodoo
Core Dumper
Posts: 124
Joined: Wed Sep 27, 2006 11:51 am

Re: macOS WIP

Post by voodoo »

Same behaviour as yours on both 0.2.9 and 0.4. First one still shrink the rendering in the lowest left corner. 0.4 crash too.
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Re: macOS WIP

Post by Z-Man »

I'll have to give up solving the 0.2.X Retina problem in code. In principle, it's super easy to get the information, it's all in the Cocoa_GL_GetDrawableSize function in the SDL2 code. But the required NSView is not accessible in SDL 1.2. You'd think it would be in SDL_SysWMinfo, but that's also only for SDL2. It's too deeply hidden to dig out :(
And setting NSHighResolutionCapable to false would be the right approach and should work (giving us a scaled up rendering, but still); the official docs even say so:
If you don’t opt in, the system magnifies the rendered results.
The default for NSHighResolutionCapable changed from false to true some time back, but still, explicitly setting it to false should give the scaling behavior. Oh well.
And it's not that that old behavior is unavailable: If I'm using a low-DPI external monitor, let the game window create itself there, then drag it over to the high DPI display, it does get scaled. It's just that we don't have control.
A small hope is left, the build system is going to use an older macOS version. Results may depend on which SDK you use for building.

delinquent: Yeah, I'm not going to bother cross compiling for M1 just yet. Rosetta2 should do the job without trouble. Considering that they deprecated OpenGL, explicitly mentioning that it's because Metal is better adapted to their own hardware, I'd bet that if they shut down Rosetta 2, they cut off OpenGL at the same time, at least on M1 Macs. And then it's lights out for us anyway.
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Re: macOS WIP

Post by Z-Man »

That small hope? Works for me! The build now uses a Mojave VM, that must be just far enough back in time so the non-Retina compatibility mode can be activated.
First result is here, still not signed.
0.2.9: https://download.armagetronad.org/blog/ ... pha_z2567/
0.2.8.3: https://download.armagetronad.org/blog/ ... pha_z1644/
0.4 (still crashes): https://download.armagetronad.org/blog/ ... pha_z5104/

I'll tackle the signing and 0.4 crash in no particular order; the Apple Developer ID stuff seems to take a bit of time.
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Re: macOS WIP

Post by Z-Man »

https://download.armagetronad.org/blog/ ... pha_z5123/

Startup crash is fixed. The problem was that we requested a regular SDL renderer, which apparently doesn't work together with OpenGL on macOS. Full Retina display support is implemented because on 0.4 and SDL2, we can do that. The macOS version even gets a toggle in the screen setup where you can choose whether windowed mode uses the full resolution or half that (only for screens macOS considers high DPI, of course), and in either mode, dragging the window between screens of different resolutions works. Bonus for all operating systems: Now the game window is resizable, which also means typical shortcuts to make the window occupy, say, the top left quarter of the screen, just work.
User avatar
sinewav
Graphic Artist
Posts: 6413
Joined: Wed Jan 23, 2008 3:37 am
Contact:

Re: macOS WIP

Post by sinewav »

Z-Man wrote: Sat Mar 13, 2021 3:39 pmNow the game window is resizable...
:o Wow, didn't see that coming. Very cool and thanks!
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Re: macOS WIP

Post by Z-Man »

Well, it would be actually useful if the cockpit would not mess itself up for nonstandard aspect ratios, but at least, that defines my priorities :D
Post Reply