Imho it’s unlikely this is for natively running on a standalone headset. The overhead of translation alone would be just burning already limited compute budgets.
The other games on their list are too demanding for untethered play in the wattage one would have on a face mounted device. IMHO gorilla tag here is just a red herring.
IMHO this is just valve hedging the bet that ARM machines become more popular , and future steamdeck like devices might use ARM.
It would make sense that they test SteamVR running with proton and tethered to a headset rather than directly connected.
Imho, that’s the more straightforward explanation for this. The game is just a test bed for tethered play.
I think you're right that they wouldn't ship Gorilla Tag this way. For a game that big I'm sure they can work with the developer to ship a native version. But for internal testing of a headset it would make sense to use this version in advance of availability of a native port.
The games that will ship this way will probably mostly be non-VR games that would never get ported otherwise. So you can play your Steam library full of non-VR x86 Windows PC games on a giant virtual screen in VR.
I think you’re perhaps over indexing on the one game in the list. The other games in the list have no VR mode at all. So they could run standalone in a flat screen view, but with fairly poor performance.
Gorilla tag also has an ARM version already for Quest. So why would valve not just start from there? The Quest line of products use effectively the only SoC that Valve would have access to anyway for the XR space.
Imho desktop and tethered playing are far more likely targets. I think Deckard might show up someday but it’s become a vessel for everyone’s hopes and dreams.
> Imho it’s unlikely this is for natively running on a standalone headset. The overhead of translation alone would be just burning already limited compute budgets.
I wonder if with both Windows and Valve getting into ARM64, that will bring significant enough pressure on the market for ARM OEMs (and ARM itself) to start including a x86-transpilation mode similar to the one Apple has in their M-series of CPUs to increase the performance of Rosetta2.
I don't think this is about the hardware necessarily. They probably make more money from the Steam store and there are some notable ARM based platforms where you currently can't use Steam and where they are not able to sell games.
Macs would be a big juicy target, for example. If they can get emulation working well enough with proton on that, that's a huge market. Lots of people with disposable income on there that could be buying lots of games. And Apple is doing similar things as well so there might be some opportunity to tap into what they are doing.
As much as it sounds like it would make sense, I haven't seen any hints that they are developing Proton for macOS. That seems like it would be evident from open source changes, if it was happening.
I think Valve is reluctant to get any closer to Apple, or any large platform owner for that matter. They want to stay independent and own their own destiny. They even tried to get away from Microsoft with Steam Machines. It failed back then, but the Steam Deck is the continuation of that effort.
I don't think the Steam hardware survey is representative of the market size. Most people with Macs are accustomed to games that should run just fine on them never getting released, which means there often isn't any point to installing Steam on a Mac in the first place. Therefore they wouldn't be represented even though they are gamers, they spend money, and they have Macs.
I don't have a PC for personal use, but I do have a lot of game consoles, an M1 MacBook Pro, and an M2 Mac mini. There are lots of games like Pizza Tower that look fun to me, do not have a Mac version, but do have a Switch version. So I wind up spending money on Switch games that would've gone to Steam if the publisher had bothered with a macOS release.
While I do have Steam installed on my M1 and M2, I rarely launch it because I've only bought eight games off Steam in two years because of this dynamic, meaning I haven't even participated in the survey myself. My Steam account is over 20 years old and has a healthy library from when I was a PC gamer. I'd say my money's on the table, but my money's in Nintendo's wallet. But I'd really rather be buying macOS versions!
That's because Steam barely works on modern macs. After they killed 32 bit support, most of my games stopped working. Even at the best of times, only a fraction of the games worked on mac. And now with essentially all macs running arm processors, the only macs left running steam are from last decade. So all these surveys prove is that a market that they barely supported wasn't very large.
And you forget that one of the largest gaming platforms out there is the iphone. Which also doesn't show up in the steam hardware survey because steam doesn't run on it. The iphone market proves that there is a gaming market for typical Apple users. A very big market even. People that spend a lot of money on their phone also seem to like spending a lot of money in the app store. And mostly on games. Apple rakes in billions via the app store.
If Steam were to get Mac support to the same level it is on Linux, most of the games would start working and there are a shitload of Apple PCs and laptops out there that would be able to run that.
People who play phone games wont convert to playing desktop games. My mother-in-law has spent untold amounts of money on candy crush, on her iPhone, has a 10 year old windows desktop and talks shit about her daughter playing videogames games from time to time. If you've got some data saying the correlation is very high, alright. But I don't believe it is.
Also, where is Apple's responsibility in all this? Steam this, Steam that. Apple changes arch, doesn't support vulkan and removes 32-bit support and then it's Steam's job to chase Apple? EA, Ubisoft, CD Project, Epic and Actiblizzard all also have store fronts and don't care to support mac. They could all be asleep behind the wheel, true. Or it could be that Apple makes it too annoying to support a platform that would barely yield any sales.
If Steam, a tiny company in comparison, and Codeweavers, also an tiny company in comparison, can get games to run on Proton+Linux then I'm pretty sure that Apple, with a little help from their trillion dollars, can manage something. But they also don't care cause Steam wont give 30%, which is Steam's fault of course.
It seems pretty clear to me that the main target of this is ARM Chromebooks, at least for now. As these are the only products currently shipping in any relevant numbers where this makes sense.
Proton didn’t exist in a vacuum though. It existed for Valves previously failed vision of the Steam Machine. Those were actual product lines that existed (briefly) to go along with Proton.
The Steam Deck was Valve finally getting sick of nobody doing what they wanted, and technology getting to where they could do something more interesting than just another desktop.
I could have worded it better but that’s my point. It was sort of their third attempt to make Linux gaming a thing (steamOS 2 + proton) before they finally came up with a compelling product of their own.
MacBooks certainly have volume, but Wine/Proton on macOS is facing serious technical challenges which they only started to address (Wine 9.0 with WoW64 was only released in January). Chromebooks are much lower hanging fruit.
Valve contracts ~a dozen developers from Codeweavers (same folks that develop Codeweavers and the downstream open source project WINE) for Proton and they've had 32 bit Windows executables working on macOS (despite the native limitations) for years.
This does not seem clear to me. My initial guess would be ARM based Steam Deck (or similar handhelds).
But generally, what is clear to me is that ARM is slowly becoming a lot more viable for general purpose computing. Apple's completely made the shift, and Microsoft seems to be persuing it for laptops at least finally. ARM seems like a great match for handhelds, if it wasn't for the compat issues.
They are fully dependent on Windows Games developed for Windows.
They are only working really hard not to pay for Windows OS licences.
The day they actually support native Linux games, instead of doing Windows API translation is when I believe they are actually serious about Linux games, and not saving OS licenses.
Valve got a scare with Windows 8 that they could be pushed off the platform.[0] It became clear to them that they were just guests in a house owned by Microsoft. That was in 2012, the first Steam Machine (running Linux) came out 3 years later and they've been working at it ever since.
It's not about saving the cost of a license, it's about guaranteeing their own survival.
As for "supporting native games," I take that to mean "sufficiently incentivize game devs to port their games to Linux." How would that work, or did you have something else in mind?
The cost of developing and maintaining Proton, Linux driver improvements, and their own Arch-based OS has probably exceeded the amount they saved by not shipping Windows on Steam Deck.
But what they got in return is a much more usable gaming operating system that doesn't constantly pester you about switching to Edge, using Copilot or draining all your battery for an update while you game
What they got in return is freedom from Microsoft's arbitrary OEM hardware requirements like having a front camera for Windows Hello, or having a TPM
What they got in return ultimately is leverage. As sibling comment mentioned, they were in fear that they could be kicked off of Windows by Microsoft. Now, Microsoft is the one in fear that if they ever kick Steam off, gamers now have a perfectly functioning alternative operating system to switch to.
> The cost of developing and maintaining Proton, Linux driver improvements, and their own Arch-based OS has probably exceeded the amount they saved by not shipping Windows on Steam Deck.
So far. Depending on Microsoft's continued benevolence is probably not a great business strategy when you're as big as Valve. You don't want to be caught with your pants down when MS wants their pound of flesh from your $8 billion company.
Assuming Windows games, developed for Windows, keep runing in Proton and Microsoft doesn't come up with specific Windows API requirements not possible in Proton, like plugging into Pluton that is now a requirement for upcoming PCs.
Seems this sentiment is coming up in every recent Proton related thread. Despite all the counterarguments offered each time.
The simple reality is that there are decades worth of Windows games that will never have a Linux version. Because of the studios being gone. Because of the source code being lost. Because of the licensing issues for dependencies, assets, music. If not for the Valve efforts people would always need a copy of Windows to play a good chunk of their libraries. At which point why bother with Linux? But with Proton the calculus changes. Most of those Windows-only games are now fully playable on Linux. Many people no longer need Windows and that's a huge win for desktop Linux adoption.
By this logic Apple should not have developed x86 translation for its latest Macs because it showed they are not serious about the platform and disincentivized devs from providing native Arm ports. Except we know that's not what happened.
I get the reasoning from your other replies. If Microsoft extends Win32 with some new API that cannot be reimplemented in Proton then Valve is screwed. So you want them to require a native Linux version from every game published on Steam.
However I really do not think Valve is in a position to dictate such terms. They have multiple competitors both in distribution and console space. Big names are already publishing on their own stores. Small indies can move to itch.io. Everyone else can switch to Epic. Steam Deck is already underpowered compared to recent Windows based handhelds. If it stops supporting Windows games via Proton then it is as good as dead.
I understand your idealism. But a step like this would kill gaming on Linux much quicker than anything Microsoft could do. Because Valve is the only big distributor even remotely interested in it. In contrast Epic is absolutely hostile to Linux. And they're the ones to gain the most users in case Steam fails.
> They are fully dependent on Windows Games developed for Windows.
Sure, but they don't want to be dependent on Windows itself. If they can run all those Windows games on another OS, that's a win. Proton is pretty amazing, even if it's not 100%.
And if game devs for some cataclysmic reason abandon Windows, they'll figure that out too.
Valve has little control on what other companies target. Their previous push for native gaming produced very little results: Valve ported all their titles, a few minor publishers released native titles and some porting companies ported some AAA titles, but it was only a drop.
Proton has caused a significant increase in Linux playable games. The side effect is that it effectively killed porting companies.
edit: also all porting companies were effectively using their proprietary equivalent of proton (although often inferior) .
TBH running through a Win32/DX API shim isn't much different than running through SDL, yet Linux games using the SDL are considered "native" but Win32 games running through Proton are not?
(the Win32 and DX APIs are also much more straightforward to use than wrestling directly with X11, Wayland, Vulkan and the Linux audio API flavour of the month)
Yet Proton game work better and with greater performance than most native ports, which are created once by third-party teams (i.e. Feral), never properly tested or rarely updated.
Soon Wine will have Wayland support and 99% of those ports that no one is willing to update will remain stuck on X11.
Good luck running a >20 year old native Linux game on a modern Linux distro without recompiling.
A Proton like layer would also totally make sense on Windows, assuming that support for older Windows APIs is better in Proton than on Windows itself (which isn't a far fetched assumption).
All of this already exists on Windows. They're already drop in DLL replacements that smooth out compatibility with older versions of graphics APIs among other APIs. And old support for old games actually isn't that bad on Windows 11. No one has heard of this game, but I could just boot up the old Japanese PC game Abyss Boat and it kind of just works. If I use a DLL replacement or something like dxwnd or dgvoodoo2 it's even better.
With a Direct Draw replacement like the one from WineD3D your game/software is not better; the game literally stop beings a Power Point presentation and gets fully playable.
But, by default, you'll get a slideshow in a game that would run screamly fast under a Pentium 3 and a Windows release from its era.
Not Valve's fault that user-space Linux is run by a bunch of unpaid headless chicken with no overarching vision, sense of momentum and direction, while Win32 is a rock-stable API that games are already using.
Until there is a Linus figure that coordinates the userspace and organises a common platform API with long term support for closed-source software, Proton is the only pragmatic choice.
Valve want to get off Windows ASAP, not necessarily waste money chasing windmills driven by silly ideology that native is better.
I love Linux, I have used it for 25 years, and even I accept that native games run WORSE than their Proton counterpart.
> unpaid headless chicken with no overarching vision
systemd, GNOME, mesa etc all have developers who are being paid by companies for their work (Red Hat, Microsoft, Canonical, SUSE etc). That said, you're not wrong on the 'no overarching vision' part, see Wayland.
> Linus figure that coordinates the userspace and organises a common platform API
Flatpak with the freedesktop runtimes are just this, that said some companies (e.g. Canonical) are trying to sabotage these efforts and Ubuntu not shipping with Flatpak is the biggest hurdle.
Flatpak is not a common userspace library, just a set of sandboxed functions (i.e. portals).
What we need is something that groups Qt/GTK, pipewire, part of systemd, part of flatpak, part of Wayland into a single library, a bit like Win32 is. And the guarantee that it remains stable even for closed source projects. For example Linux is free to change its internals and requires everything to be open, so drivers can be adapted whenever the APIs change. This is not good enough for a desktop API.
Maybe because there is a large backlog of old games that will never be ported to Linux? Have you considered that game developers and not valve are responsible for providing a Linux port of their game and so far have managed to do a worse job than a DirectX implementation for Linux?
The collective time spent on developing proton is probably less than a dozen high profile Linux ports.
The latest commit to proton 9.0 is three weeks ago. The latest commit to an experimental branch is 3 days ago and it is just an update of a wine version and no other commits. A lot of proton commits just update a version here and there.
The focus is certainly not on proton. It is simply very cheap to work on it, because it is highly effective. The steam deck probably cost them more software and hardware developer hours than proton.
It's unfortunate but win32 has stable ABI. Such thing can't be really said about glibc and dynamic linking. Many old linux game binaries simply don't work or need tinkering to get them work.
the majority of users have no idea what OS is actually running on their steamdeck and don't want to worry about it.
Proton makes it possible to maintain a large library of older games on the platform.
Like any Steam user since Half-life 2, I must have accumulated over a hundred games in my library.
I think Valve knows better than we do what users want.
So? How is a game fully running on Proton not a native game?
Wine's version of the Windows API isn't conceptually different from any other cross-platform technology here. You could make a similar purity argument against using the Unity engine since most of its games end up being primarily on Windows too.
I used to port games to linux (from windows). There is just a huge amount of work porting each game, even if the tech used is somewhat cross platform to begin with. Game devs in general (and the people funding them) are just not interested in doing that work; they have more than enough work just getting the game to ship on their primary target platforms. And at least back in my day, native linux ports sold extremely poorly.
Aside from that there is a huge catalog of games using DX 9-12 and other windows-specific APIs that is just never going to get ported and that even valve would never be able to get source code for. Most of that source code is essentially unobtainable and in some cases has passed through multiple IP holders such that whoever owns it now (most likely a big company like EA or microsoft) doesn't even know what they have, let alone how to build it or even where the archives are.
An additional fact is that nowadays many older games have communities that have modded them unofficially by resorting to DLL injection and other hacks - these hacks can work under proton with the windows executable, but would fail on with a native linux binary. An example is oblivion script extender and its many cousins for that family of bethesda games. Many of the more advanced mods for those games require the capabilities of those low level hacks.
Even as someone who tries to predominantly buy games with a native Linux version, it's not something I really want. If I have some desire to play a game from 2008 again, I'm glad Steam will still offer me the Windows version.
Why, though? What difference does it really make besides significantly reducing the cost of “porting” games?
If anything, due to Wine, Proton etc. “Windows API” is almost a pseudo opensource way of developing cross-platform content. There are significant downsides but on the bright-side it’s extremely stable considering to most stuff on Linux.
Could you help me understand why that is a pity? Seems like Valve’s adapter pattern is a great development tool to get Linux games without dev studios spending excessive dev time/money on it.
I can think of one thing, which might not be what parent meant: the incentive of developing for linux, or paying porters like icculus and flibitijibibo to build a native version goes out the window, and the need for their kind of craft goes away.
Frankly when the SteamDeck launched I hoped that game developers will start treating it as they do any other console and build specifically for it, but sadly Proton prevented that from happening.
I don't think Proton has prevented anything. In fact, without it, and the back catalog of Windows games it makes available on SteamDeck, I doubt the handheld would have been as popular. SteamDeck was successful enough to get a re-release in the form of the OLED model, which is a big success for a Linux handheld. The longer Valve remains committed to the platform, and the more devices they get into the hands of consumers, the more attractive native Linux games will look to developers.
The people I mentioned in my comment clearly disagree with you, and frankly they have more of an incentive to be well informed about the situation. See the twitter link I posted to your comment's sibling for Ethan Lee's impressions from three years ago.
Also, I never argued against Proton having been a boon for Linux gamers, but I tried to present an opposing point of view that usually does not get taken into account.
Like I mentioned in the other comment my impression over the past 3-4 years is that the number of native linux ports has dwindled to nothing and that is most likely due to Proton making them unnecessary.
In my experience, the Linux ports never got any attention from the devs either way. They'll usually have worse performance, not be on the current patch and in at least one case, Binding of Isaac Rebirth, not be compatible with the DLC as the DLC works in some hacky way on the windows version.
Without Proton the steam deck would not be popular enough to warrant any Linux ports either way. So Linux ports would be doomed regardless.
The real travesty is steam, with the recent introduction of WoW64 in Wine, is now the only software that requires me to run 32bit binaries on my desktop. Real annoying.
In your opinion, why is the "trust in Proton" not considered "developing for Linux"?
Is your argument specifically about the game developer's mental model for Linux's priority, or something core about the Proton abstraction layer?
All software runs on some abstraction. So specifically, if the game developer prioritized a Linux port by explicitly testing Proton, would that be enough for you to consider the game "developed for Linux"?
The consumer artifact for a game developed for a platform is a binary that can run natively on that platform.
Regarding games, that is a binary that targets the ubuntu based Steam Linux Runtime. That's what I meant when I said that devs should be able to target it as a regular console SDK.
I think it's a longer term play.
Step 1) Establish a large enough non-windows userbase with great compatibility tools
Step 2) Studios and especially game engine developers notice linux install base
Step 3) Some tangible benefit to running natively, if only stability, pops up and the userbase is now large enough to care about it
Step 4) Engines, and then games get better native support
> @flibitijibibo (Jul 16, 2021): Don't look at me - I'm just trying to figure out how much time I have left, either way it's pretty clearly finite
Also some anecdata from someone that pretty much bought all native linux releases from Steam since the linux version was released: in the past 2-3 years there were barely any new ones, outside of Valve's own titles maybe.
> The day they actually support native Linux games
Not "the day a majority of their library is linux native"
As others mentioned valve has been developing their games as linux native already, what do you expect them to do? Force every single developer to support all the platforms possible? Delete all the games not linux native?
> They are only working really hard not to pay for Windows OS licences.
In what way are they supposed to be paying for Windows licenses? What do you even mean by that? You aren’t required to give 30% to MS to ships Windows apps (nor macOS)
If anything they are trying to build a moat, good-luck playing Xbox games on your Steam Deck if you don’t go out of your way to install Windows. Making them affectively a monopoly for now.
Valve doesn't ship Windows on the SD, hence doesn't need to pay a license for it.
Nothing prevents MS for porting their launcher to SD and running the games on SD.
> The day they actually support native Linux games
They do, and have for a long time now, for nearly all of their own releases. There's not much more they can do than that; they don't control what platforms other companies want to port to.
Sorry, but are you saying you believe Valve is responsible for the development of every game on their store? In case you're just genuinely unaware, games are developed by a variety of people and studios completely separately from Valve.
Yes, and they opt to sell video games from most anyone who opts in to their store. Fundamentally, that is their business. What you're asking of them is beyond unreasonable because it fundamentally goes against what they do and it would immediately kill their business in its entirety if they stopped selling 99% of games. Then we wouldn't even get Proton and Linux would be truly dead for gaming.
What you're asking of them is akin to complaining that Apple sells tech instead of dishwashers when fundamentally that's so far from what they do that it's absurd, not to mention that if they suddenly stopped selling all tech their business would obviously die. I feel a bit foolish for even entertaining this because what you propose is so obviously outlandish to me that I'm about 85% sure you're just messing around to get a rise out of people.
While it would be great if Valve did what they do on SteamOS and just manage it themselves, it’s a very minor burden to use the existing solutions to do the same.
You know, every 6 months or so I get a sudden hankering to play Portal or something and start down this rabbit hole. Based on your prompt, I had another look today.
So I went and downloaded this "whisky" thing. From their website: "Experience the latest titles effortlessly with Whisky!". OK. Installed.
I open it and I see a window with "bottle configuration" (wtf is a bottle?), an "open c: drive" button (???), "SteamCMD" whatever that is, "winetricks" (??) and a "run.." button which opens a file from finder (??). I have absolutely no idea what any of this is or how to proceed.
Confronted with this and the prospect of hours of research and messing around I decide I don't need to play anything all that much really.
This is one of the things that Valve does very well. I even end up installing Steam on PCs that I run non-steam software on, because Proton is just that easy. I add the shortcut to Steam, choose my proton runtime (if that), click play, and the client does the rest. WHY ON EARTH is it more complicated with other launchers? No idea, and I bet that they have exactly 0 UX people among their midst. And even the programmer excuse doesn't work, that programmers are bad at this sort of thing (think "programmer art"); because programming also adopted convention over configuration in the early 2000s, 20 years ago now.
Sorry for the rant, I also hate bad UX. It makes me feel stupid for no good reason.
If Apple cared about gamers, they wouldn't have blocked proper Vulkan support. They simply don't care. A major reason to stay away from Apple if you are a gamer.
It’s not the end of the world to develop for macOS and iOS. These platforms are just idiosyncratic and don’t have many serious gamers.
Neither smartphones nor Macs have been powerful or ergonomic enough to play current-generation games for decades. So the user base is almost entirely people who don’t play games.
For a developer, the juice is not worth the squeeze (and by far!). The platforms are challenging to port for and all that effort seems to result in near-zero sales. All ports seem to be almost guaranteed commercial failures.
My key point is that perhaps the platforms are now mature enough to develop for and Metal is alright. But they have not been for a long time and it’s a really bad market to target for a game developer.
Unless Apple funds your games like some other platforms do, it’s better to just blow the porting budget on something that’s at least fun. I haven’t heard of anyone’s game funded by Apple, but maybe it happens? These deals are rarely made public.
I feel like Apple has the opposite attitude of Microsoft's towards 3p apps in general, not just games. Mac updates will constantly break apps at least minor ways, sometimes major (like 32-bit removal).
Microsoft's reluctance to break things comes from commercial entities being a big source of licenses both for desktops and backend servers. If some poorly maintained mission-critical app doesn't run on Windows 11 because it hasn't had a recompile in a decade, that means a Global 2000 company isn't able to update their workforce.
Apple considers it a partnership with developers, even if that partnership in reality is rather one-sided. If you stop maintaining your software you aren't holding up your end of the partnership. For instance, ignoring six years worth of deprecation warnings about 32 bit software going away, or seven years (and running) warnings about OpenGL support, or still shipping only Intel binaries four years after M1 launched.
But this is not how games are supported, except for subscription games like MMOs or crazy edge case labors-of-love like Starcraft. Fixes are going to be driven by a chance at new revenue, like updating to support HiDPI displays properly as part of a major DLC update. Afterthought ports (especially third party ones) like a Windows title to the Mac are even more limited in terms of ongoing support - and are often like-for-like limits to 32 bit intel only because the original developers never tried to write portable code.
Gamers don't need to worry about "how games are supported" as along as they work. You can run many old games in Wine even though original developers stopped supporting them decades ago. Putting hurdles in the way of that is the opposite of supporting though and that's where Apple is causing a problem. This applies to refusal to support Vulkan as well as stuff like gutting 32-bit and OpenGL.
Sometimes it works, but the performance is worse. Like back when I had an Intel Mac, csgo was fine on Boot Camp but had noticeable input lag in macOS, and iirc under Wine it had less input lag but stuttered more. It'd be unplayable if I cared about winning, but I didn't care.
It seems that way. For a long time, what Apple didn’t use or specifically wanted on their platforms didn’t get a lot of thought.
Most game engines haven’t figured out resolutions and DPI scaling for windowed full-screen games in macOS and for a long time, it didn’t seem like there were many guidelines (bare minimum) or support from Apple.
Third party is just not as important as first party to Apple, I think. Which is ironic for a company that has succeeded tremendously off the backs of 3p devs on iOS. But perhaps it’s a different strategy for each product line. And it’s probably been a good strategy to focus on certain areas and not others for them.
It’s not all bad, you can definitely port games to Macs with some effort. If it was only worth it, it would be fantastic.
Though I’ll say, I think there is a niche for casual games with excellent graphics on Macs now. This niche could be worth a lot of money by the end of the decade, just like casual mobile games.
> Unless Apple funds your games like some other platforms do, it’s better to just blow the porting budget on something that’s at least fun. I haven’t heard of anyone’s game funded by Apple, but maybe it happens? These deals are rarely made public.
Maybe I'm wrong but I thought/assumed that Valve's work to get Steam and their GoldSource and Source game engines working on Mac was with some sort of support from Apple - I know they did Linux support around the same time but the extra work to get everything working on a Mac wouldn't have been trivial.
That’s the only avenue I see where porting a AAA-style game makes sense for a Mac financially.
Left 4 Dead 1 and 2, and several Counter-Strike games were also ported, but CS:GO was later discontinued for Macs. These were done without Apple’s money as I understand. And the discontinuation seems related to support costs on a platform that doesn’t have many gamers.
Yeah I think Valve ported their whole catalogue of games, but I'm not sure what exactly happened with the discontinuation - I thought they quietly dropped the Mac support tag from all of their games two or three months ago, probably because Intel Macs haven't been sold in a few years now? Presumably they didn't want to sink more money into Mac support (they had 11 years worth of Mac usage statistics to back up their decision).
> I'm not sure what exactly happened with the discontinuation
They didn't update their old games with 64-bit support, and in February they dropped support for the last macOS with 32-bit support (Mojave) because 98% of Mac Steam users had updated to newer OS releases. Mojave (released in 2018) hasn't received security updates in years, and doesn't support the latest CEF, which the Steam client is based on. https://www.tomshardware.com/software/macos/32-bit-mac-holdo...
I don’t think Intel v. ARM matters too much once the engine HALs support it natively, or through Rosetta 2. This to me doesn’t seem too bad.
The OS APIs and building an ergonomic experience is the challenging part. Supporting APIs is harder than it may seem. That’s graphics, sound, task scheduling and multi threading, I/O for both files and devices, and many more. All these things have different approaches on different OSes, as well as different limits of what is allowed and what is not. Different best practices and degrees of documentation, too. This all then needs to make for a good player experience and meet gamer expectations. It’s a Herculean task.
It is even harder, because many graphics APIs, for example, support different features. So either your artists must accommodate and create several versions of skeletal meshes, visual effects, and similar; or your engineers must develop new graphics technologies to compensate automatically. And if that didn’t seem hard enough, try recruiting from a pool of game graphics programmers for macOS without a hot six figures a year burning a hole in your pocket. Now consider this for other APIs, though they are often more standard and less challenging.
I could be wrong, but many corners are cut for platforms that don’t have that many players — you just can’t justify the costs it would take to do an excellent port. And that creates pretty deep and difficult to patch issues. The same is seen on games ported to Linux.
While this seems counterintuitive Mac makes it very convoluted to release on their platform. To the point that the low sales really don't justify. Here's a video from a game dev driving this home
This is what I meant, in part, by saying how idiosyncratic the platform is. There are many more ways it is so.
I am very happy someone put the sales figures out there in the public. Not everyone can afford to if they must keep a professional relationship with Apple.
<100 sales for Mac like this guy claims are realistic numbers.
> Neither smartphones nor Macs have been powerful or ergonomic enough to play current-generation games for decades. So the user base is almost entirely people who don’t play games.
Current Macs and iOS devices are powerful enough. There's a handful of developers shipping full current-gen games to both platforms.
> It’s not the end of the world to develop for macOS and iOS. These platforms are just idiosyncratic and don’t have many serious gamers.
That could change if Apple and Valve would team up and make proton-like stuff happen (GamePortingToolkit is a first, but half-assed step). I own a MacMini M2 base model (retailed at 630€ new) for work and was surprised how well games last-gen games run on it (either Rosetta2 or GPTK+wine). With better software compatibility I could see the upcoming M4 mac mini as a serious game console contender. Smaller form factor and more silent than any console, add an Xbox/DualSense controller in the living room and you are good to go.
Point is that Apple is deliberately blocking Vulkan support. Which prevents things like Wine / Proton from offering decent performance for games there (MoltenVK is not really adequate for that).
Being it's Apple, not some kind of poor entity who can claim lack of resources, I'd say they very much on purpose disregard gaming as a use case and therefore it's a strong reason to stay away from Apple to begin with if you do care about it as a user (gamer).
> I'd say they very much on purpose disregard gaming as a use case
Considering they made Metal, and the Game Porting Toolkit, and Game Center, and specific tabs for games in the App Stores, and Apple Arcade, and added native support for game controllers, and have dedicated sections of their keynotes to gaming, it is pretty clear they don’t disregard gaming as a use case. Tim Cook’s Apple is bad in a lot of ways, but it isn’t that stupid to ignore that lucrative of a market which fell on their lap.
What you mean is they’re not embracing gaming the way you want. Which is fine to complain about, I also would prefer a different approach, but saying they’re purposely disregarding gaming does not align with reality.
> What you mean is they’re not embracing gaming the way you want
Yes. And I consider it disregarding when it comes to the needs of gamers (or users in general really). Apple's approach is always shoving in their users' faces "that's the way to do it". As I said, it's a major reason to completely stay away from them.
Many games that work in Wine work just fine in GamePortingToolKit (which is just an Apple-written patch on top of CrossOver which is just more patches on top of Wine)
Unlike Linux, Windows and etc. I don't think even GPU makers can provide their own implementation of Vulkan there - only Apple can do that. And they refuse. So it can be considered a deliberate blocking.
I personally believe, considering their track record, it’s more likely they simply don’t care about it.
More experienced macOS and iOS developers will probably be able to confirm that Apple basically only invests efforts in what Apple wants, whatever that is, and nothing else.
Silly argument, Vulkan also isn't available on Xbox or Playstation, yet dedicated game console platforms clearly care a lot about gaming.
There's also only a handful of Vulkan games, supporting D3D11 and D3D12 on macOS would make a lot more sense. But in reality, porting to a different 3D API isn't what makes or breaks a game port.
So if Apple would provide a similar D3D shim on macOS, all D3D games would suddenly become "Metal games"?
If Apple would implement Vulkan support on macOS it would be a layer on top of Metal (same as their GL implementation or MoltenVk). Running through two translation layers (D3D => Vk => Metal) doesn't make a lot of sense.
That would either mean that Apple needs to maintain two separate types of display drivers or create a new abstract driver interface which sits between Metal+Vulkan and the underlying hardware. That's just adding busywork with only downsides, both technical and organisational. Vulkan just isn't that important outside of Linux and Android, especially when most games are built on top of a crossplatform engine anyway.
I didn't even know there was Proton for macOS, but it looks like Valve ended that before the AS chips, so I don't think it had to do with the CPU arch.
I think, especially considering the news of Qualcomm talking with Intel about acquisition, or just Intel's general problems; we are in the last decade of x86.
Even calling Intel x86 a loss overnight AMD is doing more than fine enough, server and consumer, for x86 to stay with a competitive presence into the 2030s even taking a dim view of the architectures future.
Even Intel isn’t doing that bad. Their revenue is still 2x or so higher than AMDs and they are still ahead in the consumer market. Their next gen mobile chips are allegedly already more power efficient than Qualcomm’s meaning that their only remaining advantage might be lower price.
After buying Intel, Qualcomm could sink x86 by simply not renewing the cross-licensing agreement with AMD.
With Intel's patents on emulating x86 on other CPU architectures, Qualcomm could then ensure that going forward, the only economically viable way of running x86 code is on Snapdragon CPUs.
You would need the FTC to intervene to stop the acquisition. And currently there is a massive lobbying push by US technology companies to replace Lina Khan with someone who is more merger friendly.
China is busy replacing imported CPUs with domestically produced ones on a massive scale. Qualcomm's China business is at risk of collapse anyway. I don't think the Chinese will be interested nor able to buy Intel and AMD x86 chips for much longer either. My guess is that Qualcomm can placate them by promising to leave Zhaoxin alone (legally binding of course).
UK CMA folded extremely quickly after FTC lost their lawsuit. Microsoft had already communicated that they would withdraw Activision Blizzard products from the UK in case the deal were continued to be blocked.
The EU is a bit of a question mark, but blocking the FTC approved merger of two US companies could be seen as too costly politically.
Qualcomm would certainly not either, x86-64 is what they want to emulate with ARM... otherwise you're saying their only interest in purchasing Intel is to completely shut its main business down to reduce competition by producing neither x86 chips nor emulating them... which, apart from being extremely unlikely, would trigger even the most laid back of regulatory environments. Doubly so after already receiving over a billion in antitrust fines in 2009 for simply being "unfair" about the agreement, not even outright removing it.
Not to mention the cross-licensing deal between Intel and AMD also includes x86 patents from both sides anyways (your original article doesn't reference this as it's about Intel and Microsoft, not Intel and AMD).
In the scenario that I am envisioning, Qualcomm will be indifferent to Intel products, the only focus being to extract the maximum money out of their purchase. Oracle did the same, and nearly all Sun products are now dead or a shadow of their former selves. Plus Oracle narrowly missed the Jackpot in Oracle v. Google.
> Doubly so after already receiving over a billion in antitrust fines in 2009 for simply being "unfair" about the agreement, not even outright removing it.
Intel continued their unfair business practices, particularly in their compiler. If you wonder why Intel CPUs didn't move up from declaring CPUID Family 6 until now, that is why. More recently there was the MKL scandal. No antitrust authority was interested in either.
> Not to mention the cross-licensing deal between Intel and AMD also includes x86 patents from both sides anyways
The AMD-Intel cross-licensing agreement will need to be renewed when Qualcomm buys Intel, because it has a termination clause in case of ownership change. The companies can continue to sell existing products, but new products would need a new patent deal.
But Qualcomm won't be interested if they can just sell their Snapdragon CPUs to former x86 customers, who have no other choice because of Intel's patents on emulating the newer x86 instructions.
Taking all of your assumptions together as givens:
- Intel's unacted claims around patents 7 years ago were valid in the first place.
- No major government acts against the action because of simultaneous individual tentative politics in each and every single one. Including the EU, which has indeed blocked deals between 2 US companies even after the FTC has approved the merger (e.g. GE+Honeywell).
- Qualcomm concludes the best way to squeeze the most money out of Intel is to shitcan x86 completely by cancelling the cross-licensing deal (despite INTC having higher revenues than Qualcomm and selling competitive CPUs in markets it doesn't even target at all).
- The result of shitcanning x86 by cancelling the cross-licensing deal is people go exclusively to ARM
It's still not clear why Qualcomm would have free reign on the x86 PC market it just ate the cost of destroying. MediaTek, Samsung, and Rockchip already make consumer ARM laptops - the first two often beating Qualcomm in performance anyways. Apple also has their own walled garden offerings in the consumer ARM device space. Qualcomm's biggest advantage in the PC space was their exclusivity agreement with Microsoft for Windows on ARM but that is already dying at the end of the year. So say all the above wasn't a concern, Qualcomm really did dump billions into Intel just to stop making their processors and it was allowed, how is Qualcomm going to get their money back at all let alone better than squeezing Intel normally without first killing its main source of revenue?
In the scenario that I describe, Qualcomm is disinterested in x86, it just wants maximum profit off the purchase. Very much like Oracle basically shitcanned all of Sun Microsystems' products and squeezed Sun customers hard.
Keep in mind that the outlook for Intel products is not that rosy both short- and mid-term. They will certainly not go back to commanding historic margins in the datacenter. Also they lost trust from both institutional and private customers in how they handled the Raptor Lake voltage problem. Whether these customers come back anytime soon is doubtful.
Also on the manufacturing side, Intel foundries are bleeding money, 20A is cancelled, and 18A is yet unproven. So making back the purchase price off the usual business would likely take a looong time.
Yes, it is possible that Intel's patents on their instruction sets and on emulating them are all invalid, but Qualcomm is the kind of litigious company that seems determined to find out. (Their patents are also the presumed reason why Qualcomm is basically the last major vendor to offer AV1 hardware decode in their processors)
It is also possible that the EU blocks the merger but in the current political climate, the EU has become something of a vassal of the US. same politicians who pressure for replacement of Lina Khan will also exert pressure on the EU.
> MediaTek, Samsung, and Rockchip already make consumer ARM laptops
Yes, but them not being able to economically emulate newer x86 instructions would be a major sales point for Qualcomm Snapdragon. They could basically capture all the customers which are dependent on x86 software.
> Qualcomm's biggest advantage in the PC space was their exclusivity agreement with Microsoft for Windows on ARM but that is already dying at the end of the year
I think you got that backwards. The exclusivity was the precondition for Qualcomm to become interested in the Windows on ARM. Otherwise they would not even have bothered to release products specifically for that tiny market. It is Microsoft who desperately needs to become independent from x86.
> Qualcomm really did dump billions into Intel just to stop making their processors and it was allowed, how is Qualcomm going to get their money back at all let alone better than squeezing Intel normally without first killing its main source of revenue?
Qualcomm will continue to sell x86 processors, just like Oracle continued to sell SPARC processors, for a while. But they would wind down the x86 business and try to capture locked-in x86 customers onto (high-margin) Snapdragons, and they have all the ingredients to make this happen. And they will have the patents both on the design and manufacturing side to at least cause serious trouble for competitors.
Since you repeated the same thing you said the previous time and immediately followed with points that still ignored how Qualcomm itself also wouldn't be able to emulate or sell x86 without the cross-licensing agreement (Intel needs AMD's patents to utilize much of modern x86 as much as AMD needs Intel's) I have to ask as a sanity check - am I talking to a human or a bot?
> Qualcomm itself also wouldn't be able to emulate or sell x86 without the cross-licensing agreement
As far as I am aware, the AMD-Intel cross licensing agreement allows to continue to sell existing products after termination, just not bring new ones to market. And Qualcomm would of course continue to sell Intel's products, just possibly not develop new ones.
If Qualcomm buys Intel, they will have the patents that are needed to emulate modern x86 instructions like AVX. Or are you aware of any patents that AMD owns or claims to own on emulating x86?
> I have to ask as a sanity check - am I talking to a human or a bot?
Human. I guess I have to thank you for not writing "ignore previous instructions" or similar.
Yes, you could emulate an x86-64 CPU with SSE2 (aka x86-64-v1), but that is no longer sufficient for lots of modern x86 code. Windows 11 wants SSE4.2 at least or else it won't even boot.
As Arstechnica wrote, Intel specifically warned that they hold patents on emulating the more recent instruction sets.
Since we're all just reading tea leaves, my guess is Valve is looking at a higher performance, lighter, ARM-based SteamDeck 2. They have time to develop it, so maybe they're targeting the next generation of Snapdragon X.
Not possible to fully AOT for all applications because you don't know which ones do JIT compilation to generate x86 code at runtime. Many games make use of LuaJIT, for example.
Valve does a lot of hacks in Proton to make particular games run better. I think swapping a static library might also be possible if you target a particular game.
Very likely yes (Rosetta for the Mac already does this), but the big issue is that a ton of Unity games use JIT compiled Mono, and that would require dynamic recompilation, which as we've seen with Rosetta, would lead to terrible realtime performance
Just to clarify: yes, it requires the source AND re-building it. But, with a simple switch, you make your x86 code JITtable on ARM64. That's why it runs at native ARM64 speeds. Sometimes, you can't build natively for ARM64 due to some dependency, and this allows portions of your code to be faster at least.
Otherwise, if you have the source AND budget to rebuild, just build it natively for ARM64 of course :)
ARM64EC doesn't really make your code JITable. It is ARM64 code with thunks to enable transitions to x64 code. That's why it runs at near native speeds; not because of the JIT. The x64 portions of the binary do get JITed though, but the ARM64EC portions are usually much faster.
All x64 code gets JITed but that's regardless of whether ARM64EC is used or not; ARM64EC allows ARM64 applications to interface with x64 binaries.
Okay, I had assumed JIT for x64 wasn't possible (yet) and ARM64EC enabled that partially. So, ARM64EC images are actually native ARM code that can interact with emulated (+JITted) components. For some reason, I thought native ARM64 binaries already had this capability, but they don't. Thanks, that's actually a better state of affairs in Windows on ARM land.
Yes, that's correct! Unfortunately ARM64 can't fully interface with x64 code (e.g. you can't translate an ARM64 CONTEXT to an x64 one directly due to differing numbers of registers), so the backwards compatibility is restricted to ARM64EC only.
Interesting - Source 2 has mobile support (not sure if it's native but I assume it is, so maybe it already has ARM support) and Source technically has mobile support but that was done by nvidia Lightspeed Studios I think. Maybe Valve has been quietly adding ARM support to their engines behind the scenes.
> There are also some other tags such as "proton_experimental" and "proton-arm64ec-vanguard"
Could this potentially, have any chance, of being a method/branch of proton able to run the Vanguard anti-cheat, i.e being capable of running Valorant?
It's just a wish, but would be really nice if true.
It's exciting that they are using Waydroid. It would be great for Linux Mobile to have a corporation fund the development so that Android apps can be used where native applications are unavailable.
Compatibility with your existing Steam library out of the box will be a huge competitive advantage for Deckard over Meta Quest.