zlacker

[return to "Valve reveals it’s the architect behind a push to bring Windows games to Arm"]
1. charci+IV2[view] [source] 2025-12-03 17:57:36
>>evolve+(OP)
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.
◧◩
2. dev0p+b03[view] [source] 2025-12-03 18:21:19
>>charci+IV2
Why the vitriol? This is one of the rare cases where a company actually puts money in open source development. Of course they ultimately do it for business reasons but everyone benefits from it as a whole, so I fail to understand the issue here.
◧◩◪
3. charci+w33[view] [source] 2025-12-03 18:37:12
>>dev0p+b03
Because the title mislead me. It turned out that 0 windows games are receiving funding to add ARM compatibility.
◧◩◪◨
4. ninth_+bd3[view] [source] 2025-12-03 19:25:02
>>charci+w33
Your errant interpretation of the title would imply that Valve was funding individual game developers to support valve? This would be a fool’s errand, compared to the much more obvious interpretation that valve is funding a compatibility layer that would enable broad support for ARM.
◧◩◪◨⬒
5. charci+2t3[view] [source] 2025-12-03 20:36:52
>>ninth_+bd3
It's not a fool's errand. You are underestimating how few games most of Steam user's playtime is in. Getting proper support for ARM to make out the most performance on the most popular titles is a reasonable thing to fund. Valve can still use FEX for addressing the long tail of games, but it will have disadvantages to a proper ARM port.
◧◩◪◨⬒⬓
6. sophro+iV3[view] [source] 2025-12-03 23:04:06
>>charci+2t3
But is the disadvantage worth the relatively high overhead of specifically adding arm support? I doubt that. It is better game devs focus on what they're better at - x86 - while valve and open source devs focus on what they're better at, than trying to split funds across competing solutions to the problem.
◧◩◪◨⬒⬓⬔
7. charci+yb4[view] [source] 2025-12-04 01:03:45
>>sophro+iV3
The solutions have distant tradeoffs. When you want to run the latest PC games on mobile hardware using a battery, every cycle matters. Using translation layers for x86 will never be as good as as a native port.
◧◩◪◨⬒⬓⬔⧯
8. sophro+6m4[view] [source] 2025-12-04 02:43:01
>>charci+yb4
Yeah. Also, software written for a wide gamut of hardware configs, even those under the same CPU ISA, will always be slower than software written for a unique hardware stack and only shipped for that hardware. Does it follow that all software should be written for specific hardware? I think not, because the performance overhead you take on allows saving on massive economic costs. It just isn't realistic to use development resources in that way. Even if devs are better at making ports for their games than fex, that takes precious time and money away from making the game, adding features, polishing, etc. It is much more realistic and sensible to focus on the comparative advantage than the absolute advantage [1].

[1] https://www.econlib.org/library/Topics/Details/comparativead...

[go to top]