←back to thread

445 points _JamesA_ | 6 comments | | HN request time: 1.368s | source | bottom
Show context
sitkack ◴[] No.44382539[source]
Given that Windows games run faster via Proton on SteamOS, developers should prioritize targeting SteamOS APIs—not Windows. This ensures compatibility with Windows while maximizing performance. Game engines like Unity and Unreal must adopt SteamOS as the primary target, with CI systems rigorously testing both platforms. SteamOS, not Windows, should be the baseline for optimization.

Does Valve run a SteamOS CI/CD farm? I could see a Rust based template and library for calling into this set of APIs that you could upload your well structured project and it would build and test for all platforms. Rust would just be the skeleton, your game logic could be in anything Rust could link to.

replies(4): >>44382671 #>>44383474 #>>44385317 #>>44387927 #
1. SchemaLoad ◴[] No.44382671[source]
I'm not sure that makes sense since the Windows API is the source of truth for how something works. If you make a game that works on Windows but not in Proton, Valve will push a fix that makes Proton work the same as Windows. But if you make your game work with Proton, but not Windows, you are relying on some quirk of Proton which isn't guaranteed to work in to the future and as soon as something else needs it to work the same as Windows, your game will break.

Test your game to make sure it works on the Steam Deck and avoid features that don't work on Proton, but you still have to primarily target Windows.

replies(1): >>44383004 #
2. sitkack ◴[] No.44383004[source]
You would need to test on both of course. I am arguing that one should target the fast happy-path on Proton as Proton is a subset of the Windows APIs that runs faster than Windows.
replies(1): >>44383366 #
3. SchemaLoad ◴[] No.44383366[source]
Proton isn't a subset of the Windows APIs though. It's very likely that you could end up depending on behaviors which only exist in Proton.
replies(1): >>44385555 #
4. viraptor ◴[] No.44385555{3}[source]
That's very much not what I expected. Do you mind pointing out something Proton implements that windows doesn't?
replies(1): >>44394579 #
5. happymellon ◴[] No.44394579{4}[source]
While they are wrong, in that Proton is absolutely a subset of Windows APIs, it is describing aiming for an implementation detail.

Yes call X is faster than call Y in Proton, but that could also be because its only 50% written and skips a bunch of side effects that will be created after you have written your game.

Therefore you need to view Proton as a potential moving target. Not that Windows isn't too, but its just not as clear cut as is being claimed.

I know this because I pin some games against older versions of Proton because they work better/faster.

replies(1): >>44396468 #
6. sitkack ◴[] No.44396468{5}[source]
Thank you. I didn't do a very good job of explaining why I think Proton is worth targeting specifically if perf tests show it running faster than Windows.

The Windows API perf topology is astronomically large.

That Proton is faster than Windows can't be universally true, but if you stick to that subset that has good conformance with Windows APIs and is also faster, that should be the target (and everything is moving of course).

Cross benchmarking games between Windows and Proton, taking API traces and finding those subsets of APIs can usage styles will enable a game developer to target those Proton APIs that are both conformant and fast. It is that subset of Windows APIs (temporal spatial structural usage) that I am suggesting being the target. The API linting tool might itself compare API traces. In fact for those API traces from performant AAA games, I could see generating a header file that only exposes the same API as used by that game.