Quoting: mindedie

Quoting: missingnoForget about power, I just want a Steam Deck Pocket. One that fits in my pocket.

So... need line of "VALVE" chips. 3 ofc.
1st: Sub 10W, 1-5W or something for SteamPalm/Pocket/Pouch.
2nd: Chip for SteamDeck 2, generation leap? from barely 30fps to solid 60fps same game same power consumption.
3rd: 60-180W for SteamConsole or for those who constantly droning about 144Hz and 4K, SD-PPS (Portable Power Station edition aka always in the wall socket).

What about a Steam Book, a Steam Deck with the form factor of a 15.6" laptop? Could even throw in a Steam Controller or an actualized Deck Controller as an included accessory. I'd take that over a SteamConsole any day.

Don't much care about 144Hz and 4K myself. I rarely play games at my laptop's native resolution (1080p) any way. 720p or 810p are good enough for me. Better performance that way.

View this comment - View article - View full comments

I think that software licensing confuses a lot of people, who are expecting an ownership model such as you get when you purchase something like a hammer.

When you own a license, you own the right to use/play the software/game but you do not own the software/game itself.

Even with physical media, you may own the installation media but you do not own the software on that media. Much more complex than a simple physical ownership model.

But then, technically the music industry (vinyl, cassette, CD, etc.) was like this well before the advent of digital media ... we owned the media but not the music itself.

View this comment - View article - View full comments

Quoting: KlaasUnified Linux Wine Game Launcher?

Certainly less of a mouthful than ULWGL.

Quoting: Klaas

Quoting: whizseIf built against the Steam Runtime there would be no need for a separate projects

No. The wine version used by Proton (official or GE) uses patches that make assumptions about a running Steam client.

Wine-GE builds have (or had since they are discontinued) have those patches reverted.

Maybe I'm not understanding your response correctly but, my understanding of the whole point of the project is to remove the need for Wine-GE completely by essentially enabling Proton to function without a running Steam client.

Quoting: LiamIt means that any app can run games using Proton just like they would from inside Steam

Quoting: Liamacting as a copy of the Steam Runtime Tools and Steam Linux Runtime that Valve uses for Proton to allow Proton to properly run outside of Steam.

View this comment - View article - View full comments

Quoting: jordicomaAlso, can it be used to run native games? On steam you can choose a linux runtime that will solve possible future compatibility problems (I think). Like for example, new versions of libraries no compatible with the game.

To my knowledge, this project has nothing to do with native games. That being said, I could see how this could be incorporated into the project. The idea has very beneficial possibilities ...

View this comment - View article - View full comments

I'm not much for driving games but I really do like the visual style of this one ...

View this comment - View article - View full comments

Quoting: Liam Dawe

Quoting: Comandante Ñoñardo

Quoting: Caldathras

Quoting: Comandante ÑoñardoCan I use it on Lutris without issues?...

Not yet. Lutris is still working on implementing ULWGL. Unfortunately, GloriousEggroll stopped updating Wine-GE prematurely (IMO) so we are stuck with 8-26. ULWGL (Unified Linux Wine Game Launcher) appears to have been renamed to or nicknamed UMU launcher. You can monitor it's status at

https://github.com/Open-Wine-Components/umu-launcher [External Link]

I don't understand why they want to replace something that already WORKS with something that doesn't works yet..
Someone else should countinue the wine-GE project.

Because umu is just an entirely better system. It's not their fault Lutris has been slow to get support and an update out for it, they can't hold themselves back for someone else's software.

But that's just it, Liam. It's not just Lutris that's being slow on this. Heck, as far as I know, Heroic is no further along than Lutris. Check my link [External Link]. From what I can see, there has been no movement on the project itself since April.

I agree that UMU will be a better system but it's not fair to impune Lutris for this. I mean, I understand that it is going to take time to build the database and other infrastructure -- but why were the updates for Wine-GE stopped before UMU was ready for primetime? That's the decision I don't understand.

View this comment - View article - View full comments

Quoting: Comandante Ñoñardo

Quoting: Caldathras

Quoting: Comandante ÑoñardoCan I use it on Lutris without issues?...

Not yet. Lutris is still working on implementing ULWGL. Unfortunately, GloriousEggroll stopped updating Wine-GE prematurely (IMO) so we are stuck with 8-26. ULWGL (Unified Linux Wine Game Launcher) appears to have been renamed to or nicknamed UMU launcher. You can monitor it's status at

https://github.com/Open-Wine-Components/umu-launcher [External Link]

I don't understand why they want to replace something that already WORKS with something that doesn't works yet..
Someone else should countinue the wine-GE project.

I agree completely.

View this comment - View article - View full comments

Quoting: Comandante ÑoñardoCan I use it on Lutris without issues?...

Not yet. Lutris is still working on implementing ULWGL. Unfortunately, GloriousEggroll stopped updating Wine-GE prematurely (IMO) so we are stuck with 8-26. ULWGL (Unified Linux Wine Game Launcher) appears to have been renamed to or nicknamed UMU launcher. You can monitor it's status at

https://github.com/Open-Wine-Components/umu-launcher [External Link]

View this comment - View article - View full comments

