4 ms·

> Why doesnt Stream require their binaries to be compiled to some bytecode and transpiled during the install ? They still have to support the entire back-catal

> Why doesnt Stream require their binaries to be compiled to some bytecode and transpiled during the install ? They still have to support the entire back-catalog. It's not reasonable to expect thousands of existing games to port to ARM

DanielHB 8d ago
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.
- dezgeg 8d ago
  Games use plenty of native code; so much in fact that when Intel tried to enter the Android tablet market with x86 they had to write an ARM emulator.
  - DanielHB 8d ago
    I mentioned this in the last paragraph of my previous message...
    - TeMPOraL 8d ago
      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.
- mitxela 8d ago
  Also didn't they actually do this and realize that Windows API on x86/64 was as stable as anything they could invent?
- pjmlp 8d ago
  > 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.
TeMPOraL 8d ago
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.
lightedman 8d ago
"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.
- jamesgeck0 8d ago
  Steam has decades of games. It's highly probably a large percentage of them aren't currently even in a buildable state on Intel anymore.

DanielHB 8d ago

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.

dezgeg 8d ago
Games use plenty of native code; so much in fact that when Intel tried to enter the Android tablet market with x86 they had to write an ARM emulator.
- DanielHB 8d ago
  I mentioned this in the last paragraph of my previous message...
  - TeMPOraL 8d ago
    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.
mitxela 8d ago
Also didn't they actually do this and realize that Windows API on x86/64 was as stable as anything they could invent?
pjmlp 8d ago
> 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.

TeMPOraL 8d ago

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.

lightedman 8d ago

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

jamesgeck0 8d ago
Steam has decades of games. It's highly probably a large percentage of them aren't currently even in a buildable state on Intel anymore.