Quoting: Guest

Quoting: whizse

Quoting: GuestOut of curiosity, is there a commit or patch somewhere to go along with this?

All I could spot was this:
https://github.com/ValveSoftware/Proton/commit/6fdc1b54bc62ea54e573370a49e7d3b2d606ab3f [External Link]

Nothing as far as I can see on the proton-wine side. But I assume most of the work needed was done on the Steam client.

Makes sense I suppose. Still a little annoying: anything to fix it is not going to be open sourced, and running Steam through wine directly (this is what I still do on rare occasions) means it probably still won't work. DRM is just plain evil.

CEG was always a Steam client feature and since they won't open source the client ( obviously ) i don't get why you got annoyed.

Also; CEG always worked with Steam Wine ( Windows Steam client on Wine ) , Proton side didn't work until now because Linux client didn't have any CEG integration.

View this comment - View article - View full comments

https://forums.developer.nvidia.com/t/nvidia-470-74-breaks-gsync-support-monitor-modulates-between-0-or-144hz-and-flickers-black/189716 [External Link]

This driver seems to break Gsync.

View this comment - View article - View full comments

Quoting: chomwittIsn't Proton a patched wine?

Yes but where did you pull that "port" part?

No one ports anything, Wine/Proton usage =! Port

View this comment - View article - View full comments

Quoting: aufkrawallMemory leak (or what would be the appropriate term) with VKD3D-Proton is finally fixed.

Vkd3d master has a workaround for it, so are you sure if driver really fixed it or it is just vkd3d workaround?

https://github.com/HansKristian-Work/vkd3d-proton/commit/403d1f97434b6dbbdb3c8ab9391d6903846fd8d6 [External Link]

View this comment - View article - View full comments

Hopefully Valve will build up a cache for people to download in Steam like other games.

Fwiw, Valve doesn't build those pipelines. It is users.

They play the game, they start to cache them, client collects them from users, once there are enough to ship and validate client downloads them and client starts building shaders in two ways:

1-) Either in the background

2-) Or if it didn't have time to build them and they are still pending to be processed, client goes into full blast mode ( uses all available threads on your cpu) and builds them.

For background processing default value is 1/4 of your threads iirc.

View this comment - View article - View full comments

Quoting: Comandante ÑoñardoThe last "stable" NVIDIA 470.57.02 has memory leaks

Known issue. Reported to Nvidia when 470 was in beta phase. Mostly happens on D3D12 titles.

465 driver is fine. Regression is 470 specific.

View this comment - View article - View full comments

Quoting: gradyvuckovicIs there any advantage to using this over say Lutris for example?

Nope. Lutris is a launcher. What you meant is Lutris Wine builds i assume.

Lutris Wine builds are better in terms of game compat, they are based on TKG Wine and protects users from regressions with hotfixes they include to maintain game compat while providing upstream based builds.

View this comment - View article - View full comments

Quoting: Beamboom... And just to add to this, if we look at the available games on Stadia today:

https://stadia.google.com/games [External Link]

Scroll down to the store titles. Do anyone honestly believe that all those titles are really fully ported to Linux? Seriously? Look at that list.

Maybe a custom library or three are added just to add an API to the controllers or something, maybe, but honestly: It simply doesn't add up for me. There has to be a layer of some sort, with the vast majority of the code running being the original windows binaries.

Yes, all of those got ported to Stadia.

If you want i can throw Doom 2016 Stadia port experiences video from id Software dev, comments from Durante ( PC porter that was previously a well famed modder, also does Stadia ports )on Reddit about his Stadia ports and Stadia port requirements , Bungie's Destiny 2 Stadia port experiences video, Ubisoft's Ac Odyssey Stadia port experiences video.

Why those games ported to Stadia and why they don't see daylight for Linux desktop?

- Google pays small fortunes to get those ports on their platform.
- Supporting Stadia as a platform is lot easier than supporting desktop Linux; one driver, one set of hardware, no user input/choice that can cause different behaviour between instances. It is essentially a console but on cloud.
-While in house ports does exists and if they are confident about their Vulkan work it ends up in PC build ( such as Rockstar's RDR2,Vulkan is default api for RDR2 on PC) ; most of those ports were outsourced to porting houses such as QLOC ( Ported Cyberpunk 2077 to Stadia ) with basically zero tests being done on actual PC hw combinations. So neither build itself or VLK backend itself won't end up on PC for such cases.

PS: DXVK-native is also being used for some Stadia ports. Just like how Portal 2, Left 4 Dead 2 Linux ports are using DXVK-native. DXVK-native is meant for usage as a native library. Just name containing DXVK doesn't make it not native.

Stadia doesn't use Wine/doesn't rely on Wine.

View this comment - View article - View full comments

Quoting: BielFPs

Quoting: LeopardIt is not the fault of game devs; those popular engines has second class citizen support for anything that is a non MS graphics api.

Hence the point of my post: first ask for Vulkan then latter for a native version.

Yes, a Vulkan backend that got all dev time on a PC build is vastly better than having a port that translates from D3D code.

With source code access that is also ok ( for example like it happened with SoTR port of Feral) but usually that is not the case.

With having first class citizen Vulkan backends on PC ( Windows ) Proton should be much more viable.

It takes time and money to port an engine to another platform, so Proton can take care of this part.

View this comment - View article - View full comments

Quoting: BielFPsI said this before and I will say it again: Before ask developers to support Linux we need to ask them to support Vulkan first, in order to make them create better games with the api.

Every game made with Directx in mind is a potential "Proton only" game, which will result in cases like Trine where even if they have a native version it's different/worse than their windows counterpart, but more games made with Vulkan in mind means better performance, which means more chances to have a (good) linux native version.

Quoting: STiATOn other games (Valheim in example), the Linux port is so bad performance whise (OGL and Vulkan) that it's actually better to play using Proton,

Exactly, my last refunded game had a native port too (Last Epoch) where the game wouldn't even start in my machine, so what was the point of a native version for me in this case?

In case of Valheim I notice this too, and the cause is not Vulkan being worse than Directx, but probably because the developers are more comfortable at working with dx, because dx has more support (easier to work with) than Vulkan right now, hence why it's important to encourage more developers to work with Vulkan even if their games will be Windows only.

Valheim is a Unity title.

For Unity; GL is basically deprecated ( even if they don't call it that way) and Vulkan is there for mobile purposes.

Same goes for Unreal Engine too. Nearly all dev time+money goes into D3D side.

It is not the fault of game devs; those popular engines has second class citizen support for anything that is a non MS graphics api.

So Metal also shares the same fate.

View this comment - View article - View full comments