Why doesnt Stream require their binaries to be compiled to some bytecode and transpiled during the install ?
THen they wouldnt require any emulator for any new compiles.
Why doesnt Stream require their binaries to be compiled to some bytecode and transpiled during the install ?
THen they wouldnt require any emulator for any new compiles.
> 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
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.
Also didn't they actually do this and realize that Windows API on x86/64 was as stable as anything they could invent?
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.
I mentioned this in the last paragraph of my previous message...
I don't know, but assumed that Valve doesn't require studios to recompile their software or use any special tooling, it's basically just packaging of existing executables. This is also why they do Windows on Linux emulation.
> This is also why they do Windows on Linux emulation.
They don't. They use WINE, which as the name says, Is Not an Emulator. :D
(I'll let my pedantic self out now)
despite the funny backronym, Wine actually IS a WINdows Emulator.
That will open a can of worms. For one thing, Valve will be accused of trying to create a walled garden. Plus there's the whole problem of supporting the back-catalogue as others have said.
---
Maybe the best that they could to is to offer to distribute recompiled versions of the emulated binaries, similar to how they distribute compiled shaders. But I don't know if that would work, especially legally.
Existing games will not be recompiled for the new bytecode target, and they want all of those games to work regardless.
Because even with their effective monopoly they don't have the power to bully developers into doing whatever suits Valve. And it would be disastrous for the industry if they did.
Several games in their library are actually just game updater/launcher binaries, which manage their associated game assets and binaries externally.
They do
x86 bytecode is bytecode
I mean don't modern CPUs basically just run an x86_64 emulator on a RISC machine anyway? Like there's a layer between the microcode and the actual x86 instructions already.
Yes, but the “architecture-independent” bytecode for these RISC machines that run underneath your various Intel and AMD CPU models is the x86_64 instruction set.
No, that's a myth. It's true that the instruction decoder in a CPU core translates from ISA opcodes to micro-ops for the backend, but those micro-ops are in many cases functionally very close to the ISA instruction and decidedly not RISC-like. For example, the ADD r/m64, imm32 instruction (read from memory, add constant, write to memory) is translated to a single micro-op on several Zen architectures [1], which is far from anything you could call "RISC".
[1] https://uops.info/html-instr/ADD_M64_I32.html
I think it's more like a (kinda) VLIW machine but yes, pretty much
that bites
because there's no gaming-oriented toolchain for it
I hate that you're being downvoted for asking a perfectly reasonable question.
Guys, if you don't like the premise of the question, reply and say why, don't downvote.
I think it's a good question, and my guess for the answer is this - which is going to be the easier problem to solve?
"Hi guys if you want to publish on Steam you have to use this specific tooling and language that'll compile to native code on first run" and everyone just has to do it
or
"Hi guys we want to be able to publish everything so it runs on Arch Linux that we run on our Steamdeck, even if only Windows binaries are available, so given that Gaben is a billionaire what we'll do is just pay guys to make Wine not suck"
You choose.