101–110 of 202 posts
Earlier quoted context omitted.
all valve games are linux native, as are lots of steam releases
The point is about the large majority that runs on top of Proton.
> The day they actually support native Linux games
They do, and have for a long time now, for nearly all of their own releases. There's not much more they can do than that; they don't control what platforms other companies want to port to.
With SteamOS, they solved their dependency on Windows. Now, they're trying to stop being tied to x86. ARM64 is being tested because hardware is already widely deployed, but not being tied to x86 is the important part. Enabling e.g. RISC-V as well.
They are fully dependent on Windows Games developed for Windows. They are only working really hard not to pay for Windows OS licences. The day they actually support native Linux games, instead of doing Windows API translation is when I believe they are actually serious about Linux games, and not saving OS licenses.
But what they got in return is a much more usable gaming operating system that doesn't constantly pester you about switching to Edge, using Copilot or draining all your battery for an update while you game
What they got in return is freedom from Microsoft's arbitrary OEM hardware requirements like having a front camera for Windows Hello, or having a TPM
What they got in return ultimately is leverage. As sibling comment mentioned, they were in fear that they could be kicked off of Windows by Microsoft. Now, Microsoft is the one in fear that if they ever kick Steam off, gamers now have a perfectly functioning alternative operating system to switch to.
Earlier quoted context omitted.
TBH running through a Win32/DX API shim isn't much different than running through SDL, yet Linux games using the SDL are considered "native" but Win32 games running through Proton are not? (the Win32 and DX APIs are also much more straightforward to use than wrestling directly with X11, Wayland, Vulkan and the Linux audio API flavour of the month)
SDL handles everything for you. On Windows, good luck with running DirectX 6, 7, 8, and some DX9 and Direct Draw games under Windows > 8 without issues. Direct Draw games will lag even under an i5.
A Proton like layer would also totally make sense on Windows, assuming that support for older Windows APIs is better in Proton than on Windows itself (which isn't a far fetched assumption).
Earlier quoted context omitted.
I can think of one thing, which might not be what parent meant: the incentive of developing for linux, or paying porters like icculus and flibitijibibo to build a native version goes out the window, and the need for their kind of craft goes away. Frankly when the SteamDeck launched I hoped that game developers will start treating it as they do any other console and build specifically for it, but sadly Proton prevente…
I think it's a longer term play. Step 1) Establish a large enough non-windows userbase with great compatibility tools Step 2) Studios and especially game engine developers notice linux install base Step 3) Some tangible benefit to running natively, if only stability, pops up and the userbase is now large enough to care about it Step 4) Engines, and then games get better native support
To quote from down the conversation:
> @flibitijibibo (Jul 16, 2021): Don't look at me - I'm just trying to figure out how much time I have left, either way it's pretty clearly finite
Also some anecdata from someone that pretty much bought all native linux releases from Steam since the linux version was released: in the past 2-3 years there were barely any new ones, outside of Valve's own titles maybe.
Earlier quoted context omitted.
I can think of one thing, which might not be what parent meant: the incentive of developing for linux, or paying porters like icculus and flibitijibibo to build a native version goes out the window, and the need for their kind of craft goes away. Frankly when the SteamDeck launched I hoped that game developers will start treating it as they do any other console and build specifically for it, but sadly Proton prevente…
I don't think Proton has prevented anything. In fact, without it, and the back catalog of Windows games it makes available on SteamDeck, I doubt the handheld would have been as popular. SteamDeck was successful enough to get a re-release in the form of the OLED model, which is a big success for a Linux handheld. The longer Valve remains committed to the platform, and the more devices they get into the hands of consum…
Also, I never argued against Proton having been a boon for Linux gamers, but I tried to present an opposing point of view that usually does not get taken into account.
Like I mentioned in the other comment my impression over the past 3-4 years is that the number of native linux ports has dwindled to nothing and that is most likely due to Proton making them unnecessary.
Earlier quoted context omitted.
SDL handles everything for you. On Windows, good luck with running DirectX 6, 7, 8, and some DX9 and Direct Draw games under Windows > 8 without issues. Direct Draw games will lag even under an i5.
Good luck running a >20 year old native Linux game on a modern Linux distro without recompiling. A Proton like layer would also totally make sense on Windows, assuming that support for older Windows APIs is better in Proton than on Windows itself (which isn't a far fetched assumption).
It seems pretty clear to me that this is for Valve's long-awaited standalone VR headset, Deckard. What other reason would they have to support Gorilla Tag on ARM? https://x.com/SadlyItsBradley/status/1837210246076588500 Compatibility with your existing Steam library out of the box will be a huge competitive advantage for Deckard over Meta Quest.
It should be called DeckHead
Earlier quoted context omitted.
Me neither, but it's a shame. Those Apple Silicon chips are solid for gaming.
If Apple cared about gamers, they wouldn't have blocked proper Vulkan support. They simply don't care. A major reason to stay away from Apple if you are a gamer.
There's also only a handful of Vulkan games, supporting D3D11 and D3D12 on macOS would make a lot more sense. But in reality, porting to a different 3D API isn't what makes or breaks a game port.
Earlier quoted context omitted.
Even calling Intel x86 a loss overnight AMD is doing more than fine enough, server and consumer, for x86 to stay with a competitive presence into the 2030s even taking a dim view of the architectures future.
After buying Intel, Qualcomm could sink x86 by simply not renewing the cross-licensing agreement with AMD. With Intel's patents on emulating x86 on other CPU architectures, Qualcomm could then ensure that going forward, the only economically viable way of running x86 code is on Snapdragon CPUs. https://arstechnica.com/information-technology/2017/06/intel...
I doubt Intel would back out of the cross-licensing agreement that lets them implement x86-64.
Earlier quoted context omitted.
SDL handles everything for you. On Windows, good luck with running DirectX 6, 7, 8, and some DX9 and Direct Draw games under Windows > 8 without issues. Direct Draw games will lag even under an i5.
Good luck running a >20 year old native Linux game on a modern Linux distro without recompiling. A Proton like layer would also totally make sense on Windows, assuming that support for older Windows APIs is better in Proton than on Windows itself (which isn't a far fetched assumption).
As for the missing libraries, if you can fetch some old Debian DVD images (just the first DVD) it will run fine.