It seems pretty clear to me that this is for Valve's long-awaited standalone VR headset, Deckard. What other reason would they have to support Gorilla Tag on ARM? https://x.com/SadlyItsBradley/status/1837210246076588500
Compatibility with your existing Steam library out of the box will be a huge competitive advantage for Deckard over Meta Quest.
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.
Could split it at the image generation layer? GPU work is done on the headset, sim is running on external machine.But then why use arm?
It should be called DeckHead
And with Waydroid support, games designed for Quest or other Android-based headsets could run on Deckard as well.
With SteamOS, they solved their dependency on Windows.
Now, they're trying to stop being tied to x86.
ARM64 is being tested because hardware is already widely deployed, but not being tied to x86 is the important part. Enabling e.g. RISC-V as well.
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.
Steam has supported native Linux games for a decade.
It has, yet the focus is all about Proton.
On my deck, I can run native Linux games
Sure, pity that the large majority on Steam library are running on top of Proton.
all valve games are linux native, as are lots of steam releases
The point is about the large majority that runs on top of Proton.
It would be great if this meant proton is coming back to macOS :)
I don't have high hopes however.
Just use Whisky (https://getwhisky.app/) or CrossOver (https://www.codeweavers.com/crossover)
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.
Me neither, but it's a shame. Those Apple Silicon chips are solid for gaming.
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.
Chicken and the egg.
Just my opinion.
> 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.
Nice find, it’s true.
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.
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).
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.
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 just play whatever games happen to work on Mac. Which isn't a lot of them, but it's enough.
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)
> deliberately blocking
What do you mean by that?
Most game studios don't care about Vulkan, that is why HLSL is what everyone uses instead of GLSL.
Any game engine worth using has Metal support for ages.
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.
No native Vulkan on macOS, right? I know of MoltenVK, but I have no idea how suitable it is.
It works well enough for many games via Steam games using Crossover but Vlavle may not be interested in targeting the platform anyways.
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.
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.
Huh. I wonder if this uses https://box86.org/ or such, like proton uses wine
Would it possible to AOT-recompile from x86 to aarch64? Or will it all be emulated forever?
Yes i dont see why not. At least on the surface technical level.
I used to work at ms on xbox backcompat games and we AOT recompile PowerPC arch to x86. (Xbox 360 to Xbox one).
You could likely aot recompile any arch with enough resources to fix up issues and things.
One key difference is older games were fixed so no more updates. It can be a little trickier with modern games still taking updates but could be done.
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.
Windows already AOT compiles x86 binaries to ARM64 when they are built with /ARM64EC option. It doesn't support AOT for older executables yet.
Rosetta does do AOT recompilation when it can.
Never died Gabe “G-Fat” Newell