[dev0p]

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.

[charcircuit]

Because the title mislead me. It turned out that 0 windows games are receiving funding to add ARM compatibility.

[ninth_ant]

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.

[charcircuit]

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.

[avianlyric]

But why would Valve do that, Steam is a game market place, that happens to provide a really powerful comparability layer to allow you to run many windows games on not windows. It’s not a platform in any meaningful sense. The Steam deck is a platform, and the Steam frame, and if they can get existing games running on them, without involving the original devs what’s the problem? Dev get a new market to sell their games into, Stream gets a new market to extend their store front onto, how is that not a clear win-win?

Also Valve does fund plenty of games, such as all of the first party games you might have heard of, like Half Life, and its long tail of sequels and spin offs.

[sophrosyne42]

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.

[charcircuit]

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.

[sophrosyne42]

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...