Patreon Logo Support us on Patreon to keep GamingOnLinux alive. This ensures all of our main content remains free for everyone. Just good, fresh content! Alternatively, you can donate through PayPal Logo PayPal. You can also buy games using our partner links for GOG and Humble Store.
Latest Comments by Scoopta
Valve officially confirm a new version of 'Steam Play' which includes a modified version of Wine
22 Aug 2018 at 1:37 am UTC Likes: 5

When I saw the speculation you guys reported earlier I was against it. Now that I know it counts as a Linux sale I'm still not really for it but it does make me feel a little better. Although, I still probably won't use it because I'm worried that this will just be the norm for gaming on Linux. Who needs natives if wine is good enough right? That idea still rubs me the wrong way but it's cool technology never the less.

Valve may be adding support for using compatibility tools for playing games on different operating systems
19 Aug 2018 at 10:08 am UTC Likes: 1

Quoting: jarhead_h
Quoting: ScooptaI personally hope this isn't true. Maybe it's just me but I personally think it'll be a dark day in the Linux world when devs target Windows and just expect wine or some other compatibility layer to be used.
You mean right now? Because that's what we have. Right now. This world you're worried about where Linux is an afterthought if it's thought about at all is the world we have right now.

We've hit the chicken-egg problem head on. Valve isn't going to force devs to cater to us. They won't even force devs to use Vulkan which would make the WINE experience a whole lot nicer. But what they will do is spend their own resources to make their catalog available to us. It's very likely that DXVK is actually a Valve project, and it's open nature is Valve using us to beta for them. Happy to do it. More than happy if this eventually makes Steam's Windows catalog easily accessible to new users, and frankly, to me because WINE is a hassle.

I know it's not FOSS, but without any hyperbole, Valve doing this could be the most important computer news story of the entire decade because if Valve really does kick over this domino it means the eventual end of Microsoft's dominance because it means for the first time normies will have a real alternative to Windows. GAMERS will have an alternative to Windows. Do you look out and see a lot of love for Microsoft? I don't. I see a lot of people that want Windows without Microsoft there to ruin it. In other words, there are a lot of people that would be okay switching to Mint Cinnamon if they had easy access to the all the stuff they care about on Windows. Eye on the prize.

We can worry about Saint Stallman's blessings after we're free of Redmond.
Right now my Linux system doesn't have to emulate a Windows one to play games(except AAA ports). That's the future that scares me. I didn't leave Windows just to emulate it on Linux. Although maybe you do have a point. Maybe emulating windows is just an easy way to bootstrap Linux gaming. Maybe after it becomes reasonably popular the emulation will go away and we'll get real Linux natives. Being an after thought doesn't scare me, being an after thought where wine is the solution does.

Valve may be adding support for using compatibility tools for playing games on different operating systems
19 Aug 2018 at 10:02 am UTC Likes: 1

Quoting: ageres
Quoting: Scoopta"Ported." Everyone makes the FOSS argument but the entire game is proprietary so what does it matter if the layer is FOSS? If you don't have 100% free software then you're not in control anyway. That proprietary code could still do anything it wanted. As far as existing ports using layers. A compile time layer is not the same as a runtime layer but even still I do avoid most AAA ports for this reason anyway. I only occasionally buy AAA Linux games I'm extremely interested in. I mostly stick to Unity and UE4 games which are as native on Linux as they are on any platform.
I don't understand you. If your biggest anxiety is proprietary code, why do you use said Unity and UE4 games? They are not open-source. If it's about performance, well, Wine, DXVK and hardware is still evolving. I get solid 60 fps in Dark Souls 2 with DXVK, a year ago I wouldn't have believed this could be possible. Rise of the Tomb Raider on Vulkan sometimes performs better than it did on DX11 and DX12.
My problem is Microsoft's clutch on the gaming industry, not performance or even proprietary code. That being said I do prefer free software. Wine is FOSS but it's designed to meet Microsoft specs, not open standards. Microsoft ultimately controls some aspects of wine. They add a feature to DX and wine has to follow or else they break compatibility. That is the problem I have with wine. Well, one of many I have with wine.

Valve may be adding support for using compatibility tools for playing games on different operating systems
16 Aug 2018 at 6:15 pm UTC Likes: 1

Quoting: ageres
Quoting: ScooptaMaybe it's just me but I personally think it'll be a dark day in the Linux world when devs target Windows and just expect wine or some other compatibility layer to be used.
Yeah, sure, it would be much worse than now, when devs target Windows and just don't care about anything beside Windows. *sarcasm*