Quoting: Cyba.CowboyWhilst both Apple macOS and Microsoft Windows operating systems have "broken" countless games over the years; many games won't even run under "modern" Windows operating systems without tweaks and work-arounds.

I agree completely. I have had more luck getting old Windows games to run stably under Proton/WINE than under Windows 10. And, frankly, many of them run better under Proton/WINE than Windows. Apple is infamous for having broken old game support. I don't use many "non-stock" Android apps but, you're right, I've encountered the problem here too. I certainly wasn't trying to imply that it was a problem that was unique to Linux.

Quoting: Cyba.CowboyBut your argument, nobody should make a "native" title of anything, ever.

I never said anything of the sort. There is no need to view the world in black and white. Please reread what I wrote. Specifically,

Quoting: CaldathrasIn my opinion, there really shouldn't be a Native vs Proton debate -- we don't need just one or the other. Both are complimentary approaches to running games natively in Linux. Let the developer choose which approach works best for them.

The point I was trying to make with my examples was that there is very little difference between the benefits of native or Proton/WINE at this point. Certainly not enough to be so polarized on choosing one or the other.

Quoting: Cyba.CowboyOnce again, your argument against "native" titles is just silly.

As I made no argument against native titles, this comment is just silly.

If anything, I argued in favour of expanding our view of what is native software on the Linux platform. In terms of the Native vs Proton/WINE debate, I don't believe that one is superior to the other.

(And yet, I am going to appear to contradict myself in the second paragraph below -- but when I've chosen the Windows binary, I have had no concerns with its performance under Proton/WINE.)

Quoting: Cyba.CowboyWhen developers actually take the time to optimize their games for Linux-based operating systems, the performance is always going to be better...

Well, you took my question out of context but I suppose I could have phrased it better. I meant based on my examples...

Given the choice, I often take the native Linux version of the game -- unless the reviews have given it a bad reputation for being out of date, poorly supported or poorly optimized. I can't comment further here as I don't usually take the trouble to compare against the Windows version.

Quoting: Cyba.Cowboyany game written natively for macOS or Windows is going to perform better when written natively

If you mean "installed" natively -- at the development level that Proton/WINE is at these days, I have not found this to be true. Many of the games I've installed under Proton/WINE outperform their native Windows installation. I was quite startled when I noticed this. Not sure what that says about their (or is it Windows'?) optimization...

--
My chief point in the latter part of my comment was to reinforce my agreement with EagleDelta's assertion that Proton/WINE is an API that allows Windows binaries to run natively in Linux. As Proton/WINE continues to improve, the optimization you laud in a native binary may cease to be the benefit you consider it to be.

Any way, despite the misinterpretation of the point I was trying to make, it has been nice conversing with you.

View this comment - View article - View full comments

Quoting: CGullIf Proton is there forever and Valve does nothing to shift publisher behavior then we are all just waiting for Proton and Steam Deck support to inevitably die due to the failure of Valve's subsidy. Then the carriage which brought Steam Deck users to the dance will turn back into a pumpkin and the entire Linux gaming market, now hollowed out by the exodus to Proton, will disappear as the entire Steam audience switches to Windows on some small device suspiciously shaped like a Steam Deck.

The flaw that I see in your pessimism is something you are clearly overlooking: Proton is Open Source. In fact, Proton is a fork of WINE, another very active project for running Windows binaries in Linux. Both projects already share ideas between one another. There is also the contributions of CodeWeavers (CrossOver) to both Proton and WINE. Even if Valve disappeared tomorrow (heaven forbid), their open source projects and developments will live on and continue in the Linux community.

Another point I want to make is the often overlooked flaw in the whole Native thing. Linux evolves and changes all the time. As a relative newcomer to Linux gaming, I have already encountered numerous old native games that simply will not run on modern Linux configurations -- the libraries and technologies they depend on are no longer there. And, I am just thinking of the FOSS games & applications. Then there are the commercial native software that their developers no longer support -- they suffer from the same problem. So, how is running natively any better than utilizing Proton/WINE? At least Proton/WINE provides a mechanism to support the old dependencies that the Windows binaries rely on.

Consider EagleDelta's point from another thread -- link

Quoting: EagleDeltaHonestly, I get really annoyed by the "Proton/WINE isn't native" arguments. If WINE or Proton were Emulation tools, I'd agree, but where emulation tries to mimic hardware and other aspects that simply can't be done "natively", WINE and Proton's other tools are actually rebuilding the Windows and DX APIs for use within Linux. As such, Proton/WINE are absolutely native but the very definition of what an API does. I'm speaking of this as a Software Dev myself that works with various APIs every day. I've said it before and I'll say it again, if WINE/Proton isn't "native", then no API is native.

As EagleDelta points out, the flaw in the thinking of the Native vs Proton debate is the misunderstanding of what Proton/WINE actually is. It is an API that allows Windows binaries to run natively in Linux. Additional features of Proton/WINE making old dependencies/libraries available to these binaries is a huge benefit that old or forgotten GNU/Linux binaries often don't receive. In my opinion, there really shouldn't be a Native vs Proton debate -- we don't need just one or the other. Both are complimentary approaches to running games natively in Linux. Let the developer choose which approach works best for them.

View this comment - View article - View full comments