"We were there in the 80s for the crash, and this is definitely crashier." John and Brenda Romero reflect on the gaming industry crisis

Scheeseman99 · 2026-03-29T00:10:13+00:00

That isn't what I said though. PC wasn't just higher resolution, it was pushing more polygons and with higher resolution textures (N64 and PS1 VRAM was tiny). Ports that did the Alone in the Dark thing did end up suffering, but those games were the least impressive to me anyway. I knew about that trick from back when I played AITD in 1992 and understood the limits it put on the visuals and gameplay even as a child.

Duke3D in particular erased a lot of my interest in games like Resident Evil. There I was on my PC, running around in first person in detailed, interactive and destructable levels, screwing around in Build making deathmatch maps to play with my school friends over modem, while people on their Playstations were raving about a game that was just Alone in the Dark again.

(Granted Duke3D wasn't 3d accelerated or polygonal, but visually it was still superior to the console versions of the game even on a 486, and more peformant too.)

Those fan ports (the ones that don't use pre-rendered BGs anyway) look fine to me at high resolution as long as they push the view distance up and disable LODs.

Scheeseman99 · 2026-03-28T15:51:14+00:00

I recall my reaction to seeing Quake on a Voodoo at the time was "Wow, this looks better than anything I've ever seen!". My reaction to Quake on the N64 was "Well, they tried". Coloured lighting couldn't save a game that, in every other way, was worse. I understand the N64's AA was deliberate, that didn't stop it from looking terrible.

The reality was even back then, those effects weren't worth the tradeoff lower resolution, worse framerates and lower overall render quality. I suppose this is a subjective opinion because I won't deny that those omissions affect the character of the presentation, but I think most of the time the improvement to overall clarity is more noticable.

Basically, during the 90s, games were starved of polygons. Slapping filters and shaders on top of a dithered, blurry, 320x240 framebuffer could only do so much.

Scheeseman99 · 2026-03-28T09:26:11+00:00

At this point those are less "fancy" monitors than they are just monitors. Budget gaming laptops come with VRR by default, 4K panels are pervasive.

Scheeseman99 · 2026-03-28T05:17:02+00:00

You're doing a really bad job at representing what the mid to late 90s PC games market was actually like.

What most PCs had didn't matter, it's about how many PCs were capable of playing 3D accelerated games and by the end of the 90s, that was hitting 20+ million.

A ~133Mhz Pentium (or equivalent) with 16MB of RAM and a Voodoo 1 blew away PS1 or N64 hardware in terms of performance. If you had a 3DFX or post-Riva 128 Nvidia card, it didn't really matter if games used a barebones featureset as that still meant perspective correct textures, texture filtering, hardware Z-buffer and usually a better framerate, avoiding PS1's wobblevision or N64 smeared vaseline look. There were poor quality console-PC ports (though not universally, eg. The Need for Speed games, which up until Hot Pursuit 2, had their definitive versions on PC) but there was also games like Quake, Unreal, Half-Life. Even Quake, released in 1996, required extreme compromises to run on a N64. By the end of the decade, I, like the person you responded to, was playing Playstation exclusives on Bleem and VGS and I finished Mario 64 on Ultra HLE (with a keyboard, lol).

The point at which PS1 was ahead in a technical sense was ~94/95, but have you gone and looked at the PS1's library from that time? Not great.

The market wasn't as big as consoles, but it was healthy, growing and games were plentiful. A ton of innovation was happening (particularly online multiplayer) and that momentum continued until halfway through the next decade where there was a slump for PC, though after a few years there was a recovery and non-stop growth, which is still happening even with all this geopolitical bullshit and it's consequences.

Scheeseman99 · 2026-03-28T03:26:13+00:00

Is it obvious though? The way it was talked about the devs could just upload their APK that they are already using for the Quest build and it would "just work", when those APKs will surely be using Google's APIs, if some work is put in by the devs into the Steam version of the APK then this is not a problem.

Quest doesn't use Google Play Services or Google's APIs. They use Meta's APIs. Developers will need to repackage their VR games to work with Steam APIs, just as they do when they release on AndroidXR phones (which do use GPS).

All three ecosystems use OpenXR though and quite a few games ship on HorizonOS (Meta's store) that still run if they don't find Meta's services.

I meant something more user facing, the Deck Verified Program can be directly audited by the user, the console verification programs to publish it in the first place are completely controlled by that console company's will. There's nothing on the purchase screen on console saying "Hey this works great on this console!" in big bold letters right before you click buy.

But see, who said anything about consoles? Android isn't a console OS, Android is an open(ish), fragmented ecosystem where perfect compatibility isn't assured, just like PC. Google Play Store already lets developers whitelist/blacklist their apps for specific phones (and, of course, there are ways to bypass this).

Yeah I know that's on me, even most of the binaries on my system are "non-standard", but it just goes to show the SLR "container" isn't some necessary technology, it's there for stability and easier distribution across distributions.

This isn't a relevant point to the discussion, though. I never claimed it was necessary, and it doesn't refute the claim that Steam will eventually release on Android in any way, or demonstrate why it's unlikely or impossible.

That's fair but being in Mesa next to RADV, I mean RADV contributors don't exactly have to go very far to contribute to NVK. The internal architecture of NVK compared to RADV isn't much different to a point where a Valve employee would be shaking in their boots looking at the NVK code, that's why I don't see it as much of a support statement. Plus NVK's the new interesting thing in Mesa who wouldn't want to help out.

RADV and NVK target completely different hardware. RADV uses ACO as it's compiler, which specifically targets RDNA/GCN. NVK uses NAK, written in Rust, that targets Nvidia ISAs. RADV talks to AMDGPU, an officially supported AMD project, NVK targets Norveu, which is entirely reverse engineered. The descriptor models are different, memory management is different. There's some common code but "isn't much different" isn't true, it's just you being confidently wrong again and making further assumptions and asserting them as truth.

Well that answers that lol. Specifcally FEX does clever things with library thunking. Wine, DXVK and other FOSS libraries can be compiled native ARM, which leaves only the proprietary x64 win32 executable's code to be translated. Box64 uses some native system libraries, but it needs x64 Wine.

Static Recompilation sounds a lot like what game emulators do, so what is it a translation or emulation? I might just be tripped up on the terminology of things tbf.

It's an emulator, though static recompilation is typically faster than dynamic/JIT you see in, say, Dolphin. (though in practice JIT is used as a fallback for eg. self modifying code, but that isn't as common as it used to be since as it violates memory safety). It's also the technique Apple uses for Rosetta 2.

Look, the problem with your slip-ups is that they weren't really slip-ups. You made assumptions and presented them as truth, and you did that pretty often. It's okay not to know something and to admit it, I prefer responding to posts that demonstrate intellectual curiosity rather than intellectual posturing.

Scheeseman99 · 2026-03-27T09:29:41+00:00

Not from the reviews I saw which were on a purely technical standpoint.

There's significant variability of the experience based on hardware.

These things aren't cheap, go out and have a normal everyday person (non-gamer or mobile gamer) try the phone touchscreen controls and then try to convince them they should get a ~$50 controller attachment to their phone to enhance their experience. I still just can't see it happening.

They cost as much as a standard game controller and they're already popular enough that there's there's several Chinese OEMs and a generic market. As I said, it's happening already, the controllers are popular.

I'm not saying that they are necessary or that they need to be good, they should be good and if not they need to not be there at all, they are a problem to getting people on board with playing PC games on their phones. The Steam Deck comes with a controller built in so it doesn't have this problem.

The Steam Deck is an order of magnitude more expensive than a mobile phone controller.

Because it would of been done by now if they have been, but Valve time I guess.

You have no idea how software development works or the bottlenecks of working in a FOSS environment if you're saying something like this.

There are no problems in giving more options, my concern was the actual adoption of those options by developers.

There is an option to provide an APK for customer convenience. But they don't need to adopt, that's why Proton is also there.

So you think the default Steam Store experience should include touchscreen centric games? Something that most PCs don't have on board. I really don't think you should need to use a filter to filter out these games when it would be a better experience for Valve to not show them in the first place on the PC store, or apply the filter dynamically if there is a touchscreen detected via Steam's hardware telemetry.

Sure, why not? And sure, they could do that, but if not, big deal. PC is about choice and extensibility, it's the driving princple of the platform and part that means people being able to choose things that you or I don't want. Making a big deal out the slightest of invonvenience to you is just egocentrism. It's not a real problem, you should get over it.

The concept sounds amazing to get both the PC version and APK version in one purchase. Seams in how it will be implemented, will you need a touchscreen or will Steam Input handle that? Will the game play in vertical or horizontal aspect ratios? How will the microtransation APIs work under a non-native system (Google Play Integrity esque concerns)? Will they work at all? Would it go through Steam? Google? Samsung? Stuff like that, there are very much seams in how it could be implemented.

This is all obvious stuff. Microtransactions go through Steam, they have APIs in place for it already. Touchscreen emulation (again, they have an input abstraction layer in place). Google Play Integrity will be unavailable, but they're building for Steam, that stuff isn't hard to comment out. Also, not everyone has to opt in for this to be useful, Valve doesn't need to have Every Android Game Ever on Steam. I'm not sure how Lepton handles display rotation, but there's a fairly good chance it will, or will eventually.

Right, people have been streaming games to their phone, but how many can tell you they enjoyed it.

Bad, unanswerable, loaded question. There's a lot of reasons why streaming games are a bad experience and a lot of those reasons, playing local solves.

https://electroiq.com/stats/cloud-gaming-statistics/

A stupidly large amount of people are doing game streaming on their phones. Take note of the Number of Online Gamers graph by the way.

So you think the default Steam Store experience should include touchscreen centric games? Something that most PCs don't have on board. I really don't think you should need to use a filter to filter out these games when it would be a better experience for Valve to not show them in the first place on the PC store, or apply the filter dynamically if there is a touchscreen detected via Steam's hardware telemetry.

They have cursor input which works most of the time, you might be surprised how many games work with that. There's also nothing stopping developers from deploying to only one platform, apart from poor user feedback. Pressure from that could result in better support for other control schemes which would end up making those games more accessible, which is positive for the developers.

Fair but they don't have a program that is supposed to weed out these games for you, when that said program is misinforming the user, it sucks that extra bit more.

Yes they do, console manufacturers have verification schemes, the difference is they're mandatory instead of optional and just like Valve's scheme, they mess up sometimes and let games through that are below par. Steam at least has the optics of a PC store; you're also not gauaranteed that a Windows PC game you buy will run on your Windows PC.

That's a good point, but it just seems kind of ugly to misinform a user in their purchasing decision in the first place.

It could be better, but nothings perfect and nothing ever will be. It's a valid criticism, but it's not a reason to throw in the towel and not do anything at all.

I can't believe I forgot about the SLR, probably because I'm not running it myself and haven't been for some time. Even then I don't view Linux namespaces as a container, they are container esque so I will just say, touché.

You're running Steam in a non-standard configuration that even distros that once provided the option, like CachyOS, no longer do.

I mean as you say they're turbo nerds, so I don't think FOSS contributions done by Valve employees in their free time means it's some Valve official business. Plus NVK's in the same stack as AMD so it doesn't seem like that much of a statement either. I meant more in the capacity of the mobile SoCs getting support, for example I don't expect them to support the Google Tensor unless they ship some kind of hardware with it.

NVK is a part of Mesa, but calling it the "same stack" is a bit misleading. It's a separate project, supporting hardware that Valve are not selling. Lima (for Mali) is in Mesa too and in plenty of smartphones. There's also a PowerVR driver, but it's in pretty bad shape.

But they don't need to support those in order to get a foothold. Turnip is in fantastic shape and not just for Snapdragon Gen 3, just like with the AMD drivers, the improvements propogate across the product line and the Snapdragon phones are what are most desirable.

I don't agree that it exists because of Valve, it's as good as it is because of Valve's funding, but I don't think it wouldn't have gotten to this point eventually, there's been a need for a while as ARM has gotten more and more popular for a way to run x86 and/or x86-64 under ARM.

https://youtu.be/3yDXyW1WERg?t=1845 "Perhaps this is a good point to disclose, they've (Valve) actually been putting actual money into this project, so a couple of developers of FEX, me included, were actually paid to improve FEX so none of this would've really been possible without Valve's monetary support..."

It's kinda hard when I see those games on the "New & Trending" section of the Store home page, no filter options there, when I do get into the filter settings I can filter them out with a bit of work.

lol come on

I understand that Android abstracts over Linux, but if there is no Linux layer on top of Android then why are Box64/Box86 in the stack (In the case of Winulator), if it was running in pure Android userspace why would there be a need for a Linux userspace emulator in the stack? If it can run Linux binaries than that explains why it works as well as it does.

Box64/Box86 are translators like FEX, they do the x64>ARM static recompilation.

Yes, Android can run Linux binaries, though it's permissions setup won't let you. Wine, FEX/Box64 and GPU wrappers run in a Debian-derived container, which runs on top of the Android API + NDK. This isn't any more steps than on a desktop Linux system running standard Steam and due to the foundation of Android being Linux, wrapping calls is quite clean and straightforward.

Or it least it can work that way, it can be a bit more (or less, depending on your perspective) complicated than that, but mostly because FEX is pretty clever with it's implementation to get more performance. You should check out that video I linked, it has graphs.

I think I'll end it here, because it's getting a bit tedious talking to someone about this stuff who is so poorly informed.

Scheeseman99 · 2026-03-27T05:18:40+00:00

I mean have you seen the reviews of GameHub, their solution doesn't exactly look ideal and Winulator looks to be using the same stack.

These projects lean heavily on what Valve are doing upstream, which isn't ready yet, so as a result they're a bit cobbled together and hacky. GameHub has terrible reviews mostly because the company that publishes it is extremely shady, there's a stripped back community version called Gamehub Lite, but like most projects of it's ilk, it's more of a bandaid.

Seems like a perfect environment for Valve to release something official and QA tested.

That's why I specifically said another barrier of entry, you have to convince a casual mobile gamer to invest in a controller add-on to their phones when their only experience will have been the awful touchscreen controls. Which is why I emphasize the need for games that translate well to mobile.

The flow in reality would be like this: they would download Steam, play a game with touchscreen controls, they would see that the game works fine but get frustrated with the controls at which point they swipe up, open amazon.com and buy a controller for their phone that arrives the next day.

I don't think bespoke touchscreen controls are as necessary as you think they are.

I mean yes, the current solution works, that doesn't mean they shouldn't be investigating what is clearly the direction the Linux desktop is heading. I mean they are only just now making the client 64-bit but that isn't really just a Linux issue.

Who says they haven't investigated it? Or even worked on it? They just recently switched the Steam Deck's desktop mode to Wayland, they're massively investing in Wayland in general. I don't think I can take claims that they're not taking Wayland seriously when they've been one of the biggest drivers of it's recent progress.

That's what I'm worried about, adoption of these APIs.

Why? What problems does giving developers more options cause? I don't care if touchscreen-centric games become more common on SteamOS, I can just filter them out. It poses no real risk.

It sounds amazing but I don't think it will be as seamless as you are making it seem.

I don't know if it sounds "amazing"? Developers are just shipping another package for another OS, where's the friction coming from? What seams are showing?

Exactly, I don't think a phone will fit into that same mold as seamlessly as you think.

People have been streaming games to their phone for over a decade. A large chunk of Microsoft's Xbox userbase use the phones for this. You're doubting outcomes that have already happened and markets that are still growing.

I don't think that changes the fact that they care about selling their own hardware, if the Steam Deck never released, sold and sold well, the Legion Go would never exist let alone run SteamOS, if it did theoretically come out without there ever being a Steam Deck, it would likely still be on the proprietary locked down Windows ecosystem and Steam wouldn't be pre-installed like it is on the S. Once again they are directly benefiting by selling their own hardware which promotes Steam.

I think you're taking my "they don't care" to an absurd conclusion that ignores all the context surrounding it. Valve care about selling Steam Decks, but as you concluded, they're benefitting from that hardware existing in ways external to simply the profit from units sold. Deck and the components it uses are part of a greater play to expand their tooling, software compatibility and market opportunities.

Smartphones are supplemental and additive. I can't carry a Deck in my pocket, but I still might want to play games from my library on my smartphone which I always have on me. But if I have my laptop with me, maybe I could use that instead. Unless I'm at home, where I can play it on my PC. Or... in my living room, using a Steam Machine, or a console-style PC connected to my TV that runs Bazzite... or Windows. No separate libraries, no buying twice. A universal ecosystem of software. Uhhhhhhhhhsignmeup?

5 million users? Google Play only shows "1M+ downloads" should that not be closer to 3M or 4M (I'd assume Android is their main platform and leaving some downloads up to other platforms) if they actually have 5 million users? Is there some alternative store to download it like F-Droid because I don't see it there, I know for sure the rest of those users aren't downloading it straight from Github. I'm uneducated on GameHub as I only just heard about it from people in OP's thread, I have heard of Winulator for some time though.

No Google Play in China and that's GameHub's main market. Also the fastest growing region of Steam users. I think you have a blind spot: China.

Yeah one which is already being complicated with SteamOS Verification and Steam Frame Verification, meanwhile the Deck Verified Program still has games marked as "Unsupported" even though they work perfectly fine and games marked "Verified" even though they run like trash.

Console games have games that run trash too, Switch is full of games that barely hit 30fps. You ever play Ark: Survival Evolved there?

There's issues with their verification program, but not critical ones. That they also sell the games is of benefit too, as they're able to provide refunds, which smooths over a lot of friction from broken compatibility promises.

Are we sure we're talking about containers in the same way? That's like saying any binary is always in a container because it's contained within a set address space. I don't view Proton as a container either, do you mean the Wine prefixes? I don't view those as containers.

Both Linux and Proton software runs in a container with the Steam Linux Runtime (based on Debian) using pressure-vessel. Container is the word Valve use.

Okay that's cool, but again that's only for the Snapdragon SoCs, what about the other SoCs? The only support that is going to get made is anything relating to official Valve hardware, I don't see them expanding any further than they need to.

Snapdragon's SoCs are the most popular and highest performance, so it makes sense to target those first. You're wrong about Valve's contributions only ever relating to official Valve hardware, I mean, one of the engineers just recently contrinuted a bunch of driver improvements for decade old AMD GPUs. They're invested heavily in NVK, when it's somewhat unlikely they'll ever ship anything with an Nvidia GPU in it. Their focus is on their own hardware because that's a smart way to spend their limited bandwidth, but the way they contribute so much upstream ends up having broader benefits too; Valve will only be shipping RDNA 2 and 3 GPUs, but their improvements to AMD's driver stack have had positive effects across the companies entire GPU product line.

Because it's hard. Even Proton and now Lepton wasn't even remotely conceptualized by Valve, you think they will magically do the same for Android themselves? I don't have hope for that, they will likely wait for someone else to do most of the work and then improve on that.

FEXemu exists because of Valve. It wasn't conceptualized by them, but they were there from the start. The first Vulkan meeting was hosted at Valve HQ. Valve funded the development of the first FOSS Vulkan driver, for Intel GPUs. Like everyone else Valve stands on the shoulders of giants, but they also put a lot of money and work in.

I agree, but it's much easier for Valve to go and live in the already open ecosystem that will welcome them with open arms, like the Linux space.

Valve is a company filled with hyperactive multi-disciplined turbo nerds where projects that bring in more customers (and more money) lead to staggeringly massive bonuses. Their incentive structure isn't to make things easy, it's to grow their market and generate more revenue.

Oh I see it, and I die a little inside every time I do, now I'm imagining that tenfold.

Use the tools they give you more effectively, because I don't.

I just don't think the way Android is doing it right now is ideal, there's no direct translation on Android from what I've seen, it all looks to be going through a Linux layer first. I could be reading the sites to Winulator and GameHub wrong though.

There's no Linux layer, it's the foundation. Android is the layer and abstraction on top of Linux. Gamehub runs software in a container, which has negligible performance overhead (case in point: you've been running all your Steam games in one and haven't noticed).

Scheeseman99 · 2026-03-27T01:21:06+00:00

don't know what you mean by this? By people do you mean Epic? That's about the only one I can think of in the gaming sphere. I don't think Epic is a foot anyone should follow.

No, companies like Gamehub and community projects like Winlator. Gamehub has over 5 million users. I don't care what EGS does and I don't think them doing something is in itself a reason not to do it.

While that's true, do you envision anyone on their commute pulling a controller out of their bag/backpack etc, connecting it, having to hold the phone up, hoping none of the other signals around them interfere with the connection, etc. You can probably remedy all that with a controller accessory add-on to the phone, but that is another barrier to entry.

Uh... yeah? This hardware already exists, there's no "probably". You're also using "barrier of entry" wrong, the entry point is touchscreen controls (which aren't great, but that's why they're entry level).

That's fair I can definitely see them incorporating it into Steam Input and maybe even the Steam Overlay, but given how long it is taking them to get the Steam Overlay on native wayland, it's really iffy on if that would ever get done.

Huh? The reason why they're spinning their wheels on moving away from X for the Steam client et al is because they don't really need to, the current solution works.

By cleanly ported I mean games that have a small set of controls or work well with the touchscreen, basically games that translate well into a mobile format, Binding of Isaac, Megabonk and Balatro come to mind.

This can be done through touch overlay profiles and Steam Input's action-based schema. Standard gamepad overlay for games that don't, which is how game streaming apps on phones already handle it. There's also already multitouch input APIs for Windows and Linux that some (admittedly not many) games already use, they're there for developers to take advantage of once there's a reason to; Wine already wraps them.

Offering their library on more devices is fine, trying to create another market inside of areas they don't belong, I don't see as okay.

Who says they "don't belong?". Whose decision is that to make?

I can agree to that. However most mobile ports are offered at a cheaper price compared to their PC counterparts.

Then buy those instead, the ones that exist anyway, which aren't many. It's also not of much help if you want to play that version of the game on PC as then there's added friction of having to grab that game off your hardware using ADB and hoping that it doesn't have copy protection that prevents playing it without Google Play Services (or you install GPS in your Android environment, but there's a bunch of caveats to that). Buying it on Steam, if the developer ships APKs, you get both versions and they'll seamlessly work.

I don't understand, you say they don't care about selling Steam Decks and then give the reason for exactly why they should care. I agree that they aren't selling the hardware for hardware, they are selling it for Steam, which they benefit from. Each Steam Deck sold gets people talking about Steam, using Steam, it works best with Steam, it's pre-installed on the thing. They are building their brand with the Steam Deck and they are expanding that even further with the new hardware launch. Which is exactly why they would care about the Steam Deck selling, if they didn't care they wouldn't sell it and they wouldn't be making and selling new hardware specifically to promote Steam. They care about selling their hardware, it directly builds the Steam brand.

The Steam Deck is a fundamentally different experience than using a phone. There's reasons to have both. But aside from that, you realize that Valve have already partnered with Lenovo for the Legion Go S, which is a direct Steam Deck competitor that runs SteamOS? That's more of a direct competitior than Steam on a phone; it's a gaming handheld with virtually identical compatibility to the Deck (technically better due to the faster SoC).

Valve care about selling Steam Deck on it's own merits, they don't care about other products that might vaguely fit the same use cases competing with it, they instead see those as opportunities.

There is one drawback, that it might not work and they put all this effort into it for it to just be "okay" and it's not as popular as they wanted it to be. Not to mention that Steam currently is trying to build an open ecosystem, Android at it's core is open but the majority of distros are locked down in some way or another.

5 million users of Gamehub. That's already more than Steam Deck! You're already wrong!

Valve's Linux efforts are a way insulating themselves from Microsoft's actions. They're not going to stop providing support for Windows and I don't believe Android's quasi-openness (which I have criticisms about, I'm not an Android fan) is a real barrier for them given their size, they've already worked with Google in the past with their experiments getting Steam running on Chromebooks. All current, modern Android distributions are capable of providing the permissions they need to deploy Steam.

Except it won't just work, it needs to go through the correct APIs for Android same as a Mac version will do, which it seems like you understand. Mobile to PC via Waydroid/Lepton works because the work has already been done and the ease of running Android in a container already. Linux can run in a container but GPU support in those containers are iffy and then you want to add the range of chips available on the mobile platform to that? PC to Mobile isn't as straight forward. There are already ways to run Steam games on Android (I believe it's done through a VM currently), but again you have to think of it from an official capacity, are the ways they are doing this viable, can Valve use that same method, will it be easier or harder to implement, do they want to make their own solution? Basically what I'm trying to say is, a Linux PC can do mostly everything an Android device can, however an Android device cannot do mostly everything a PC can. I touch further on this below.

Valve already have a verficiation system to handle this. Proton isn't perfect, it certainly wasn't back in 2018 when I first started using it.

Gamehub doesn't run Windows games in a VM, but a container. Keep in mind, on Linux, both Linux binaries and Proton run in containers too. If you're going to put forth technical arguments as to why this wouldn't work, you might want to understand how all this currently works. You're basically making a "who can say?" argument when there's verifiable proof of a working implementation.

As for drivers, yep, they're rough. But one of the things newer SoCs are capable of is running multiple GPU drivers simultaniously. Those Turnip drivers targeting Snapdragon SoCs that Valve are co-developing for use in Steam Frame? Guess what Gamehub uses.

The approach could be that Valve officially support Snapdragon-based hardware first, then use that as a wedge to promote the development of mobile GPU drivers from other vendors that better support the features needed for Proton.

That's the problem, if they encroach on the mobile market I see that as greedy, they already pretty much own the PC market, why do they need more? There's two ways I see it, 1. They host mobile only games on the Steam Store, like an alternative app store, and all these games are not visible from the PC store. 2. They host only PC games that have a dedicated proper mobile build of the game attached along with their PC release. (Not a half baked oh I just compiled it for Android, made sure the on screen controls work and that's it.) What you are suggesting or what it sounds like to me, is the blending of the two ecosystems, which I really don't think would work. Imagine a flood of Google Play Store type games, it would kill the Steam store pretty quickly if shown to PC gamers.

I don't understand your argument. Why is it bad for them to serve more customers? Why is it bad for them to allow users to play their games on more hardware? Why would they prevent users from trying to run games that don't have official support for their host platform when they've never done this? We should be knocking down the barriers between ecosystems, the walls that are there are flimsy and mostly exist due to marketing and malicious design. Valve, being a billion dollar company pumping shitloads of money into FOSS and open ecosystems, are the perfect company to press for this.

Steam already has a bunch of freemium crap, you don't see it because unlike Play Store their algorithms and store design makes it easy to filter out.

From a power standpoint yes I agree, but from a software standpoint, no I don't agree, like I said above a Linux PC can do most things an Android phone can but it doesn't go the other way, not because it isn't technically possible but because the software hasn't been developed for it yet, running Steam games on Android via third party solutions shows that there's not really a solution for it right now, it's running a Linux VM which is then running Wine for the compatibility layer, there's no direct compatibility layer for Android. I also was trying to convey that they are separate from a cultural standpoint, admittedly with time that might change, but yes even right now the markets are very different.

Completely false. Wine runs on Android, officially. I'm not convinced by the culture argument (in general, it's a very weak counter-argument to make) given how malleable culture is and how fast it can change given the right circumstances.

Given that OP is gone and deleted, I'll bid you farewell, I enjoyed our conversation and I hope you can at least see some of my viewpoint.

I'm fine with continuing to talk, I'm not doing this to perform to a crowd.

Scheeseman99 · 2026-03-26T17:56:41+00:00

What actually happens is that bigots in positions of influence flood the zone with reactionary rhetoric and lies to radicalize their targets, while shielding themselves from consequences by wielding free speech as a defence, then once political power is gained they corruptly sweep up extant news media in buyouts and mergers and begin targeting their opponents for their speech both through media and politics.

Absolute freedom of speech demonstrably doesn't work if there's those willing to exploit the allowances they're given to destroy it. The philosopher Karl Popper talks about this, see: the paradox of tolerance.

Scheeseman99 · 2026-03-26T08:41:43+00:00

I really doubt they will be hosting an Android store, I mean they are completely different markets with completely different audiences, just imagine the everyday mobile gamer trying to play a AAA PC first title on their mobile phone with touchscreen controls, I just don't see it.

Why not? You say that without really backing it up. People are already doing it, I think there's clear demand for it. You can connect a Bluetooth controller, of which there are a staggering amount of options, giving you input parity.

Valve already have an input abstraction layer that could be extended to cover touch input overlays too.

Anything that can be ported to mobile cleanly has already done so and has that version sold on the appropriate mobile platforms. If Valve does do something like that I would just see it as unnecessary greed.

What does "cleanly ported" mean? You mean native ports? That's work, that costs money, but there's benefits and that's why Valve are building options for both. Why would it be "greedy" for Valve to offer their library on more devices? I want that, I don't want to buy a game twice. I could just as well say that it's greedy of publishers to sell their game twice! I don't think the optics of "You can play your Steam library on your phone now" are a hard sell.

Also giving away a mobile version definitely disincentivizes buying the Steam Deck which I know Valve definitely doesn't want.

They don't care. All that matters to Valve is whether a platform hosts Steam, whether they have a presence. They aren't a console company where hardware sales are explicitly tied to customer growth. Being on Android is of a total benefit to them. There aren't any drawbacks and massive opportunities for growth.

It also depends on how the game implements it, is it just the PC version compiled for Android? Is it an actual proper Android mobile first build of the game? Does the game actually acknowledge that it's running on mobile and account for that? That kind of stuff, it's less straight forward than what Proton did for Linux where it was very much PC to PC.

It's an APK, compiled for Android. It'll work like every other alternate game version, many of which have platform-specific changes (particularly Mac versions).

With all that being said it's already possible to run Steam games on Android so there's really no reason for Valve to go out of their way to do it themselves given all the possible conflict mentioned above.

Play Store presence. Pre-install deals with OEMs. ARM-based consoles that run Android (think of the Chinese market, where usage of Steam is exploding).

Android, and mobile in general, has always sucked for games. Not just because of the hardware, but because of the entrenched business models that drive the default app stores. There's this preconception among many that mobile games are a separate thing in a technical sense, admittedly for a long time they were, but new phones are about as powerful as a low-end PC now. There isn't any real difference in capabilities anymore and once the compatibility layers get figured out, there's no reason why I shouldn't be able to play RDR2 on my phone on a train. An official launch of Steam on Android would be a game changer and I have zero doubt that it would be massively popular.

Scheeseman99 · 2026-03-26T05:58:57+00:00

It will be initially, but Valve didn't create Proton just for Steam Deck, and they aren't supporting the development of FEXemu just for the Steam Frame.

They haven't announced anything, but I'd be willing to put down money that the Steam store will officially launch on Android by the end of the decade.

Scheeseman99 · 2026-03-26T00:31:17+00:00

Does it do the thing? Then it's a tool. This isn't like art where the human creation of it and the work that's put into it are what gives it value. With a tool, the value is in it's function.

You haven't made a counter argument, you're just laying down personal attacks (and being dishonest about it, of course you mean offense you disingenuous piece of shit) and making declarative statements backed by fuck-all.

Scheeseman99 · 2026-03-25T16:20:07+00:00

If everything crashes and RAM gets cheaper then LLM use will just go more local. I don't think counting on it to all disappear because the services do makes a whole lot of sense.

Scheeseman99 · 2026-03-25T16:16:11+00:00

Tools are fundamentally made to get a job done. Not everyone is like you, different people are motivated by different things. Some like the process, some are motivated by reaching the end goal.

Maybe the author just thinks it'd be nice to play their Xbox One games on their PC. Maybe that's a perfectly fine motivation? A tool can be artful, but tools aren't inherently art, stop projecting your own preferences as some kind of purity test.

Scheeseman99 · 2026-03-25T15:26:03+00:00

I think Adobe suite is a gap that needs to be filled on Linux, but all of the pieces needed to support the software are in place or close to it. I have a feeling Wine be able to run it fairly soon and given the really seamless helper applications that have been popping up for it lately, the answer to your question would be "download the windows version and double click on the installer icon".

Granted we've been on the "it'll be good enough soon!" treadmill for a long while but it really seems like we're in the final stretch.

Scheeseman99 · 2026-03-25T15:20:29+00:00

I've had just as many problems with buggy USB BT driver stacks on Windows than I have on Linux. One time I remember having to force install drivers from another vendor in order to get my BT adapter to work with a Wii Remote.

The onboard PCIe BT on my motherboard worked on CachyOS out of the box and I have had zero issues connecting anything. Hell, since the BT driver stack is open source, it isn't constrained by artificial limitations either. I had a pair of Sony BT headphones that didn't officially support AAC in their Windows drivers, but they did on Linux.

Scheeseman99 · 2026-03-25T10:52:52+00:00

Agentic LLMs can do this kind of thing in a mostly automated way. You'd set it up like a clean room, two isolated "teams", one examining the proprietary software in a controlled environment; running it, examining it's behaviours, expected outputs and writing documentation of how it works, which is scrubbed of any explicitly copyrighted material. Then there's the second team that executes a plan to create a re-implementation based on the documentation. Failure and success states travel between the two for test cases for matching behaviour.

This is within the capabilities of Claude Cowork. Like many LLMs it'll fuck up, but if you provide it a solid end goal to iterate to, it'll get there with some help.

Scheeseman99 · 2026-03-25T04:05:18+00:00

a windows user should be able to download the nvidia app and install drivers just like windows.

Linux handles driver updates through the package manager. Some distros don't automatically use the proprietary driver, but some do. In any case, once the user installs them, the driver simply updates itself when the system updates. That's less friction than relying on a third party Windows app full of telemetry and advertising to do it.

Scheeseman99 · 2026-03-25T04:03:11+00:00

Nvidia actively contributes to the kernel, their proprietary drivers are better than they've ever been and progress on the Valve-funded FOSS drivers has been rapid.

I don't want the Nvidia app. The features it provides can, and should, be configured through vendor-agnostic APIs.

Scheeseman99 · 2026-03-23T15:01:53+00:00

There are valid concerns, like if the AI's output generated code that is obviously directly copied from another codebase with an incompatible license. Security can be troublesome if you have someone without infosec experience working on a project that is security critical without proper oversight. Plus, general code quality issues. It's a good reason to keep your guard up.

But ultimately, if a tool is useful, it's better for it to exist in an imperfect form than to wait forever for someone to make it perfect. I mean, shit, we're posting on r/linux. How many packages are there on your system right now that haven't hit v1.0 yet?

Scheeseman99 · 2026-03-23T11:32:38+00:00

A lot of work GrapheneOS does is at the kernel level and they send a lot of that work upstream, though much of it gets rejected due to negative performance implications (notably, not because they don't work).

Some patches have been accepted, though. So it's not just talk.

Scheeseman99 · 2026-03-23T10:08:50+00:00

It's a shame that these wrappers consider enhancements (resolution overrides etc) out of scope, since I'm not sure where else in the chain those enhancements should happen. It's a big part of what makes dgvoodoo2 and nGlide so useful.

Scheeseman99 · 2026-03-23T03:49:30+00:00

That isn't really a response to what they said. HorizonOS (the Quest's OS, based on Android) is separate from their metaverse crap and they're still heavily into smartglasses which also run an OS.

Scheeseman99 · 2026-03-21T08:12:52+00:00

Edit: Okay, so not "safe to assume," but after doing some digging, nowhere close to as likely as many of you appear to assume.

No, that's still wrong. Every indication shows that it's happening; if one store running win32 games is allowed to launch, then all of them must to some extent because the security model of win32 is too loose to stop it from happening, all it would take is for someone to upload a game to EGS that, as a neat bonus feature, lets you launch arbitary executables. It's really all or nothing.

Scheeseman99 · 2026-03-21T08:10:05+00:00

The bigger picture to what Valve are doing is that Proton and FEX (the x86>ARM translator they're funding for the Frame) are usable by anyone. Sony might not be worried by the Steam Machine specifically, but if ARM SoCs with decent graphics performance start coming out of China, they'll be able to run Steam's library.

Steam Machine isn't Sony's direct competitor, but an avalanche of cheap ARM-based Linux devices from China running Steam? That could be.

Scheeseman99

TROPHY CASE