zlacker

>>frankj+(OP)
Asahi Lina is truly an inspiration for open source reverse engineering. For those not aware, they also live stream their coding sessions quite often: https://www.youtube.com/@AsahiLina

I'm excited for the day that I can easily install SteamOS (the modern one that runs on the Steamdeck) on an M2 Mac mini for an insanely powered "Steam console" for my living room TV.

>>jamies+9g
I wonder how long it's going to take for games to start generally supporting ARM. Getting Linux running well on M1/M2/etc.. seems like only half the battle for making a good gaming machine out of these.

>>ozarke+oh
I wouldn't count on many developers going back to update old games with ARM support. It's more likely that the community will work to build some sort of Box86 + Proton stack to get games working, which should get a lot of the classics working[0]. From there, I think the struggle will be getting Box86 to run fast enough for modern games. Apple's ARM CPUs have great IPC, but that can still get annihilated when it's forced to simulate SIMD/AVX instructions. I assume Apple has some sort of vector acceleration framework in Apple Silicon, but it will take time and effort to reverse-engineer and implement.

Things are certainly looking better than they did a couple years ago, but getting ARM to run x86 code faster-than-native is an uphill battle. Maybe even an impossible one, but I've been surprised before (like with DXVK).

[0] Crysis on a Rockchip ARM SOC, for example: https://youtu.be/k6C5mZvanFU?t=1069

>>smolde+1o
It's a little frustrating how it's the norm in the game industry for companies to toss a binary over the wall and maybe patch it for a short period after release (not a given, ports in particular are vulnerable to being forever stuck at 1.0), with significant technical updates being out of the question until it's been long enough for them to try to sell you a remaster.

Not having any experience in that industry, I wonder what the driving forces of this are. I suspect it's some combination of incredibly brittle codebases that cease to build if glanced at the wrong way and aversion to spending anything on games post-release.

>>kitsun+hy
Not supporting new platforms is because

- Total dependency on an engine's build system

- Lack of official support for uncommon platforms

- Extremely low expected ROI even if it were possible to deliver on other platforms

Gamedevs aren't in the business of building platforms, they're in the business (mostly) of consuming them and going where the players are.

Gamedevs not updating is because

- The engines themselves are indeed outrageously brittle at times, with LTS releases sometimes containing significant bugs that persist against newer releases of minor and major versions

- New releases can actually cause dramatic regressions, not just in terms of bugs, but in terms of features, stability, binary size, and more

- AAAs are wasting time chasing the next big thing, non-AAAs are struggling with few people and need to constantly be building the next thing because they're building products, not services

- Gamedevs are largely media/entertainment companies, very few act like technology companies