That's cool, just noticed too.

UMU is fresh out of the oven and a small platform like ZOOM has already managed a tool for Linux gamers utilising it. Granted, it's just a tool without a GUI or anything, but still. Already done more than GOG at least.

Might have to check out ZOOM now, have never bought from them.

Zoom saying there script is wine in it's pure form. So are they pushing wine or Proton?

They are pushing for Proton and for a good reason, it is a Wine fork made specifically for playing games whereas Wine is more of a generalist that won't allow 3rd party additions to be included such as DXVK, VKD3D-Proton etc. or specific patches.

What OWC aims with UMU is to literally get Proton running without depending on Steam Linux Runtime by forking it and make it run outside of Steam.

It is possible to run Proton without Steam at all for years but you'd be susceptible to various dependency problems which UMU makes it no longer being a problem.

If it's UMU, it's Proton.

Also from their website

https://zoom-platform.sh

Thank you both for the reply. I was asking because one Zoom employee said it's Wine in its pure form. Maybe I read it wrong.

So UMU is making it more streamline to use Proton without steam? Interesting, how much easier does it make installing GOG games? I might need to try it out now. Thank you for the information.

I can’t say anything about VKD3D-Proton, but for the lack of inclusion of DXVK, it is on the DXVK devs. They purposefully choose to develop it in a way that makes it impossible to include in upstream WINE (the lack of inclusion was not their goal, obviously, but they knew from the start that their choices would lead to this inability to include it upstream).

Currently Heroic Games Launcher has a built in UMU support as experimental which requires you to manually enable it from settings, Lutris also has it. You just install the game through em with selected Proton version on em and let UMU do its job.

Currently HGL is in partnership with GOG so each time you buy a GOG game through em they get some commission.

VKD3D-Proton is literally based on Wine's VKD3D, albeit more gaming oriented. As for DXVK it started off as a single project to get NiER Automata playable until it received some big attention and the real reason why it won't be included into Wine is because its written primarily in C++, not C as Wine team wanted it which is their loss.

Although i guess they also do not want to incorporate VKD3D-Proton as well which from what i've heard runs way better than Wine's own project.

I had no idea HGL was a parent with GOG right now. Why was this news not talked about more, or did I just miss it?

It was mentioned in their 2.13 release page. Forgot to mention that since 2.15 version they have an experimental Comet API support which allows for achievements and playing multiplayer games that are available only through GOG Galaxy, thus making it an alternative to GOG's own client.

Can you download offline installers from HGL? I never used HGL much.

Only through the Store tab which is basically a built-in browser, do note that it will not show the progress bar at all. Perhaps requesting a proper support for it would suffice.

It's nice to have that option, and it's better than nothing. I always use Lutris when I use Linux. Thank you again.

I think it's on Wine devs being too stubborn about it. dxvk should be included in Wine same as vkd3d-proton.

The real reason why it's not is simply lack of interest in supporting extra cases. Since Codeweavers want Wine to work on macOS they have to provide something that works there and that can't be dxvk and vkd3d-proton which use cutting edge Vulkan features. Apple lock-in freaks are at fault, since they don't alow native Vulkan on macOS. So Wine developers have to stick to MoltenVK and the like that doesn't allow them using advanced Vulkan features in wined3d's Vulkan backend. Result is degraded performance which dxvk and vkd3d-proton avoid. And that performance difference is super significant to always prefer dxvk / vkd3d-proton over wined3d (and Wine's vkd3d) on Linux.

That said, no one stops Wine developers from having separate paths for macOS and Linux with latter using all the best options (dxvk / vkd3d-proton). But that's some extra work which they don't want to do.

My personal opinion - it should have been included in Wine not external to it and inferior use case implementation (for macOS) should have coexisted with good one (for Linux) within the project.