For reference , Fex is a translation framework for x86 to ARM much like Apple’s Rosetta2 and Microsoft’s Prism.
Valve sponsor development as it’s also the way the new Steam Frame supports x86 games. It’s also being used (as a fork) in Crossover Beta to replace the use of Rosetta2.
This is what Android does with Dalvik/Android Runtime. Apps you download from the store are compiled to bytecode that is then compiled to native code at installation time.
With the compilation making use of the native instruction set supported for your device, so it can make use of newer arm instructions on newer devices while still supporting older devices.
This is the major reason app installation is so slow in Android compared to iOS (which pre-compiles everything). But it also greatly improves app compatibility with older versions.
There is no way Valve would be able to convince all the myriad of game engine developers to support a proprietary (or even open source) bytecode format even in the future. Best they could do is make it an opt-in.
Android only pulled it off because Google provides the "engine" (Android SDK) for all apps made for the platform and it did from the start.
And even so, most Androids games actually bypass this system entirely and just hand-compile to native binaries anyway. Because, again, the game engines don't want to support this bytecode format and google doesn't offer a C++ toolchain themselves that the engine developers could integrate with.
Your message seems to be arguing both points at the same time - at least that's how it reads to me; first, that it's absolutely feasible to do this because Android did, and then, that in reality game developers there casually defeated those efforts anyway.
> Apps you download from the store are compiled to bytecode that is then compiled to native code at installation time.
This is only true in Android 5 and 6.
Starting with Android 7, due to amount of time it took to compile in tiny ARM CPUs, limited optimisation levels, and Java's dynamic abilities, there was a full reboot of this process.
Which is an Assembly hand written interpreter, intended to allow for quick startup in case the JIT cache is empty, a JIT compiler, and an AOT compiler that only compiles the hot paths that the JIT already had a look into, and during idle times while charging so that it can have the CPU all for itself when doing optimisations.
Additionally several other measures were taken to optmise this process, via Play Store Services, devices can share PGO data gathered by the JIT so that each device doesn't have to start from scratch, thus the interpreter step can be skipped when metadata is available. To further improve this process, developers can do training runs, and ship the metadata themselves on the APKs.
Also during the compilation to native code, depending on code access patterns, the executable code gets remapped so that there is an optimal alignment for the instruction cache when reading from the executable code cache.
Google certainly offers clang as part of the NDK, and game development is one of the few officially supported scenarios to run native code on Android.
It's more than thousands, and not only it's not reasonable, it's not possible.
Plenty of games run on some critical optimizations that exploit native code quirks that may or may not hold up only because Windows papers over them by special-casing the game process at OS level. The source of such games may be stuck in IP limbo, with five different studios/companies claiming ownership (three of them dead or bankrupt), and even then, the only person who knows what and how needs to be reimplemented is on a remote tropical island, working for a competitor / happily retired / stuck collecting trash for a living, depending on how their career went.
Takes only a few such cases to turn out to be some well-known games with substantial legacy fanbase hoping to relive some childhood memories, to risk seriously damaging the "supporting everything" marketing angle.
Emulating underlying runtime is safer and more practical choice.
"It's not reasonable to expect thousands of existing games to port to ARM"
Realistically it is possible and not actually that difficult. The hardest part would be ensuring that specific code changes from older x86 code to modern ARM code actually translate over properly and perform as expected. The majority of work done there would have to be in the libraries that were used to build the game. For way older games, like the ones you'd run under DOS, it would be much easier, as most stuff was in ASM and C (you did have the occasional BASIC game or PASCAL game flying around which would likely need a little bit of extra work) so you'd just be doing direct translation of instructions.
dagmx · · focus · HN ↗
Valve sponsor development as it’s also the way the new Steam Frame supports x86 games. It’s also being used (as a fork) in Crossover Beta to replace the use of Rosetta2.
MiroslavPokorny · · focus · HN ↗
THen they wouldnt require any emulator for any new compiles.
swiftcoder · · focus · HN ↗
They still have to support the entire back-catalog. It's not reasonable to expect thousands of existing games to port to ARM
DanielHB · · focus · HN ↗
With the compilation making use of the native instruction set supported for your device, so it can make use of newer arm instructions on newer devices while still supporting older devices.
This is the major reason app installation is so slow in Android compared to iOS (which pre-compiles everything). But it also greatly improves app compatibility with older versions.
There is no way Valve would be able to convince all the myriad of game engine developers to support a proprietary (or even open source) bytecode format even in the future. Best they could do is make it an opt-in.
Android only pulled it off because Google provides the "engine" (Android SDK) for all apps made for the platform and it did from the start.
And even so, most Androids games actually bypass this system entirely and just hand-compile to native binaries anyway. Because, again, the game engines don't want to support this bytecode format and google doesn't offer a C++ toolchain themselves that the engine developers could integrate with.
dezgeg · · focus · HN ↗
DanielHB · · focus · HN ↗
TeMPOraL · · focus · HN ↗
mitxela · · focus · HN ↗
pjmlp · · focus · HN ↗
This is only true in Android 5 and 6.
Starting with Android 7, due to amount of time it took to compile in tiny ARM CPUs, limited optimisation levels, and Java's dynamic abilities, there was a full reboot of this process.
Which is an Assembly hand written interpreter, intended to allow for quick startup in case the JIT cache is empty, a JIT compiler, and an AOT compiler that only compiles the hot paths that the JIT already had a look into, and during idle times while charging so that it can have the CPU all for itself when doing optimisations.
Additionally several other measures were taken to optmise this process, via Play Store Services, devices can share PGO data gathered by the JIT so that each device doesn't have to start from scratch, thus the interpreter step can be skipped when metadata is available. To further improve this process, developers can do training runs, and ship the metadata themselves on the APKs.
Also during the compilation to native code, depending on code access patterns, the executable code gets remapped so that there is an optimal alignment for the instruction cache when reading from the executable code cache.
Google certainly offers clang as part of the NDK, and game development is one of the few officially supported scenarios to run native code on Android.
TeMPOraL · · focus · HN ↗
Plenty of games run on some critical optimizations that exploit native code quirks that may or may not hold up only because Windows papers over them by special-casing the game process at OS level. The source of such games may be stuck in IP limbo, with five different studios/companies claiming ownership (three of them dead or bankrupt), and even then, the only person who knows what and how needs to be reimplemented is on a remote tropical island, working for a competitor / happily retired / stuck collecting trash for a living, depending on how their career went.
Takes only a few such cases to turn out to be some well-known games with substantial legacy fanbase hoping to relive some childhood memories, to risk seriously damaging the "supporting everything" marketing angle.
Emulating underlying runtime is safer and more practical choice.
lightedman · · focus · HN ↗
Realistically it is possible and not actually that difficult. The hardest part would be ensuring that specific code changes from older x86 code to modern ARM code actually translate over properly and perform as expected. The majority of work done there would have to be in the libraries that were used to build the game. For way older games, like the ones you'd run under DOS, it would be much easier, as most stuff was in ASM and C (you did have the occasional BASIC game or PASCAL game flying around which would likely need a little bit of extra work) so you'd just be doing direct translation of instructions.
jamesgeck0 · · focus · HN ↗