Even with the M2 Pro, Mac gaming is as bad as it’s ever been(macworld.com)
macworld.com
Even with the M2 Pro, Mac gaming is as bad as it’s ever been
https://www.macworld.com/article/1485513/mac-mini-m2-pro-gaming-resident-evil-village-pc-graphics.html
7 comments
> But Valve should be the one making Proton compatible with Macs
Why on earth would they do that? That gives them absolutely no competitive advantage. Linux allows them to build Steam Machines and Decks. MacOS gives them nothing.
Proton uses Wine and translates DirectX calls to Vulkan when required. Apple chose to be hostile to Vulkan so the current project has different requirements anyway.
Why on earth would they do that? That gives them absolutely no competitive advantage. Linux allows them to build Steam Machines and Decks. MacOS gives them nothing.
Proton uses Wine and translates DirectX calls to Vulkan when required. Apple chose to be hostile to Vulkan so the current project has different requirements anyway.
> MacOS gives them nothing
It increases Steam sales which increases their profits. Probably not by a great deal, but gaming on Mac is a bit of a chicken and egg situation. No-one does it because it sucks, and it sucks because no-one does it.
It increases Steam sales which increases their profits. Probably not by a great deal, but gaming on Mac is a bit of a chicken and egg situation. No-one does it because it sucks, and it sucks because no-one does it.
> It increases Steam sales
I would need a citation on that. These folks already purchased a Mac, so they went in already knowing that they are never going to actually play games on it so it couldn't have been a priority.
I would need a citation on that. These folks already purchased a Mac, so they went in already knowing that they are never going to actually play games on it so it couldn't have been a priority.
See I just don't believe apple supporting Vulcan* would change anything - Metal has a vast install base of consumers that most studies show are happier paying for things than the android and linux consumer bases. The reality is that game developers target consoles with their proprietary APIs, on windows they use DirectX or GPU vendor specific paths. A small subset also might support whatever the current open-graphics API is, but they're a clear minority, and it's a secondary platform.
Apple adding support for Vulcan just wouldn't change that - linux+Mac users combined don't come close to the windows game market, let alone the consoles, when you add in to that supporting directx giving you windows and xbox, there's no competition.
Obviously Apple could start paying devs to support Mac+ios, but again they'd have to do that whether their main api was metal or Vulcan, so given all their shipping hardware is designed for Metal (whatever that means), what would be the benefit in switching to a new graphic library? (other than making new games not work on otherwise functional older hardware and being accused of artificial obsolescence)
*it was at this point I gave up fighting autocorrect
Apple adding support for Vulcan just wouldn't change that - linux+Mac users combined don't come close to the windows game market, let alone the consoles, when you add in to that supporting directx giving you windows and xbox, there's no competition.
Obviously Apple could start paying devs to support Mac+ios, but again they'd have to do that whether their main api was metal or Vulcan, so given all their shipping hardware is designed for Metal (whatever that means), what would be the benefit in switching to a new graphic library? (other than making new games not work on otherwise functional older hardware and being accused of artificial obsolescence)
*it was at this point I gave up fighting autocorrect
Vulkan is supported via MoltenVK.
https://en.m.wikipedia.org/wiki/MoltenVK
The problem is that no one is actually interested.
https://en.m.wikipedia.org/wiki/MoltenVK
The problem is that no one is actually interested.
I used to play a lot of games on macOS using Wine but the reason many newer games don’t work and DXVK isn’t available on macOS is because Metal lacks some features that have been difficult for MoltenVK to emulate. This means that MoltenVK is only useful if your application/game doesn't rely on those features.
You can find all the details in this issue:
- https://github.com/KhronosGroup/MoltenVK/issues/203
Reading the latest comments there it sounds like things may improve once Metal 3 is out.
You can find all the details in this issue:
- https://github.com/KhronosGroup/MoltenVK/issues/203
Reading the latest comments there it sounds like things may improve once Metal 3 is out.
> The problem is that no one is actually interested.
Exactly my thought. Even assuming there's a general "Mac people spend more than PC people" trend, you're still talking about a relatively tiny amount of the market.
Exactly my thought. Even assuming there's a general "Mac people spend more than PC people" trend, you're still talking about a relatively tiny amount of the market.
Some Nvidia GPUs draw more than 3x the power of a MacMini. The recommended PSU is 10x (500W to 50W)
Something gotta give
But Valve should be the one making Proton compatible with Macs.
Why is the onus on the smaller company to make games compatible with Mac and not, say, the world's biggest tech company?
Macs are largely incompatible with gaming because of Apple's decisions. And Apple customers who are into gaming usually dual-boot into Windows to game, because Windows is (and for several decades, has been) the superior OS for gaming.
Why is the onus on the smaller company to make games compatible with Mac and not, say, the world's biggest tech company?
Macs are largely incompatible with gaming because of Apple's decisions. And Apple customers who are into gaming usually dual-boot into Windows to game, because Windows is (and for several decades, has been) the superior OS for gaming.
Sadly dual booting isn’t really an option anymore. Apple Silicon based Macs do still have the ability to dual boot, but there’s no Windows-on-Arm builds available for them. Also, Apple actually made (or supplied, depending how you looked at it) all the Windows drivers for the various Intel Mac devices that could dual boot Windows. If Microsoft decided to target Apple Silicon, it would have to be a team effort with Apple to make all the drivers available. It would be an extra difficult thing to do because Apple Silicon now uses custom GPUs where before they were just the standard Intel iGPU or Nvidia/AMD discreet GPUs.
Mac gaming is better than it's ever been — it's just that the author has a massive blind spot. The future of macOS gaming is iOS gaming.
Steam has ~50K games¹. The App Store has somewhere in the neighborhood of a million iOS games¹. You can probably guess where Apple is focusing its resources.
Apple's gaming strategy isn't to persuade game developers to support macOS. Their strategy is to make iOS a great game platform from both a technical and business perspective, and in turn for macOS to have amazing support for iOS games. This is a significant part of the Apple Silicon story.
Supporting that strategy is Apple Arcade, a subscription gaming product that is effectively their Netflix for games. It's tough to find data on how popular it is, but game developer was quoted as saying that Apple Arcade has more than 100 million subscribers².
Of course, Apple isn't building a gaming ecosystem for Serious Players. They're targeting the mass market — people whose primary identity may not be "Gamer", but who enjoy games from SimCity to Civilization, and from Angry Birds to Sneaky Sasquatch. And they're doing it in plain sight.
¹ A large percentage of which are crap, yes.
² https://www.imore.com/gaming/football-managers-miles-jacobso...
Steam has ~50K games¹. The App Store has somewhere in the neighborhood of a million iOS games¹. You can probably guess where Apple is focusing its resources.
Apple's gaming strategy isn't to persuade game developers to support macOS. Their strategy is to make iOS a great game platform from both a technical and business perspective, and in turn for macOS to have amazing support for iOS games. This is a significant part of the Apple Silicon story.
Supporting that strategy is Apple Arcade, a subscription gaming product that is effectively their Netflix for games. It's tough to find data on how popular it is, but game developer was quoted as saying that Apple Arcade has more than 100 million subscribers².
Of course, Apple isn't building a gaming ecosystem for Serious Players. They're targeting the mass market — people whose primary identity may not be "Gamer", but who enjoy games from SimCity to Civilization, and from Angry Birds to Sneaky Sasquatch. And they're doing it in plain sight.
¹ A large percentage of which are crap, yes.
² https://www.imore.com/gaming/football-managers-miles-jacobso...
How many people who can afford a Mac can't ALSO afford a gaming PC? I'd say VERY few. Also, gaming graphical quality probably isn't your goal if you DO choose to game on a Mac. Macs are notoriously underpowered when it comes to gaming.
To add to that, Macs are notorious for not supporting many games. The games that ARE ported are mostly made by big companies, who's profits on the game is so high that hiring a small team to port it to Mac is a small expenditure. Why not port it, eh?
Still, I think gaming on Mac would be in a much better place if they didn't have such a tedious app release process. Having to install xcode (which is an abysmal IDE until you FORCE yourself to unlearn everything you know about, you know, how a reasonable IDE should work!) and sign apps is just pointless drudgework. Unity should handle all of this, but I assume that no one at Apple is returning Unity's calls.
Greasing the flywheel of indie devs is generally a good way to build up your gaming platform.
To add to that, Macs are notorious for not supporting many games. The games that ARE ported are mostly made by big companies, who's profits on the game is so high that hiring a small team to port it to Mac is a small expenditure. Why not port it, eh?
Still, I think gaming on Mac would be in a much better place if they didn't have such a tedious app release process. Having to install xcode (which is an abysmal IDE until you FORCE yourself to unlearn everything you know about, you know, how a reasonable IDE should work!) and sign apps is just pointless drudgework. Unity should handle all of this, but I assume that no one at Apple is returning Unity's calls.
Greasing the flywheel of indie devs is generally a good way to build up your gaming platform.
> Having to install Xcode (
..you mean you don't have to install developer tools on your platform?
> which is an abysmal IDE until you FORCE yourself to unlearn everything you know about, you know, how a reasonable IDE should work!
Plenty of people love Xcode, it's likely you're interpreting "different from how my IDE works" as "clearly incorrect". Having spent plenty of time dealing with MSVC, Netbeans, various Borland IDEs, etc over my life Xcode seems perfectly fine, and clearly better than msvc.
> ) and sign apps is just pointless drudgework.
Signing apps is not drudge work, but also is not hard.
> Unity should handle all of this, but I assume that no one at Apple is returning Unity's calls.
Based on what I see from the game industry I would assume no one at Unity is calling Apple in the first place, and I would assume that if being ignored is happening in any direction it's unity ignoring apple.
..you mean you don't have to install developer tools on your platform?
> which is an abysmal IDE until you FORCE yourself to unlearn everything you know about, you know, how a reasonable IDE should work!
Plenty of people love Xcode, it's likely you're interpreting "different from how my IDE works" as "clearly incorrect". Having spent plenty of time dealing with MSVC, Netbeans, various Borland IDEs, etc over my life Xcode seems perfectly fine, and clearly better than msvc.
> ) and sign apps is just pointless drudgework.
Signing apps is not drudge work, but also is not hard.
> Unity should handle all of this, but I assume that no one at Apple is returning Unity's calls.
Based on what I see from the game industry I would assume no one at Unity is calling Apple in the first place, and I would assume that if being ignored is happening in any direction it's unity ignoring apple.
> ..you mean you don't have to install developer tools on your platform?
People always ask me this when I complain about xcode and I don't understand where they're coming from. Have you developed apps for Linux or Windows? You don't need to use a specific IDE to sign your code, I can tell you that much.
> Plenty of people love Xcode
Well, I haven't met one. All of the iOS developers I know tell me "Yeah, it's a weird bird, but you gotta learn it". Have you experienced otherwise?
> Having spent plenty of time dealing with
Well let's all stop discussing the relative merits of things, olliej has spoken about what's good or bad. Everyone else's thoughts and opinions are meaningless.
> Signing apps is not drudge work, but also is not hard.
Shrug Difference of opinion, I guess.
People always ask me this when I complain about xcode and I don't understand where they're coming from. Have you developed apps for Linux or Windows? You don't need to use a specific IDE to sign your code, I can tell you that much.
> Plenty of people love Xcode
Well, I haven't met one. All of the iOS developers I know tell me "Yeah, it's a weird bird, but you gotta learn it". Have you experienced otherwise?
> Having spent plenty of time dealing with
Well let's all stop discussing the relative merits of things, olliej has spoken about what's good or bad. Everyone else's thoughts and opinions are meaningless.
> Signing apps is not drudge work, but also is not hard.
Shrug Difference of opinion, I guess.
> People always ask me this when I complain about xcode and I don't understand where they're coming from. Have you developed apps for Linux or Windows?
Yes. For many years. And those platforms also require you to install the toolchains for your target platforms. On macOS those toolchains come with a IDE, but there's no need nor requirement to use it. As demonstrated by large numbers of Mac devs using emacs, vim, vscode, etc all of which use a separately installed toolchain on every platform. On your various linux systems you're using apt-get or similar to install the toolchains and SDKs, on windows you're having to download and install them as well (historically having to pay for the toolchain as part of MSVC or such, but I assume that that's no longer the case).
> You don't need to use a specific IDE to sign your code, I can tell you that much.
You don't need to use Xcode to do that either, you can think of it as the dev tools also include a UI you can use, but can also ignore.
> Well, I haven't met one. All of the iOS developers I know tell me "Yeah, it's a weird bird, but you gotta learn it". Have you experienced otherwise?
Yes, that's literally what I said. It's also the IDE I've tended to prefer over the years, easily better than MSVC in my experience, but again that could be because I've learned and prefer Xcode to MSVC. OTOH I was also using MSVC a long time prior to Xcode so I didn't arrive at Xcode with no prior IDE experience.
> > Having spent plenty of time dealing with
> Well let's all stop discussing the relative merits of things, olliej has spoken about what's good or bad. Everyone else's thoughts and opinions are meaningless.
While I agree I should have said "in my opinion Xcode is better than msvc", but I also didn't say any one else's thoughts and opinions were meaningless. In fact the whole crux of my comment was that you were passing your dislike of Xcode as though it were objective fact rather than an opinion.
> > Signing apps is not drudge work, but also is not hard.
> Shrug Difference of opinion, I guess.
see above, it's a single command line that you can put in a makefile or whatever.
Yes. For many years. And those platforms also require you to install the toolchains for your target platforms. On macOS those toolchains come with a IDE, but there's no need nor requirement to use it. As demonstrated by large numbers of Mac devs using emacs, vim, vscode, etc all of which use a separately installed toolchain on every platform. On your various linux systems you're using apt-get or similar to install the toolchains and SDKs, on windows you're having to download and install them as well (historically having to pay for the toolchain as part of MSVC or such, but I assume that that's no longer the case).
> You don't need to use a specific IDE to sign your code, I can tell you that much.
You don't need to use Xcode to do that either, you can think of it as the dev tools also include a UI you can use, but can also ignore.
codesign -s "MY Certificate Here" my.app
> Well, I haven't met one. All of the iOS developers I know tell me "Yeah, it's a weird bird, but you gotta learn it". Have you experienced otherwise?
Yes, that's literally what I said. It's also the IDE I've tended to prefer over the years, easily better than MSVC in my experience, but again that could be because I've learned and prefer Xcode to MSVC. OTOH I was also using MSVC a long time prior to Xcode so I didn't arrive at Xcode with no prior IDE experience.
> > Having spent plenty of time dealing with
> Well let's all stop discussing the relative merits of things, olliej has spoken about what's good or bad. Everyone else's thoughts and opinions are meaningless.
While I agree I should have said "in my opinion Xcode is better than msvc", but I also didn't say any one else's thoughts and opinions were meaningless. In fact the whole crux of my comment was that you were passing your dislike of Xcode as though it were objective fact rather than an opinion.
> > Signing apps is not drudge work, but also is not hard.
> Shrug Difference of opinion, I guess.
see above, it's a single command line that you can put in a makefile or whatever.
> those platforms also require you to install the toolchains for your target platforms
No, that's not true. There are multiple toolchains for Linux and Windows. You don't have to use a specific one.
> No one is forced to use Xcode
Not only are you forced to install xcode, if your Mac is too old, you can't get the latest xcode, and you can't develop apps for iOS. If you don't have a Mac, you can't even develop apps for iOS or Mac.
> that's literally what I said
No, it isn't. You said lots of people like XCode, and I'm saying that you're the only one I've ever heard of.
> you were passing your dislike of Xcode as though it were objective fact
Yes, I think it's a well-known fact that most Mac/iOS devs do not like XCode.
> a single command line that you can put in a makefile or whatever
Yes but getting to that single command isn't easy. That's like saying time travel is easy, you just need to press the "go" button on the time machine (which needs to be invented).
No, that's not true. There are multiple toolchains for Linux and Windows. You don't have to use a specific one.
> No one is forced to use Xcode
Not only are you forced to install xcode, if your Mac is too old, you can't get the latest xcode, and you can't develop apps for iOS. If you don't have a Mac, you can't even develop apps for iOS or Mac.
> that's literally what I said
No, it isn't. You said lots of people like XCode, and I'm saying that you're the only one I've ever heard of.
> you were passing your dislike of Xcode as though it were objective fact
Yes, I think it's a well-known fact that most Mac/iOS devs do not like XCode.
> a single command line that you can put in a makefile or whatever
Yes but getting to that single command isn't easy. That's like saying time travel is easy, you just need to press the "go" button on the time machine (which needs to be invented).
The new mac mini is $599.
And if you buy it, you're choosing convenience and ease of use over raw performance and upgradeability. If someone can make that choice, they can probably drop another $600 on a gaming PC to go along with it.
I feel like for a long time Apple considered games to be just toys for kids, and were completely perplexed about adults gaming. It didn't help that nearly all Intel Macs had such a low-end GPUs that they only could play Nintendo-style games.
Supporting only Metal made macOS-native gaming left with mostly quick ports of iPad games. Economics of App Store, touchscreen controls on iOS, and the "family-friendly" curation of the App Store means that designed-for-Metal games are mostly bargain bin, simple short arcade games.
I think this might be slowly changing. Apple has added official support for controllers (they worked before, but Apple acknowledging their existence is new). Addition of MetalFX is a nice surprise, since upscaling is still a desirable new feature in PC/AAA gaming. In the old days Apple's OpenGL drivers were left to bitrot, lagging far behind everyone else, so the fact they've added something not-outdated-yet is nice.
They still need to acknowledge Vulkan exists. Even if Apple doesn't plan to add Vulkan themselves, it'd be nice to have some assurance that Apple won't suddenly break or ban solutions like MoltenVK.
Supporting only Metal made macOS-native gaming left with mostly quick ports of iPad games. Economics of App Store, touchscreen controls on iOS, and the "family-friendly" curation of the App Store means that designed-for-Metal games are mostly bargain bin, simple short arcade games.
I think this might be slowly changing. Apple has added official support for controllers (they worked before, but Apple acknowledging their existence is new). Addition of MetalFX is a nice surprise, since upscaling is still a desirable new feature in PC/AAA gaming. In the old days Apple's OpenGL drivers were left to bitrot, lagging far behind everyone else, so the fact they've added something not-outdated-yet is nice.
They still need to acknowledge Vulkan exists. Even if Apple doesn't plan to add Vulkan themselves, it'd be nice to have some assurance that Apple won't suddenly break or ban solutions like MoltenVK.
Im not sure why Vulkan keeps being raised here: Steam/proton demonstrate that windows developers aren't interested in Vulcan either, it's directx or bust, and then "supporting" linux is just done via Wine. If
Steam/proton aren't going to work for Mac any time soon as they're fundamentally "run a x86 windows game in a translator", and as far as I can make out wine requires 32bit hardware to emulate the win32 environment (also, why do windows devs who ostensibly care about performance but still ship 32bit binaries?).
Steam/proton aren't going to work for Mac any time soon as they're fundamentally "run a x86 windows game in a translator", and as far as I can make out wine requires 32bit hardware to emulate the win32 environment (also, why do windows devs who ostensibly care about performance but still ship 32bit binaries?).
> Im not sure why Vulkan keeps being raised here: Steam/proton demonstrate that windows developers aren't interested in Vulcan either, it's directx or bust
I think you're making some rather broad assumptions about why developers aren't targeting Linux natively vs. relying on WINE/Proton being a lack of interest in Vulkan.
The major complaint I see from Windows game developers WRT supporting Linux is the still insane situation of shipping executables for Linux userspace as it exists today. The first challenge everyone encounters attempting it is that glibc overtly doesn't support static-linking. That renders practically every mainstream linux distro largely incapable of even producing statically-linked executables utilizing external dependencies. Go ahead, try it. Arch Linux doesn't even install the .a files of every library it has .h and .so files installed for. Arch literally goes out of its way to strip them from packages. Even if you do manage to stay within a small enough set of deps to succeed, gcc will spit out warnings about static linking being unsupported due to stuff like nsswitch.
The whole exercise is immediately maddening and discouraging, and everything you see screams RUN AWAY.
Game developers already target myriad graphics APIs simply from shipping on consoles as well. There are already GL libraries to hide such annoyances if you're not determined to eek out every last bit of GPU performance.
The instant Proton/WINE became a reliable way to ship binaries for every linux distro under the sun that Just Work, most developers abandoned even figuring out how to build equivalent native linux binaries.
It's so crazy you can actually more successfully produce statically-linked Windows and MacOS binaries of an SDL2+SDL2_Mixer et al using game, on Linux, via mingw and osxcross toolchains, than you can produce equally statically-linked Linux executables, from within linux, if attempting to use the distro-provided libraries. I'm a long-time Linux user+developer, as FOSS/Linux/GNU-biased as you'll find, and even I will shout from the rooftops THIS IS INSANITY. The new shiny way to paper over this embarrassment is containers; a host-like instance full of dynamically linked dependencies per executable! Brilliant.
I think you're making some rather broad assumptions about why developers aren't targeting Linux natively vs. relying on WINE/Proton being a lack of interest in Vulkan.
The major complaint I see from Windows game developers WRT supporting Linux is the still insane situation of shipping executables for Linux userspace as it exists today. The first challenge everyone encounters attempting it is that glibc overtly doesn't support static-linking. That renders practically every mainstream linux distro largely incapable of even producing statically-linked executables utilizing external dependencies. Go ahead, try it. Arch Linux doesn't even install the .a files of every library it has .h and .so files installed for. Arch literally goes out of its way to strip them from packages. Even if you do manage to stay within a small enough set of deps to succeed, gcc will spit out warnings about static linking being unsupported due to stuff like nsswitch.
The whole exercise is immediately maddening and discouraging, and everything you see screams RUN AWAY.
Game developers already target myriad graphics APIs simply from shipping on consoles as well. There are already GL libraries to hide such annoyances if you're not determined to eek out every last bit of GPU performance.
The instant Proton/WINE became a reliable way to ship binaries for every linux distro under the sun that Just Work, most developers abandoned even figuring out how to build equivalent native linux binaries.
It's so crazy you can actually more successfully produce statically-linked Windows and MacOS binaries of an SDL2+SDL2_Mixer et al using game, on Linux, via mingw and osxcross toolchains, than you can produce equally statically-linked Linux executables, from within linux, if attempting to use the distro-provided libraries. I'm a long-time Linux user+developer, as FOSS/Linux/GNU-biased as you'll find, and even I will shout from the rooftops THIS IS INSANITY. The new shiny way to paper over this embarrassment is containers; a host-like instance full of dynamically linked dependencies per executable! Brilliant.
macos doesn’t support statically linking to libsystem.dylib (equivalent of glibc) and windows doesn’t have a static version of kernel32.dll. The problem isn’t dynamic vs. static linking, it’s that linux distros don’t offer backwards compatibility (although the linux kernel does). The whole static vs dynamic arguments people make is so weird to me, as what real apps do is ship the dlls/frameworks they need alongside the executable.
I've personally shipped some small cross-platform games for win+macos+linux, and it's rather trivial to produce the statically-linked versions for windows and macos even from within Linux.
When the experience you encounter attempting the same thing for the linux build is an actively developer-hostile environment the moment you attempt to shove -static in your LDFLAGS and --static in your pkg-config flags, the message seems rather loud and clear: "We don't want you easily shipping standalone proprietary binaries on our systems avoiding learning and using our package management machinery!"
It's rather desirable to hand out standalone executables for such simple isolated programs as games.
Your claim that games don't statically link when possible strikes me as rather odd. It's such a common practice that SDL added an escape hatch to divert SDL calls to another libSDL at runtime [0]. Because sometimes you want a newer SDL to fix/support some newfangled stuff, and not be stuck with the statically linked version. Do you really think the SDL devs would bother with such a thing if it weren't a common practice?
[0] https://github.com/libsdl-org/SDL/blob/release-2.26.2/src/dy...
When the experience you encounter attempting the same thing for the linux build is an actively developer-hostile environment the moment you attempt to shove -static in your LDFLAGS and --static in your pkg-config flags, the message seems rather loud and clear: "We don't want you easily shipping standalone proprietary binaries on our systems avoiding learning and using our package management machinery!"
It's rather desirable to hand out standalone executables for such simple isolated programs as games.
Your claim that games don't statically link when possible strikes me as rather odd. It's such a common practice that SDL added an escape hatch to divert SDL calls to another libSDL at runtime [0]. Because sometimes you want a newer SDL to fix/support some newfangled stuff, and not be stuck with the statically linked version. Do you really think the SDL devs would bother with such a thing if it weren't a common practice?
[0] https://github.com/libsdl-org/SDL/blob/release-2.26.2/src/dy...
You can statically link SDL2 itself, but you are still dynamically linking to libsystem, Cocoa and a collection of other dynamic libraries provided by the system. Same thing on Windows, you are dynamically linking to user32.dll and other libs. And why wouldn’t you anyway? The system actually offers backwards compatibility for those dynamic libraries.
Given that you already have to have a dynamically linked executable, the difference between static linking your libraries vs. just shipping dlls alongside the executable is academic. It’s just another resource the program needs to run.
Common practice on linux does make this needlessly difficult - you have to fiddle with things like RPATH so that your libraries don’t try to load from system libraries with no backwards compatibility guarantee.
Given that you already have to have a dynamically linked executable, the difference between static linking your libraries vs. just shipping dlls alongside the executable is academic. It’s just another resource the program needs to run.
Common practice on linux does make this needlessly difficult - you have to fiddle with things like RPATH so that your libraries don’t try to load from system libraries with no backwards compatibility guarantee.
This should be easier now with Flatpak
This is not true. Vulkan is still the preferred option for game developers moving from OpenGL 3.3/4.0+.
Apple’s huge cash reserves are by far the least interesting advantage it can bring to bear in this area. There are two and a half more interesting advantages: their superstar translation layer developer team[1], their superstar silicon team[2], and the ability for these teams to work together[2.5].
1: Rosetta 2 was low-key a modern miracle: Apple made an x86-to-ARM translation layer that Just Works for 99% of software.
2: Apple Silicon was another modern miracle, although much more high-key: Apple stepped into chip design for laptops/desktops and produced a thoroughly competitive set of chips (that are even industry-leaders in some, though not all, important metrics).
2.5: One of the reasons Rosetta 2 worked so well was that M-chips were designed with built-in tricks to support it (https://twitter.com/ErrataRob/status/1331736203402547201).
Using these advantages to support gaming is the way to go, not trying to pay game developers to use Metal. Take your Rosetta dev team and task them with making a DirectX-to-Metal translation layer (you even have a ready-made name for it: the Ezana Stone is another trilingual stone like the Rosetta Stone, this time written in Classical Ethiopic, Sabaic, and Ancient Greek). Take your Apple Silicon team and task them with making a gaming-focused chip (this might be as simple as making an M-chip that has more like a 3:1ish ratio of GPU to CPU cores rather than the current 1:1ish ratio). Have these two teams work together to put features on the gaming chip that support the translation layer (explicit hardware support for a few of the trickiest DirectX calls or something). Maybe you can even punt all that fancy neural-network-based DLSS upscaling to the Neural Engine, who knows?
The M1 Ultra was essentially two M1 Maxes taped together and much was made of it being “beating” Nvidia’s 3090 (only if you starve the 3090 of power). But tape two M1 Ultras together, and it looks like you probably beat a 3090 in a fair fight too.
If Apple wanted to go that way, they could ship a hypothetical system that packs two GPU-core-heavy M3 Ultras taped together, executes a translation layer that runs DirectX/Vulkan alongside OpenGL/Metal, and shoves the pixels onto studio-grade 4K/5K/6K Retina displays. That would be the most powerful gaming PC in absolute as well as relative terms. Apple would go from “by far the worst gaming platform” to “by far the best gaming platform” overnight. I doubt Apple has any interest in this direction, but if they did, they could do so much better than throwing cash at game developers.
1: Rosetta 2 was low-key a modern miracle: Apple made an x86-to-ARM translation layer that Just Works for 99% of software.
2: Apple Silicon was another modern miracle, although much more high-key: Apple stepped into chip design for laptops/desktops and produced a thoroughly competitive set of chips (that are even industry-leaders in some, though not all, important metrics).
2.5: One of the reasons Rosetta 2 worked so well was that M-chips were designed with built-in tricks to support it (https://twitter.com/ErrataRob/status/1331736203402547201).
Using these advantages to support gaming is the way to go, not trying to pay game developers to use Metal. Take your Rosetta dev team and task them with making a DirectX-to-Metal translation layer (you even have a ready-made name for it: the Ezana Stone is another trilingual stone like the Rosetta Stone, this time written in Classical Ethiopic, Sabaic, and Ancient Greek). Take your Apple Silicon team and task them with making a gaming-focused chip (this might be as simple as making an M-chip that has more like a 3:1ish ratio of GPU to CPU cores rather than the current 1:1ish ratio). Have these two teams work together to put features on the gaming chip that support the translation layer (explicit hardware support for a few of the trickiest DirectX calls or something). Maybe you can even punt all that fancy neural-network-based DLSS upscaling to the Neural Engine, who knows?
The M1 Ultra was essentially two M1 Maxes taped together and much was made of it being “beating” Nvidia’s 3090 (only if you starve the 3090 of power). But tape two M1 Ultras together, and it looks like you probably beat a 3090 in a fair fight too.
If Apple wanted to go that way, they could ship a hypothetical system that packs two GPU-core-heavy M3 Ultras taped together, executes a translation layer that runs DirectX/Vulkan alongside OpenGL/Metal, and shoves the pixels onto studio-grade 4K/5K/6K Retina displays. That would be the most powerful gaming PC in absolute as well as relative terms. Apple would go from “by far the worst gaming platform” to “by far the best gaming platform” overnight. I doubt Apple has any interest in this direction, but if they did, they could do so much better than throwing cash at game developers.
[deleted]
I'm not sure that I agree with the direction the author wants Apple to take.
It would be really nice if Apple supported Vulkan. For sure. But Valve should be the one making Proton compatible with Macs. And directly paying off studios to make Mac versions of big games is never going to produce anything of lasting quality.
Nintendo has charted a pretty successful course with the Wii, Wii U and now Switch. Apple's got better hardware than that, it just needs to be used more creatively.