4 ms·
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
by MiroslavPokorny 1mo ago
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.
- matheusmoreira 1mo agoExisting games will not be recompiled for the new bytecode target, and they want all of those games to work regardless.
- MiroslavPokorny 1mo agoNo im simply suggesting that Steam take this approach and prepare for the future. One day todays latest x86 will be old and some new architecture will replace it.
- rwmj 1mo agoI 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.
- cassianoleal 1mo ago> 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)
- mitxela 1mo agodespite the funny backronym, Wine actually IS a WINdows Emulator. Someone apparently told them that it's only called an emulator if it's emulating a CPU architecture, but that's not true.
- cdmckay 1mo agoI thought it was an implementation of the Win32 API as a compatibility layer. What is it emulating exactly?
- anthk 1mo agoDoes Windows NT have a Windows 9x API emulator?
- pjmlp 1mo agoWindows NT predates Windows 95 for two years. And yes it did had emulators for Windows 16, and DOS https://en.wikipedia.org/wiki/Virtual_DOS_machine https://en.wikipedia.org/wiki/Virtual_DOS_machine https://en.wikipedia.org/wiki/Windows_on_Windows https://en.wikipedia.org/wiki/Windows_on_Windows
- fredoralive 1mo agoIf you squint a bit (well, a lot really), Win32S on 3.1 and Windows 95’s Win32 implementation are Windows NT emulators running on top of 16 bit Windows.
- mitxela 1mo agoWindows NT doesn't emulated Windows, it is Windows. Wine is not Windows and emulates Windows.
- MiroslavPokorny 1mo agoIt is windows today, but in the beginning the two were incompatible different products.
- swiftcoder 1mo ago> 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 1mo agoThis 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.
- cwillu 1mo agoSeveral games in their library are actually just game updater/launcher binaries, which manage their associated game assets and binaries externally.
- SSLy 1mo agobecause there's no gaming-oriented toolchain for it
- account42 1mo agoBecause 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.
- MiroslavPokorny 1mo agoNot suggesting they FORCE developers, im simply suggesting that another option for distribution would be an advantage.
- ekianjo 1mo agoa dominant position is not a monopoly
- account42 1mo agoSure, it just quacks like one.
- raverbashing 1mo agoThey do x86 bytecode is bytecode
- DonHopkins 1mo agothat bites
- ErroneousBosh 1mo agoI 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.
- raverbashing 1mo agoI think it's more like a (kinda) VLIW machine but yes, pretty much
- MiroslavPokorny 1mo agoVLIW implies packets of different independent instructions that can be executed in parallel. I dont think this definition is ever true for the vast majority of x86 instructions.
- sph 1mo agoYes, 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.
- adwn 1mo agoNo, 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 https://uops.info/html-instr/ADD_M64_I32.html
- ErroneousBosh 1mo agoI 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.
- 4thguy 1mo agoThat 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.
- wat10000 1mo agoThat dream of write-once-run-anywhere has been attempted for decades and is still a massive struggle. And Steam isn’t in a position to mandate that kind of massive change. They’re big, but they still have competition from other stores and from direct sales.
- MiroslavPokorny 1mo agoMost of those write-once-run-anywhere platforms struggle on the UI simply because host o/s are the same but often quite different in L&F. On the CPU level, ignoring native WORA guis, java and dotnet are very successful WORA platforms.
- gwbas1c 1mo agoA few reasons: Bytecode can't really abstract the differences in memory model between the two different processors without some kind of consequence. (IE, it would be slower.) I've personally done some high performance multithreaded programming in C# / .Net, but it only "works" because C# / .Net assumes the TSO memory model. (Described in TFA.) In contrast, games need to squeak every cycle of performance out of their chips, and optimizations can be very CPU specific. When games target bytecode, they either won't be able to take full advantage of the hardware, or otherwise will need a lot of platform-specific fallbacks (that negate the point of bytecode anyway.) (This is why I prefer console gaming or "simple" games that don't tax the hardware.)
- MiroslavPokorny 1mo agoI appreciate there will parts of a game that have hand rolled assembly, but even those have problems when x86 move forward. In the near future SIMD instructions will double their widths and todays fast code using them will be old. C# solves this problem by providing rich libs, so Microsoft continues to evolve faster functions, without programmers having to the all do the same work again and again.
- well_ackshually 1mo agoBecause nobody would publish through them anymore. Because Valve has zero legitimacy to mandate that anyone changes their software for any reason. Because this is such an apple-brained, anti developer, anti user move that noone else in the industry does it. Because Valve mandating that for their own gain would bring in such a gigantic gatekeeper lawsuit. Because you profiled your code, optimized, then you'd then rely on Valve's "transpiler" to not write back absolute dogshit code back to the users. Because if it doesn't work well, people are going to blame the video game developer and never Valve. The list is extremely long, and the only people it would benefit is Valve.
- MiroslavPokorny 1mo agoWhat makes you think that i suggested that a neutral bytecode should be the ONLY option ?
- pkasting 1mo agoDisclaimer: I work for Valve, but I had nothing to do with Fex or anything related. There are a lot of other replies here, but one additional consideration is which solution is generally beneficial outside the original problem domain. A Steam-specific bytecode is applicable to games on Steam, whereas x86 emulation on ARM is of general interest to many problem domains today. Working on the latter could be viewed altruistically (it benefits the larger community) or self-interestedly (other developers are more likely to do work for us), but either way, it's an argument for the generalist path.