This just shows how little Apple cares about gaming on Mac. It's so sad that I spent thousands on multiple Mac devices (MBP, M Studio, etc.) only to be bottlenecked not by hardware, but by Apple's shitty approach to gaming software.
I know why they do it though. Apple can't take their undeserved 30% cut of Mac games the same way they take their iOS cuts.
We had a teacher years ago who said something that remains true until today: "everything is about money, especially the ones that appear to have non-monetary reasons."
wlesieutre · 23m ago
I think their bigger problem is there's shit for documentation. You get a big list of function signatures and if you actually want to know how you're supposed to use anything you find the WWDC session from 4 years ago and hope it's still accurate.
latexr · 20m ago
> I know why they do it though. Apple can't take their undeserved 30% cut of Mac games the same way they take their iOS cuts.
Why would Apple be deliberately sabotaging the experience? They would gain nothing from it. That argument makes even less sense when you consider most of the games mentioned in the article are on the Mac App Store, Apple can take their cut.
This is an obvious case of Hanlon’s Razor. Anyone who develops for Apple platforms and has had to file Feedbacks is aware of Apple’s incompetence and lack of care.
iwontberude · 47m ago
to be fair there is only so much you can do inside the power envelope of 100W or so
gchamonlive · 37m ago
Not really. If you compare it to gaming rigs, they bear radically different architectures, so you can't really compare them by TDP or power requirements. They don't emit the same hear or require the same amount of power per TFLOP. And I wouldn't be surprised if tflops also wouldn't translate to actual compute room for shaders.
Even if they did, 100w should be room enough to play relatively recent titles, specially indie ones. Nothing really excuses Apple from this contempt it has for the gaming market.
theandrewbailey · 19m ago
> Even if they did, 100w should be room enough to play relatively recent titles
Steamdeck runs on 45W, and that's plenty enough power to have fun.
DaiPlusPlus · 22m ago
> Nothing really excuses Apple from this contempt it has for the gaming market.
Considering how the typical self-identifying "gamer" conducts themselves online, I think Apple might be on to something...
Almondsetat · 22m ago
While the differences between ARM and x86 CPUs are quite substantial, Apple's iGPUs follow the same architecture as all the brands
reactordev · 1h ago
Oh it’s not just Apple…
This was an issue I also discovered on Xbox 360 in 2008. TV’s have overscan and depending on that setting, your resolutions will be off.
However, at the time, we couldn’t create render targets that matched the overscan safe area. XNA added a Screen SafeArea rect to help guide people but it was still an issue that you had to consciously develop for.
Now, we can create any back buffer size we want. It’s best to create one 1:1 or use DLSS with a target of 1:1 to the safe area for best results. I’m glad the author went and reported it but ultimately it’s up to developers to know Screen Resolution != Render Resolution.
Anyone using wgpu/vulkan/AppKit/SDL/glfw/etc need to know this.
DaiPlusPlus · 18m ago
If I understood you correctly... you wanted to be able to render to a slightly smaller surface to avoid wasting graphics compute time, but that's still going to be upscaled to 1080 for the HDMI scanout, and then mangled again by TVs' overscan - which to me feels like introducing more problems more severe than whatever problem you were trying to solve in the first place.
(Besides, TV overscan is a solved problem: instead of specifically rendering a smaller frame games should let users set a custom FoV and custom HUD/GUI size - thus solving 3 problems at once without having to compromise anything).
rustystump · 12m ago
Read up on g buffer and deferred rendering. Usually one doesnt do everything at full resolution until the final output and even then it is often better these days to have fancy upscaling.
Many games do let users set the things you mention but it is not always so simple. For example, handling rounded edges and notches is a huge pain.
ziml77 · 1h ago
Not mentioned about WoW in here is that they considered the notch enough to also have an option to have the UI avoid the notch. It calls a function in C_UI to get the safe region, and then resizes UIParent to fit within that region while still rendering the game up to the true top of the display.
pdpi · 49m ago
WoW has always been exceptionally good at treating macOS like a first-class citizen. It's a shame Blizzard has stopped supporting macOS for their newer games.
cosmic_cheese · 35m ago
Back in the day they even implemented near-zero-performance-impact video recording that leveraged AVKit/Quicktime as a Mac-exclusive feature, which was pretty neat. It let me get silky recordings where Windows user guildmates’ videos skipped and stuttered from having to run both WoW and much heavier third party recording software.
dontlaugh · 39m ago
Perhaps one or two people on that team have always had personal macs.
diebeforei485 · 6m ago
How can this be fixed without breaking existing software? Re-ordering the list?
debugnik · 25m ago
> But World of Warcraft is an older game using the legacy CoreGraphics display services full screen API. That API actually allows World of Warcraft to draw into the notch.
Not knowing much about Macs, I would have thought games were supposed to render full screen around the notch for immersion but respect the safe area for UI and gameplay. Are they supposed to leave a menu bar on macOS?
> Control gets around the issue by just making up its own resolutions.
That's hilarious, I wonder if they had trouble enumerating resolutions and gave up or if they simply couldn't bother.
TheJoeMan · 39m ago
I’m disappointed none of the proposed fixes are for CGDisplayCopyAllDisplayModes to have the “first” option on the list be the BEST option, taking into account the notch. The author hinted that many games pick the first option, so rather than demanding all those publishers add new code, Apple could make the easy path the happy path.
MBCook · 40m ago
Interesting article, but I think the demonstration image isn’t doing its job. Neither side really looks good to me. They both look roughly the same.
AndriyKunitsyn · 1h ago
Which says more about the volume of the market of gaming on Mac. It's small and unfortunate.
diath · 1h ago
It's actually really small, according to Steam Hardware Survey, Macs are only 1.88% of Steam users, which is less than that of Linux, which is probably why most developers don't care.
zamadatix · 1h ago
Between the deprecation and stagnation of OpenGL on the platform, the removal of 32 bit support completely, the refusal to natively support Vulkan in favor of Metal, and the switch to ARM based systems... I can't believe it's still that "high".
egypturnash · 45m ago
I do my work on a Mac. I game on a game machine. Which right now is a Steam Deck. In the past it's been PS4, 360, Gamecube, PS2, etc.
I think the only game I've put serious time into on my Mac was Hades 1, which I pretty much finished before the console ports happened.
add-sub-mul-div · 56m ago
It would be smaller than that overall because Steam stats are incomplete, they don't count all the Game Pass users. I haven't opened Steam in the six or so years I've been taking advantage of Microsoft providing a few hundred games for $10/month.
zamadatix · 1h ago
Also consider setting NSPrefersDisplaySafeAreaCompatibilityMode and just leave self letterboxing control to a toggle in the settings (with whatever default you prefer).
mushufasa · 1h ago
interesting -- I ran into this recently playing baldur gate 3 and was curious the technical details why. my fix was that I had an external monitor and I just reset the resolution to the external monitor. (by default, though, the monitor was showing up blurry though; with the wrong aspect ratio.)
thadk · 35m ago
How's factorio?
andrewmcwatters · 1h ago
Yes!
I remember first implementing this in Planimeter Game Engine 2D, we got a massive resolution list from SDL (through LÖVE, which is what we're built on).
If I remember correctly, we filtered the list ourselves by allowing users to explicitly select supported display ratios first, then showing the narrowed list from there. Not great. Technically there's a 683:384 ratio in there.[1]
But it did enough of the job that users who knew what resolution they wanted to pick in the first place didn't have to scroll a gargantuan list!
I know why they do it though. Apple can't take their undeserved 30% cut of Mac games the same way they take their iOS cuts.
We had a teacher years ago who said something that remains true until today: "everything is about money, especially the ones that appear to have non-monetary reasons."
Why would Apple be deliberately sabotaging the experience? They would gain nothing from it. That argument makes even less sense when you consider most of the games mentioned in the article are on the Mac App Store, Apple can take their cut.
https://apps.apple.com/us/app/control-ultimate-edition/id650...
https://apps.apple.com/us/app/shadow-of-the-tomb-raider/id14...
https://apps.apple.com/us/app/riven/id1437437535
https://apps.apple.com/us/app/cyberpunk-2077-ultimate/id6633...
https://apps.apple.com/us/app/stray/id6451498949
This is an obvious case of Hanlon’s Razor. Anyone who develops for Apple platforms and has had to file Feedbacks is aware of Apple’s incompetence and lack of care.
Even if they did, 100w should be room enough to play relatively recent titles, specially indie ones. Nothing really excuses Apple from this contempt it has for the gaming market.
Steamdeck runs on 45W, and that's plenty enough power to have fun.
Considering how the typical self-identifying "gamer" conducts themselves online, I think Apple might be on to something...
This was an issue I also discovered on Xbox 360 in 2008. TV’s have overscan and depending on that setting, your resolutions will be off.
However, at the time, we couldn’t create render targets that matched the overscan safe area. XNA added a Screen SafeArea rect to help guide people but it was still an issue that you had to consciously develop for.
Now, we can create any back buffer size we want. It’s best to create one 1:1 or use DLSS with a target of 1:1 to the safe area for best results. I’m glad the author went and reported it but ultimately it’s up to developers to know Screen Resolution != Render Resolution.
Anyone using wgpu/vulkan/AppKit/SDL/glfw/etc need to know this.
(Besides, TV overscan is a solved problem: instead of specifically rendering a smaller frame games should let users set a custom FoV and custom HUD/GUI size - thus solving 3 problems at once without having to compromise anything).
Many games do let users set the things you mention but it is not always so simple. For example, handling rounded edges and notches is a huge pain.
Not knowing much about Macs, I would have thought games were supposed to render full screen around the notch for immersion but respect the safe area for UI and gameplay. Are they supposed to leave a menu bar on macOS?
> Control gets around the issue by just making up its own resolutions.
That's hilarious, I wonder if they had trouble enumerating resolutions and gave up or if they simply couldn't bother.
I think the only game I've put serious time into on my Mac was Hades 1, which I pretty much finished before the console ports happened.
I remember first implementing this in Planimeter Game Engine 2D, we got a massive resolution list from SDL (through LÖVE, which is what we're built on).
If I remember correctly, we filtered the list ourselves by allowing users to explicitly select supported display ratios first, then showing the narrowed list from there. Not great. Technically there's a 683:384 ratio in there.[1]
But it did enough of the job that users who knew what resolution they wanted to pick in the first place didn't have to scroll a gargantuan list!
[1]: https://github.com/Planimeter/game-engine-2d/blob/v9.0.1/eng...