kllrnohj

It's primarily only the AAA multiplayer games that have that, not just AAA games in general.

Just browse the Deck Verified page for example: https://www.steamdeck.com/en/verified & https://store.steampowered.com/greatondeck/

Forza Horizon 6 and Assassin's Creed Black Flag Resync'd are both listed, and both are very recent, major AAA game launches. With top-tier Linux compatibility.

It is staggering how different the situation is now as compared to just a couple years ago. Steam Deck (and associated investments by Valve) are damn near a revolution. It's a perfect storm of the incumbent turning to shit at the same time the underdog really got its act together.

If you or your friend group is really into a game that doesn't have Linux support yeah that's a bummer, especially when it's just because of the kernel level anticheat that's horrifying in its own right (triply so when it's for a PVE game, cough cough, helldivers 2, cough cough). But I don't think that's most people anymore. The more casual and indie game scene these days is huge, and of course single player games in general continue to be super popular.

Then I don't understand your argument. If you're just saying what could go wrong with heap corruption, then your vtable complaint also applies to storing function pointers in arena allocators in Zig? Zig doesn't have anything special here?

You could write a JS engine with Zig-like idioms (arena allocation, static initialization)

Arena allocators & static initializers are not novel. You'll find them in high performance C++ projects as well, such as LLVM or JavaScriptCore. But arena allocators have the quite significant limitation that they only help when everything being allocated in them have approximately the same lifetime. So they don't help when you need to allocate memory to provide the native implementation of a JavaScript object, for example (eg, FFI).

You can just do that, and then Zig is really no less robust than Rust.

If you just don't write bugs, then yes all languages are equally robust, including assembly.

Zig, like C, is simply not a robust language. I don't know why this feels like something contentious? It's clearly not intended to be robust?

Re #3: vtable pointers aren't mutable...?

Because the transformer architecture that enabled modern LLMs wasn't invented until 2017[1]?

1: That's the "T" in GPT fyi, even though Google is the author of the research paper that changed everything

Bytedance and Tencent are tech giants for sure, nonetheless they’re not Google kind of giant.

$186 billion and $105 billion revenue in 2025 respectively vs. $402 billion? Yes, Google is larger, but they're all in that same ballpark?

ByteDance's 2025 net income isn't that different from Anthropic's Series H funding even ($50bn vs $65bn respectively).

But this is all also ignoring how much of China is state owned (25% of the GDP!), so the available resource pool is dramatically larger than it would appear depending on what the government decides is important

Or they just don't actually have any compute access restrictions of significance? Chinese companies can just go use those GPUs in neighboring countries that aren't export-restricted, like Malaysia. Like ByteDance openly did: https://www.tomshardware.com/pc-components/gpus/chinas-byted...

and Tencent is rumored to have done via Japan: https://wccftech.com/china-tencent-gains-access-to-nvidia-bl...

And that's not even considering just smuggling the GPUs in by eg buying them in Singapore.

AI-specific chips also seem to be on the easier side to design & create relative to high performance CPUs & GPUs, so there's no particular reason to expect Chinese domestic designs to continuously lag behind. They have access to the same fabs, after all

and a proper way to write parallel programs for when async would lead to all the bad stuff async leads to.

you need real threads for parallelism though? And real threads scale just fine such that m:n threading isn't typically needed.

That's because they are very rarely useful. This was true then and it's still true now. There's just not many workloads where it makes sense to need to rapidly launch a thread that doesn't need to do much of anything but does need to exist for a while before terminating.

What is useful is the state machine aspects of things like coroutines or async/await, but those aren't quite fibers and very much aren't M:N threading. A major use of them is in UI where they have strict thread requirements even.

maybe tell us how much a non-Apple system that you can run that (probably similarly or faster) would cost?

Ryzen AI Max 395+ with 128GB of unified memory can be found around $3-4k.

But 27B isn't that large, either, especially if you are ok with the quantized models. So this laptop choice seems to more be a "because they had it" rather than "this is what's necessary for this particular workflow"

You don't need nearly that much RAM to run Qwen 3.6 27B, though. qwen3.6:27b-q4_K_M is only 17GB, for example.

XNA, MonoGame, Love2D, etc. are all frameworks rather than game engines so they're absolutely doing typical engine work in the scripting language, if you need a different example.

And games using low end frameworks like that are already plentiful on the web, such as on itch.io. Heck you can even find games using Unity there, too.

especially when WebGPU is closer to the native graphics API than DirectX on Linux is.

Uh... no? no it's not? WebGPU is rather high level & feature limited, which is why it can even be implemented on top of GLES 3.1. It's cutting edge for the web, but compared to native it's positively ancient.

Meanwhile DX12 and Vulkan are quite competitive on features and behaviors. Also most people aren't going through such a translation at all in the first place regardless, so I don't know why you're framing it as some given.

Unity doesn't use C# for everything. Notably the game engine itself is not C# but C++. C# is essentially just the scripting language.

You're also ignoring the overhead of WASM -> WebGPU -> native graphics API, not to mention how much harder it is to develop and debug that platform than it is a native one.

Half Life 2 is only ~4-6gb and was designed to run on video cards with 128-512mb of RAM, and it didn't even do texture streaming so you just need to have those assets at load time. Sure you can stream those low res textures at an acceptable rate. That's wholly different from streaming the textures for a modern game, which are at least an order of magnitude larger, and are expecting to stream in from NVME/SSD storage.

This website is also a proof of concept, it doesn't care if people are actually able to play it consistently. It can afford to just say "anyone with less than 100mbps internet gets a shitty experience, lol don't care" and nobody will complain, because it's a free tech demo. Not an actual product trying to sell copies and make money. And certainly not anything remotely modern, we are talking about an over 20 year old game here. Technology did, in fact, get a little bit faster and more capable over those last 20 years, you know

While you got the Black Mesa remake confused, HL2 did get a free 20th Anniversay Update a couple years ago: https://www.half-life.com/en/halflife2/20th

So it's still worth a revisit :)

For what purpose, though? Why saddle yourself with the overhead & restrictions of WASM and the limitations of WebGL (or even WebGPU), just to run in a browser? The typical answer for running in a browser is the fast deployment, but if the user has to sit through a 20GB download anyway, then what's the point? Just to avoid needing an install wizard? And in case you aren't aware, 20GB would actually be a relatively small game. 60GB+ is quite common now (the more recent call of duties tip the scales at 140GB)

While MegaTexture was removed from Doom Eternal because it's just not necessary in a small level-based game like that, the general idea was carried on. It's a big reason you could basically describe the entire PS4 era as the era of texture pop-in. Virtual texturing made it very easy to build massively large worlds, using GPU "page misses" to figure out what textures to stream in.

The problem is, well, the player sees it. As ugly as fuck texture pop-in.

The problem with Doom 3's gameplay is it was too fucking dark and constantly having demons jump scare you or spawn behind you got stale quickly. At some point I need to give the BFG edition a try which at least addresses the "too fucking dark" aspect, but that's also now a 2012 game instead of a 2004 game.

Doom 3 and Half Life 2 were both quite demanding titles at the time, neither ran well on hardware of the era if you cranked up the settings & resolution. Doom 3 was definitely more compromised because of it, though, with too little lighting because of the "only real time lights" constraint (which the BFG edition changed, and also adopted the famous "Duct Tape" mod).

I think you might be misremembering Doom 3 a bit. Both it and Half Life 2 came out in the same year, and, well... just compare:

https://www.youtube.com/watch?v=aTJ1weGimZQ

and

https://www.youtube.com/watch?v=y_3vMUOayyc

Doom 3's fully real time lighting and bump mapping was technically impressive, and the live interacting UI was very trick, but the character acting and animation was definitely not SOTA. That was Half Life 2. And if we consider impact on the gaming landscape, Doom 3 was if anything a dud. Elements from that game were not taken along, including not even in subsequent Doom games. Meanwhile Half Life 2's approach to storytelling & world building, animations, physics system - those practically defined the next generation.

I believe all of these previews are using pre-production units. Production units should be better built with better tolerances since it becomes all factory done, but that's definitely something you'd have to wait and see when it actually begins shipping.

That said, given the price point and the new-ness of the manufacturer, there's all but certainly going to be fit & finish issues.

Valve has since clarified that all current units will have a single 16GB stick. It might change in the future, but as of right now everything is the same. I assume that 8GB sticks just kinda don't exist anymore, though.

A GPU defect on the Steam Machine requires a full replacement of the proprietary motherboard. You can’t put a new GPU in or have someone do it for you.

Of course you can have someone put in a new one for you, it's called an "RMA"? A GPU defect is going to show up well within the warranty period. It's things like fans that will fail over time.

Valve claimed in their internal tests it did not meaningfully change performance, which I'd be inclined to believe. The Steam Machine is likely going to be most often GPU bottle-necked, so the CPU performance regressing by even double digit percentages doesn't necessarily result in any change in gaming performance.

You'll note in that techspot comparison, by contrast, they used the fastest CPU and fastest GPU and then still used medium/low settings to really maximize whatever difference the RAM speed would have. Which is a valid test, but it's not necessarily going to generalize to low-end hardware. Like the CPU being limited to 90fps instead of 120fps doesn't matter when the GPU is struggling to hit 60fps in the first place.

The steam machine has upgradable storage and RAM, both being their respective commodity connections (m.2 & sodimm respectively). There's even 1 sodimm slot free from the factory if you want to immediately plunk in a 2nd 16gb stick.

Those two are realistically the only upgrades someone buying a prebuilt instead of DIY is going to entertain doing regardless.

But that's all besides the point, which it's simply that clearly the steam machine is priced fairly for the hardware it contains in the current economic market. Whether or not you personally would prefer a prebuilt or to DIY is entirely irrelevant

Steam Machine very clearly states Zen 4, so it has approximately a Ryzen 5 7600, not 3600. So no, the 225F is not going to be significantly more powerful.

The RTX 5050 8 GB is 10-20% faster

yeah... like I said, basically the same? but if you're determined to split hairs, then that 10-20% faster is also 10-20% more expensive ($1050 vs $1200), so it's still a wash either way. But when "just" a 5060 Ti 8gb (supposedly a $380 GPU) is then 50% faster than the 5050... Clearly the steam machine and 5050 are playing in the same ball pit here. They're doing the same gaming experience

I think you need to check out what prebuilt PC prices are now. This is pretty much the same price as a DIY.

Just to pick on someone, iBuyPower's cheapest "RDY" prebuilt gaming PC has 6 performance cores, 16GB RAM, 8GB VRAM RTX 5050, 1TB NVME, and costs $1200. Basically same specs as the Steam Machine, for a very similar price, but in a typical midtower instead of a sleek, compact cube

Or buy this and get the exact same thing, but without building and parting it our yourself? It's still an open computer, not a locked down console. The price reflects that reality. It's not subsidized because you actually just properly own it.

The price of this steam machine is a rounding error away from the build it yourself DIY price. It's not marked up, this is just what PC components actually cost these days :/

Yes, you kept binary compatibility but you that created so many other problems such as not being able to use value types in generics.

This is often given as the defensible reason, but it's not even that true. Java 1.5/5 had several "breaking" changes in it regardless including the newly reserved 'enum' and a whole freaking memory model update.

And besides if any of your dependencies updated for all practical purposes you did, too, since you had to use a newer runtime to run their code regardless, it never really made sense to keep using an older javac out of spite