EVERY big modern software uses compatibility layers in some ways. At least we would know it's FOSS Wine and DXVK, not something unknown and proprietary.

Imagine this situation:
1. Games on Steam get Linux support,
2. Ubisoft (for example) watch significant income from Linux users,
3. They don't want to share that money with Gaben,
4. Uplay and some games there get ported to Linux.
"Ported." Everyone makes the FOSS argument but the entire game is proprietary so what does it matter if the layer is FOSS? If you don't have 100% free software then you're not in control anyway. That proprietary code could still do anything it wanted. As far as existing ports using layers. A compile time layer is not the same as a runtime layer but even still I do avoid most AAA ports for this reason anyway. I only occasionally buy AAA Linux games I'm extremely interested in. I mostly stick to Unity and UE4 games which are as native on Linux as they are on any platform.

Valve may be adding support for using compatibility tools for playing games on different operating systems
16 Aug 2018 at 7:05 am UTC Likes: 1

I personally hope this isn't true. Maybe it's just me but I personally think it'll be a dark day in the Linux world when devs target Windows and just expect wine or some other compatibility layer to be used. I understand that it can be a good transitional tool to make coming to Linux easier but I still wine is a generally negative impact on Linux. I don't want to live in a world where the software is open but MS controls the specifications because all the FOSS software has to be compatible. That's just one of the many philosophical issues I have with wine and similar utilities. A lot of people don't care as long as they get their games but I don't like the idea of relying on compatibility layers and the easier and better they become the less reasons devs have to do native ports. If you had a tool that could run windows software exactly like it was on windows with no bugs then no dev would bother porting. I doubt it'll ever get to that point but wine is getting pretty good these days.

Looks like Valve may be preparing a 64bit version of the Steam client
12 Aug 2018 at 5:57 pm UTC

Quoting: solar_domeSome games that say they are 64 bit, still use some 32 bit components.

An example would be GRIP
https://www.cagedelement.com/grip/ [External Link]

A relevant part of wine wiki:
https://wiki.winehq.org/Building_Wine#Shared_WoW64 [External Link]
But that's a strictly Windows problem so what does that have to do with the Linux version of steam?

Looks like Valve may be preparing a 64bit version of the Steam client
11 Aug 2018 at 10:05 am UTC

Oh thank fuck. Maybe I can finally disable 32 bit compatibility on my system. It all depends on how many 32 bit games I actually want to play so I guess I should start looking at that.

Language learning game Lingotopia to release on August 16th with Linux support
11 Aug 2018 at 10:03 am UTC

I wish they had Cantonese but the game does look interesting.

Snap! The new Minecraft launcher now has another easy way to be installed on Linux
29 Jul 2018 at 10:09 am UTC

Quoting: slaapliedje
Quoting: Scoopta
Quoting: slaapliedjeSnap pisses me off. Ubuntu literally forces it upon you, if you try to remove it, it removes the 'software-center' even if you're using the Gnome one instead of the Ubuntu one. They changed the dependencies from Debian's 'Suggests' to 'Recommends' for snap. And since by default Ubuntu will install Recommends as if they are dependencies, you have to force no recommends.

Time to go back to Buster...
I'm not a huge fan of snappy either. Nor am I huge fan of Ubuntu or really canonical in general.
Me either. I figured I would give it a try since somehow my Sid install on my laptop became corrupted and it was causing all sorts of errors that made me think I was having failing hardware, but everything seems to be running okay, so may just need to reinstall Debian. Ubuntu is too annoying.
Hmm that's kind of a weird problem. I too run Sid but I haven't had any issues like that. I started out on Mint but left because I wanted more control. I've only used Ubuntu itself a little bit but I really started to have problems with it when Canonical was caught sending search data from Unity to Amazon.

Snap! The new Minecraft launcher now has another easy way to be installed on Linux
28 Jul 2018 at 10:19 am UTC

Quoting: slaapliedjeSnap pisses me off. Ubuntu literally forces it upon you, if you try to remove it, it removes the 'software-center' even if you're using the Gnome one instead of the Ubuntu one. They changed the dependencies from Debian's 'Suggests' to 'Recommends' for snap. And since by default Ubuntu will install Recommends as if they are dependencies, you have to force no recommends.

Time to go back to Buster...
I'm not a huge fan of snappy either. Nor am I huge fan of Ubuntu or really canonical in general.