Posted on 18 Aug 2022.
I recently upgraded from my old 2017 MacBook Air to a new 14-inch MacBook Pro, which was a big upgrade, but also brought along quite a few changes. The obvious upgrade is going from a 5th-gen mobile Intel CPU to an M1 Pro (over 6 times as fast with over 7 times better graphics), but this is also the first time I have a retina screen, and a 120Hz one at that.
In this blogpost I will explain some of the things I ran into when running my projects on this new hardware.
The main change of course was going from an Intel CPU with the x86_64 architecture, to an Apple Sillicon-CPU with the arm64 architecture. This turned out to not be all that noticeable for general use, mainly because most common apps have support for it natively at this point and Rosetta exists to translate any Intel-only software I use. I did need to make a few updates to some of my own projects to make them compile under arm64 properly.
Quite a few of my projects depend on SDL2, and I used to simply copy the framework into each projects' folder. However, this meant that quite a few different versions of SDL2 were being used by different projects, and some of the earlier projects used a version old enough that native M1 support was not yet added. This caused linking to fail because it could not find SDL2's symbols for the arm64 architecture.
This meant that I needed to update those projects to use a newer version of SDL2. I decided to change the way that I use SDL2 for all projects that needed it, by having a simlink in each project to a single folder and putting a single copy of SDL2 in there. This means that all projects now use the same version of SDL2, and that I can update it simply by putting the new version in there. As newer versions of SDL2 are universal (support both Intel and Apple Sillicon), this allowed all of those projects to now link correctly.
One of my projects depended on external libraries that don't have native support for Apple Sillicon.
This meant that, similar to SDL2, it failed to link. However, no native versions were available for these libraries.
The solution here was to add -target x86_64-apple-macos10.13 to the compilers arguments to have it compile for Intel instead.
This allowed it to link correctly, and the app can then be run through Rosetta.
Another of my projects gets build into a full app bundle and I wanted it to be a universal app.
Doing this required compiling the executable twice,
one with -target x86_64-apple-macos10.12 added to the compilers arguments to make it build for Intel,
and the other with -target arm64-apple-macos11 added to build it for Apple Sillicon.
The lipo-tool can be used to combine these into a single universal executable that can run on both,
by running lipo -create -output <out> <in-intel> <in-arm>
(with the <>-items subsistuted by the executables' names).
This can then be copied into an app bundle to make it universal.
The Apple Sillicon 14- and 16-inch MacBook Pro have ProMotion-screens, which support framerates up to 120 Hz. This means that code depending on V-Sync for timing will now run 120 times per second. I (apparently) had written quite a few thing that assumed V-Sync to be 60 Hz, and were now running too fast. These screens are also Retina (high-DPI) meaning that the size of windows are no longer equal to the size in pixels. This can make certain applications look somewhat blurred, or extra pixely (when using 3D-graphic APIs like OpenGL or Metal).
A few of my projects using SDL2 were using V-Sync to handle timing, and assumed this to be 60 Hz.
I needed to update these to detect the screens actual framerate and compensate accordingly.
To to this, I used SDL2's SDL_GetDisplayMode to get the framerate, and set up a (float) variable to be equal to the wanted FPS divided by the screens framerate.
This variable is added to a second variable starting at zero and the frame-update code is only run when it reaches 1 or more.
After running the frame-update (and only when it did run, meaning the second variable ended up >= 1), 1 gets subtracted from this variable.
Doing this allows the frame-update to be run at the wanted FPS, as long as the screen's framerate is at least that high.
Projects running in the browser using window.requestAnimationFrame might also run at 120 Hz now, but a similar technique could also be used here.
Safari does not do this though, and still runs such projects at 60 Hz even though the screen supports 120 Hz and does do scrolling and such at that rate.
Projects that use graphic-APIs like OpenGl or Metal (through SDL2) looked pixelated, due to those not being written with High-DPI awareness.
Fixing this involved adding SDL_WINDOW_ALLOW_HIGHDPI to the SDL_CreateWindow call,
and using SDL_GL_GetDrawableSize (for openGL) or drawableSize on a CAMetalLayer (for Metal) to get the size to set the viewport to.
I also needed to make sure to use that size for creating the texture used for the depth-attachment as well (for Metal).
Projects using SDL_Renderer look blurry, but in those cases that isn't that big of a problem, and I haven't looked into updating those yet.
The final thing that affected one of my projects was the fact that the default audio rate was now 48000 Hz instead of the 44100 it was on my old device.
For most projects this doesn't really matter, as most audio-API's have you set up the wanted audio rate and will internally resample if needed.
The exception to this though is the Web Audio API, which does not allow you to do this, and things using ScriptProcessorNode depend on this rate.
This causes audio to sound wrong and high-pitched. One of my projects did not properly adjust to the rate and was hitting this issue.
And that is a list of the things that needed adjustment when I switched to my new laptop. It goes to show that even for 'simple' projects, testing on different hardware can still expose problems and untrue preconceptions.