macOS WIP

Help test release candidates for the next release
Post Reply
User avatar
Z-Man
God & Project Admin
Posts: 11424
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: 11424
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: 11424
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: 11424
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: 11424
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: 11424
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 pm
maybe 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: 728
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.

Post Reply