> and modern multiplayer games with anti-cheat simply do not work through a translation layer, something Valve hopes will change in the future.
Although this is true for most games it is worth noting that it isn't universally true. Usermode anti-cheat does sometimes work verbatim in Wine, and some anti-cheat software has Proton support, though not all developers elect to enable it.
It works in the sense it allows you to run the game; but it does not prevent cheating. Obviously, Window's kernel anti-cheet is also only partially effective anyway, but the point of open-source is to give you control which includes cheating if you want to.
Linux's profiling is just too good; full well documented sources for all libraries and kernel, even the graphics are running through easier to understand translation layers rather than signed blobs.
These things do not prevent cheating at all. They are merely a remote control system that they can send instructions to look for known cheats. Cheating still exists and will always exist in online games.
You can be clever and build a random memory allocator. You can get clever and watch for frozen struct members after a known set operation, what you can’t do is prevent all cheating. There’s device layer, driver layer, MITM, emulation, and even now AI mouse control.
The only thing you can do is watch for it and send the ban hammer.
Cheating still exists and will always exist in online games.
Sure, but you still have to make a serious attempt or the experience will be terrible for any non-cheaters. Or you just make your game bad enough that no one cares. That's an option too.
> though not all developers elect to enable it.
Looking at you Rust.
Edit:
And the rest of you. If even Microsoft's Masterchief Collection supports it, I Don't understand why everyone else does not.
Then I saw the arewe…yet url and thought you meant Rust the programming language
Then I visited the arewe…yet link and realized it was the Rust game you meant after all
I know what you mean, sometimes I google Rust specific things (the coding language) and get Rust the game.
For awhile googling “Swift” was like that with Taylor Swift results instead of the programming language.
Likely a case where Google figured out which one you meant through the telemetry of what you clicked on and how you refined your search, now that personalization is automatic. In my case, I get four regular results, which are the financial standard, the programming language, the wikipedia page for the programming language, and an ISP; then I get a "top stories" block that is all about the singer.
More tricky for the sibling comment with Rust, where either one could be valid.
as a person that plays rust and writes rust I feel this all the time
> I Don't understand why everyone else does not.
It's because the Linux versions of those anti-cheats are significantly weaker than their Windows counterparts.
It's telling that Valve uses a user space anti-cheat (VAC) for Counter-Strike 2, but the competitive community overwhelmingly rejects that and ops to use a third-party Windows-only kernel mode anti-cheat (FACEIT).
I think even the "Major" tournaments which are officially sanctioned and sponsored by Valve, though organized by third parties, usually run on FACEIT or similar.
Would love to see it on MacOS X -- Steam works great on my Mac Mini for the games it supports, would be great to see everything run on it.
Are you looking for Crossover? It's a bit annoying to not run Steam natively (no cmd+H to hide, etc) but it's got a lot of support. Performance is decent on my M2 mini, and even cross-platform stuff like Baldurs Gate 3 is comparable performance to native.
Especially anything that Mac Steam natively calls out lack of 32bit support has good support.
Yep. I know Apple has little motivation to support such a project but it would be great to see them work with Valve on this. Having the majority of Steam games "just work" on modern Macs, like they do on the Steam Deck, would be fantastic.
I think it's more than "little motivation" if we're being honest. Right now Valve is quietly targeting MS' attempt to create a walled garden for gaming on Windows and (probably) cut them out. Their very clever approach has been a full end-run around the OS by using Proton, which I'm sure genuinely thrilled Apple... as long as Valve is only doing that to MS.
Why would Apple ever invite Valve to potentially do the same to them?
Especially looking at Apples recent gaming history.
When Cyberpunk, AC, and a couple other AAA titles came to macOS, Apple made a big deal of them being in the mac app store, specifically. They didn't go out of their way to call out that they run on mac, you can get them from Steam, etc. The big deal was they are in the app store.
That's where Apple wants mac gaming to happen so they can get their 30% cut.
I wish that weren't the case, but Apple's gonna Apple.
Yes, that is what I was alluding to.
But, I do think it might actually be a net positive for them on the Mac by expanding the audience of people who might buy a Mac.
Given that full PC-Game-style game sales via the Mac App Store are likely abysmal, at least compared to mobile game revenue, I don’t think they have that much to lose.
I'm not sure what FEX could offer on macOS that Rosetta 2 doesn't already, with better performance thanks to Apple Silicon magic.
Running x86 code on ARM macOS is the most solved part of the stack, if anything needs work it's the API translation layers.
Aren’t most Mac issues now around Metal vs OpenGL and DirectX?
[deleted]
Rosetta 2 is going to be EOL'd within the next few years. A more permanent solution would certainly be welcome.
AIUI they intend to retire support for x86 macOS apps in a few years, but Rosetta will remain as a low-level component so that things like Crossover and Parallels can continue to work. Maybe not forever, but there's no immediate threat of it being EOL'ed.
> Rosetta was designed to make the transition to Apple silicon easier, and we plan to make it available for the next two major macOS releases – through macOS 27 – as a general-purpose tool for Intel apps to help developers complete the migration of their apps. Beyond this timeframe, we will keep a subset of Rosetta functionality aimed at supporting older unmaintained gaming titles, that rely on Intel-based frameworks.
i’m not sure how end-of-life it will actually be because rosetta is used in apple/container and seems to be a large part of the virtualization stuff apple’s built in the last few years
I would imagine they would disable the user-facing "load x86_64 Mach-O's seamlessly" and other loader magic, and keep around the core for such things.
Are you expecting to run Windows 11 ARM version on your Mac Mini directly, or within Parallels?
I think it's a pretty reasonable wish for more macOS + Apple Silicon support of games, including more native FEX & Proton ARM support within the steam client. (We're lucky Steam works, it's a better games client than the Mac App Store dreams to be, but that's also not saying much either.)
You’d run FEX with WINE/Proton, no windows needed. If you did use a VM, I’d think it would be a Linux VM. But, Linux VM on macOS could already use Apple’s Rosetta2 for x86_64-to-arm64 translation.
Speaking of which, maybe you could just run the games with Apple’s WINE “game porting toolkit” direct with Rosetta2. Worth a Google.
Verge has a dynamic paywall - so it depends on how many articles you’ve read.
For those having issues, open in private mode I guess.
kinda funny that Microsoft has tried and failed multiple times to make Windows on ARM work
and then valve is probably going to succeed, to Microsoft's detriment
It may have taken them a while, but it does now work fine.
Define 'fine'
It turns out the best API for gaming on Linux and gaming on ARM was Win32 and x86_64. Who knew?
Well, compiling ARM game binaries is actually super duper easy and just totally fine. The issue Windows actually has with ARM is GPU drivers for the ARM SoCs. Qualcomm graphics drivers are just super slow and unreliable and bad. ARM CPU w AMD GPU is easy mode.
Does anyone know what the limfac is? The machine code produced is of course different on different CPU arches, but isn't this handled at the compiler level? I.e. lower level than game devs worry about.
The exception I see is if SIMD intrinsics.
This system allows playing unmodified production x86 executables on arm64. It doesn’t have anything to do with the developers.
Given how arm license is know to be less than friendly.... Wouldn't it be preferable to explore a RISCV architecture.
As far as I know RISC provides similar power efficiency and sleep that is like ARM.
>arm license is know to be less than friendly
Sure, it's not open source or anything. But ARM doesn't seem to be a typical greedy incumbent that everyone hates. They don't make all that much profit or revenue given how much technology they enable - there isn't much to disrupt there.
RISC-V is severely lacking in high-performance implementations for the time being.
Have we seen a commercially available high performance 64-bit RISCV chip at production scale yet?
There’s a lot of work and experience built up for ARM through Proton and other tech (that can be reverse engineered to see how it works) like Rosetta. A lot of that would have to be redone for RISCV. Seems like a lot of risk in the short term for what’s not an obvious product benefit.
I would expect the high-end RISCV market to mature before a company like Valve dives in.
>at production scale
You can even omit that part and the result is the same: nothing
No one has yet produced a RISC-V CPU or SoC with truly competitive CPU and GPU performance and compatibility to the current state of arm64 or amd64.
It’s a catch-22: why build a RISC-V CPU if there’s no software for it, and why write software if there’s no CPU to run it?
Until there's a common, well-supported, and sufficiently performant family of RISC-V SoCs or CPUs with support for existing well-supported GPUs, RISC-V support will be a massive pain in the ass of a moving/fragmented target.
This has held back Arm for years, even today the state of poor GPU drivers for otherwise good Arm SoCs. There is essentially a tiny handful of Arm systems with good GPU support.
That's a geopolitical question.
ARM is Western
RISC is China / Eastern
Valve is just trying to outflank Microsoft here. And they're doing a magnificent job of it.
Microsoft has on at least half a dozen occasions tried to draw a box around Valve to control their attempts to grow beyond the platform. And moreover to keep gaming gravitas on Windows. Windows Store, ActiveX, Xbox, major acquisitions ... they've failed to stop Valve's moves almost every time.
Linux, Steam Box, Steam Machine - there's now incredible momentum with a huge community with more stickiness than almost any other platform. Microsoft is losing the war.
The ARM vs RISC battle will happen, but we're not there yet. There also isn't enough proliferation for it to be strategic to Valve.
I suspect that many projects—such as BOOM—have stalled as a consequence of this situation. If it continues, the long-term impact will be highly detrimental for everyone involved, including stakeholders in Western countries.
RISC-V the ISA is open; RISC-V implementations need not be. There's no reason to believe that any truly high-performance implementations will be usefully open.
And since China has such a lead, you'll be using their implementations.
That's why this is geopolitical.
The DoD and Five Eyes prefer ARM.
2026 will be the year of the linux desktop
This is news how exactly since the announcement of arm Steam Frame?
Did they at the same time announced that they had been funding open source ARM compatibility for over a decade? Maybe it was mentioned somewhere, but the article had new details for me at least, even if I consider myself somewhat up-to-date generally.
Agreed. I saw the Steam Frame announcement, and plan to get one as soon as it's available.
I saw the mention of Fex then too, but absolutely nowhere, before now have I seen any information that they'd been working on this for the best part of a decade.
I think it's more revealing of how they've been playing the long game
[deleted]
I thought for a moment from the title that Valve has finally started funding game developers to make content from SteamOS, but no, this is just another case where Valve pays some contractors for open source projects and force developers to foot the bill for verifying compatibility.
> force developers to foot the bill for verifying compatibility
How are they forcing developers? If developers don't think it's worth it to make their game compatible with Steam Deck, can't they just avoid doing that?
I'm sure those developers hate getting a larger install base for free.
> and modern multiplayer games with anti-cheat simply do not work through a translation layer, something Valve hopes will change in the future.
Although this is true for most games it is worth noting that it isn't universally true. Usermode anti-cheat does sometimes work verbatim in Wine, and some anti-cheat software has Proton support, though not all developers elect to enable it.
It works in the sense it allows you to run the game; but it does not prevent cheating. Obviously, Window's kernel anti-cheet is also only partially effective anyway, but the point of open-source is to give you control which includes cheating if you want to. Linux's profiling is just too good; full well documented sources for all libraries and kernel, even the graphics are running through easier to understand translation layers rather than signed blobs.
These things do not prevent cheating at all. They are merely a remote control system that they can send instructions to look for known cheats. Cheating still exists and will always exist in online games.
You can be clever and build a random memory allocator. You can get clever and watch for frozen struct members after a known set operation, what you can’t do is prevent all cheating. There’s device layer, driver layer, MITM, emulation, and even now AI mouse control.
The only thing you can do is watch for it and send the ban hammer.
Cheating still exists and will always exist in online games.
Sure, but you still have to make a serious attempt or the experience will be terrible for any non-cheaters. Or you just make your game bad enough that no one cares. That's an option too.
> though not all developers elect to enable it.
Looking at you Rust.
Edit:
And the rest of you. If even Microsoft's Masterchief Collection supports it, I Don't understand why everyone else does not.
https://areweanticheatyet.com/
First i thought you meant the video game Rust.
Then I saw the arewe…yet url and thought you meant Rust the programming language
Then I visited the arewe…yet link and realized it was the Rust game you meant after all
I know what you mean, sometimes I google Rust specific things (the coding language) and get Rust the game.
For awhile googling “Swift” was like that with Taylor Swift results instead of the programming language.
Likely a case where Google figured out which one you meant through the telemetry of what you clicked on and how you refined your search, now that personalization is automatic. In my case, I get four regular results, which are the financial standard, the programming language, the wikipedia page for the programming language, and an ISP; then I get a "top stories" block that is all about the singer.
More tricky for the sibling comment with Rust, where either one could be valid.
as a person that plays rust and writes rust I feel this all the time
> I Don't understand why everyone else does not.
It's because the Linux versions of those anti-cheats are significantly weaker than their Windows counterparts.
It's telling that Valve uses a user space anti-cheat (VAC) for Counter-Strike 2, but the competitive community overwhelmingly rejects that and ops to use a third-party Windows-only kernel mode anti-cheat (FACEIT).
I think even the "Major" tournaments which are officially sanctioned and sponsored by Valve, though organized by third parties, usually run on FACEIT or similar.
Would love to see it on MacOS X -- Steam works great on my Mac Mini for the games it supports, would be great to see everything run on it.
Are you looking for Crossover? It's a bit annoying to not run Steam natively (no cmd+H to hide, etc) but it's got a lot of support. Performance is decent on my M2 mini, and even cross-platform stuff like Baldurs Gate 3 is comparable performance to native.
Especially anything that Mac Steam natively calls out lack of 32bit support has good support.
Yep. I know Apple has little motivation to support such a project but it would be great to see them work with Valve on this. Having the majority of Steam games "just work" on modern Macs, like they do on the Steam Deck, would be fantastic.
I think it's more than "little motivation" if we're being honest. Right now Valve is quietly targeting MS' attempt to create a walled garden for gaming on Windows and (probably) cut them out. Their very clever approach has been a full end-run around the OS by using Proton, which I'm sure genuinely thrilled Apple... as long as Valve is only doing that to MS.
Why would Apple ever invite Valve to potentially do the same to them?
Especially looking at Apples recent gaming history.
When Cyberpunk, AC, and a couple other AAA titles came to macOS, Apple made a big deal of them being in the mac app store, specifically. They didn't go out of their way to call out that they run on mac, you can get them from Steam, etc. The big deal was they are in the app store.
That's where Apple wants mac gaming to happen so they can get their 30% cut.
I wish that weren't the case, but Apple's gonna Apple.
Yes, that is what I was alluding to.
But, I do think it might actually be a net positive for them on the Mac by expanding the audience of people who might buy a Mac.
Given that full PC-Game-style game sales via the Mac App Store are likely abysmal, at least compared to mobile game revenue, I don’t think they have that much to lose.
I'm not sure what FEX could offer on macOS that Rosetta 2 doesn't already, with better performance thanks to Apple Silicon magic.
Running x86 code on ARM macOS is the most solved part of the stack, if anything needs work it's the API translation layers.
Aren’t most Mac issues now around Metal vs OpenGL and DirectX?
Rosetta 2 is going to be EOL'd within the next few years. A more permanent solution would certainly be welcome.
AIUI they intend to retire support for x86 macOS apps in a few years, but Rosetta will remain as a low-level component so that things like Crossover and Parallels can continue to work. Maybe not forever, but there's no immediate threat of it being EOL'ed.
> Rosetta was designed to make the transition to Apple silicon easier, and we plan to make it available for the next two major macOS releases – through macOS 27 – as a general-purpose tool for Intel apps to help developers complete the migration of their apps. Beyond this timeframe, we will keep a subset of Rosetta functionality aimed at supporting older unmaintained gaming titles, that rely on Intel-based frameworks.
https://www.macrumors.com/2025/06/10/apple-to-phase-out-rose...
i’m not sure how end-of-life it will actually be because rosetta is used in apple/container and seems to be a large part of the virtualization stuff apple’s built in the last few years
I would imagine they would disable the user-facing "load x86_64 Mach-O's seamlessly" and other loader magic, and keep around the core for such things.
Are you expecting to run Windows 11 ARM version on your Mac Mini directly, or within Parallels?
I think it's a pretty reasonable wish for more macOS + Apple Silicon support of games, including more native FEX & Proton ARM support within the steam client. (We're lucky Steam works, it's a better games client than the Mac App Store dreams to be, but that's also not saying much either.)
You’d run FEX with WINE/Proton, no windows needed. If you did use a VM, I’d think it would be a Linux VM. But, Linux VM on macOS could already use Apple’s Rosetta2 for x86_64-to-arm64 translation.
Speaking of which, maybe you could just run the games with Apple’s WINE “game porting toolkit” direct with Rosetta2. Worth a Google.
EDIT: indeed, you can already play x86 windows games on Mac using software written by Apple: https://gist.github.com/Frityet/448a945690bd7c8cff5fef49daae...
I think they're wishing for something like the Proton/Fex combination for running x86 Windows games on ARM Macs, like they already do for Linux.
Link could be changed to the source: https://www.theverge.com/report/820656/valve-interview-arm-g...
But that is paywalled
https://archive.is/AKhTr
Oh - I'm not seeing any paywall.
Nope...
Verge has a dynamic paywall - so it depends on how many articles you’ve read.
For those having issues, open in private mode I guess.
kinda funny that Microsoft has tried and failed multiple times to make Windows on ARM work
and then valve is probably going to succeed, to Microsoft's detriment
It may have taken them a while, but it does now work fine.
Define 'fine'
It turns out the best API for gaming on Linux and gaming on ARM was Win32 and x86_64. Who knew?
Well, compiling ARM game binaries is actually super duper easy and just totally fine. The issue Windows actually has with ARM is GPU drivers for the ARM SoCs. Qualcomm graphics drivers are just super slow and unreliable and bad. ARM CPU w AMD GPU is easy mode.
Does anyone know what the limfac is? The machine code produced is of course different on different CPU arches, but isn't this handled at the compiler level? I.e. lower level than game devs worry about.
The exception I see is if SIMD intrinsics.
This system allows playing unmodified production x86 executables on arm64. It doesn’t have anything to do with the developers.
Given how arm license is know to be less than friendly.... Wouldn't it be preferable to explore a RISCV architecture.
As far as I know RISC provides similar power efficiency and sleep that is like ARM.
>arm license is know to be less than friendly
Sure, it's not open source or anything. But ARM doesn't seem to be a typical greedy incumbent that everyone hates. They don't make all that much profit or revenue given how much technology they enable - there isn't much to disrupt there.
RISC-V is severely lacking in high-performance implementations for the time being.
Have we seen a commercially available high performance 64-bit RISCV chip at production scale yet?
There’s a lot of work and experience built up for ARM through Proton and other tech (that can be reverse engineered to see how it works) like Rosetta. A lot of that would have to be redone for RISCV. Seems like a lot of risk in the short term for what’s not an obvious product benefit.
I would expect the high-end RISCV market to mature before a company like Valve dives in.
>at production scale
You can even omit that part and the result is the same: nothing
No one has yet produced a RISC-V CPU or SoC with truly competitive CPU and GPU performance and compatibility to the current state of arm64 or amd64.
It’s a catch-22: why build a RISC-V CPU if there’s no software for it, and why write software if there’s no CPU to run it?
Until there's a common, well-supported, and sufficiently performant family of RISC-V SoCs or CPUs with support for existing well-supported GPUs, RISC-V support will be a massive pain in the ass of a moving/fragmented target.
This has held back Arm for years, even today the state of poor GPU drivers for otherwise good Arm SoCs. There is essentially a tiny handful of Arm systems with good GPU support.
That's a geopolitical question.
ARM is Western
RISC is China / Eastern
Valve is just trying to outflank Microsoft here. And they're doing a magnificent job of it.
Microsoft has on at least half a dozen occasions tried to draw a box around Valve to control their attempts to grow beyond the platform. And moreover to keep gaming gravitas on Windows. Windows Store, ActiveX, Xbox, major acquisitions ... they've failed to stop Valve's moves almost every time.
Linux, Steam Box, Steam Machine - there's now incredible momentum with a huge community with more stickiness than almost any other platform. Microsoft is losing the war.
The ARM vs RISC battle will happen, but we're not there yet. There also isn't enough proliferation for it to be strategic to Valve.
> RISC is China / Eastern
Imo this is a really strange characterization of RISC. I've never seen this before. I think you try to paint a misleading picture in bad faith, please consider this: - https://riscv.org/blog/how-nvidia-shipped-one-billion-risc-v... - https://tenstorrent.com/en/ip/risc-v-cpu - https://blog.westerndigital.com/risc-v-swerv-core-open-sourc... - https://www.sifive.com - ... - https://riscv.org/about/ -> "RISC-V International Association in Switzerland"
No: RISC is open ARM is closed.
I suspect that many projects—such as BOOM—have stalled as a consequence of this situation. If it continues, the long-term impact will be highly detrimental for everyone involved, including stakeholders in Western countries.
RISC-V the ISA is open; RISC-V implementations need not be. There's no reason to believe that any truly high-performance implementations will be usefully open.
And since China has such a lead, you'll be using their implementations.
That's why this is geopolitical.
The DoD and Five Eyes prefer ARM.
2026 will be the year of the linux desktop
This is news how exactly since the announcement of arm Steam Frame?
Did they at the same time announced that they had been funding open source ARM compatibility for over a decade? Maybe it was mentioned somewhere, but the article had new details for me at least, even if I consider myself somewhat up-to-date generally.
Agreed. I saw the Steam Frame announcement, and plan to get one as soon as it's available.
I saw the mention of Fex then too, but absolutely nowhere, before now have I seen any information that they'd been working on this for the best part of a decade.
I think it's more revealing of how they've been playing the long game
I thought for a moment from the title that Valve has finally started funding game developers to make content from SteamOS, but no, this is just another case where Valve pays some contractors for open source projects and force developers to foot the bill for verifying compatibility.
> force developers to foot the bill for verifying compatibility
How are they forcing developers? If developers don't think it's worth it to make their game compatible with Steam Deck, can't they just avoid doing that?
I'm sure those developers hate getting a larger install base for free.