[smoldesu]

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

[kitsunesoba]

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.

[stonemetal12]

>aversion to spending anything on games post-release.

I am pretty sure that is the answer. Unless the game is Cyberpunk levels of unplayable, there is no money in post release support unless it is bundled with DLC or GOTY releases.

Back in the day it was pretty commonly sited figure that like 90% of a game's revenue came in the first 3-4 weeks of release. DLC and "seasons" are an attempt to stretch it out and make more off a single release, but I haven't heard how well that works.

[masklinn]

> DLC and "seasons" are an attempt to stretch it out and make more off a single release, but I haven't heard how well that works.

That also dates back to back in the days, we just called it expansion packs.

[masklinn]

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

The primary reason is that there's no money in it. Like movies, your "one shot" game (without some sort of continuous billing e.g. mmo, subscription, continuous stream of DLCs) makes most of its revenue in the first few weeks, and once the kinks are ironed out what it makes afterwards doesn't really depend on maintenance.

Additional maintenance doesn't pay for itself, the producer doesn't pay the devs for that, and thus the devs take on the next contract to pay the bills. Not to mention additional maintenance is a risk.

[Gigachad]

Most of the time if the game was good and it’s been abandoned, someone will make a remaster or a modern take on it which now works on modern systems again

[ynx]

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

[jacquesm]

I much prefer that model over services that suddenly disappear.

[izacus]

Not to mention the predatory subscription models that are rampant in mobile for software that is equally as broken, just costing more.

[kitsunesoba]

The "binary abandonment" model can have effectively the same result, though.

An example that come to mind immediately is how much of a mess it is to get games that were built with Games for Windows Live like the PC port of Fable 3 running on modern Windows. It's possible, but there's a ridiculous number of hoops to jump through, none of which would be necessary if Microsoft shipped a quick and dirty update that pulled out the Games for Windows Live dependency.

[howinteresting]

GFWL games are really an exception -- most games on Windows or Proton work fine years down the road.

[nicoburns]

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

I'm pretty sure it's just vanilla ARM NEON so I don't think it will take any reverse engineering. The Apple Silicon GPU is custom, but the CPU is just minor extensions to (and compatible with) AArch64. Rumour has it that this is because AArch64 was designed by Apple and donated to ARM (who Apple has close relationship with being that they were a founding member).

[smoldesu]

Interesting, that's what I was curious about. NEON is a bit slow last I checked, but at least Apple is sticking to spec here. It does make me wonder how much performance is left on the table for ARM architectures that want to emulate x86, though.

...it also raises the question of how emulated titles fare against translated ones. It would be fascinating to see how something like Dark Souls Remastered performs through Yuzu vs DXVK on Apple Silicon.

[saagarjha]

Apple support NEON (and uses it for most SIMD code) but it also has other proprietary ISA extensions for e.g. matrix multiply.

[shaunsingh0207]

note that the proprietary extensions are extremely unlikely to gain linux support though, unless upstream arm adopts something similar

though amx won’t help out with emulation much

[58028641]

The problem with Box86 is that it requires 32 bit ARM, which Apple Silicon does not support.