Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Integrate UMU-Launcher for a Native-Like Windows Gaming Experience #3537

Open
RaulKong898 opened this issue Oct 19, 2024 · 9 comments
Open

Comments

@RaulKong898
Copy link

Tell us the problem or your need

Currently, running Windows games on Linux with Bottles, while functional, can sometimes lead to compatibility issues and performance limitations due to the inherent challenges of emulation. This can result in a less than ideal gaming experience for users.

Describe the solution you'd like

Integrate UMU-Launcher into Bottles. UMU-Launcher leverages Steam Runtime and Proton, offering a containerized environment optimized for running Windows games. This integration would provide:

Enhanced Compatibility: By utilizing Proton, compatibility with a wider range of Windows games would be significantly improved.
Increased Performance: The optimized runtime environment provided by UMU-Launcher would lead to smoother and faster gaming performance, minimizing performance overhead typically associated with emulation.
Unified Experience: Users would enjoy a seamless experience running games from various platforms (Steam, Epic Games Store, GOG, etc.) within Bottles, simplifying game management.
This would essentially allow Bottles to run Windows games with a level of compatibility and performance approaching that of native Linux games.

Other solutions?

While other solutions exist for improving Windows game compatibility on Linux, such as using different Wine versions or tweaking configurations, they often require manual intervention and technical expertise. Integrating UMU-Launcher offers a more streamlined and user-friendly solution, automating many of the complexities involved in optimizing game performance.

Additional context and references

UMU-Launcher GitHub repository: https://github.com/Open-Wine-Components/umu-launcher
UMU-Launcher documentation: https://github.com/Open-Wine-Components/umu-launcher/blob/main/README.md

This feature would greatly enhance the Bottles gaming experience, attracting more users to the platform and solidifying its position as a leading solution for Windows gaming on Linux.

Submitted by: Raul Popescu (aka Kong)

@Arcitec
Copy link

Arcitec commented Nov 12, 2024

The creator of Bottles is one of the people who have write access to the UMU organization so I am 100% sure the plan is to add support for it later. I hope it's soon because it's the best way to run games. And Wine-GE has been abandoned for 9 months since Proton-GE with UMU is the new solution.

https://github.com/Open-Wine-Components

https://github.com/GloriousEggroll/wine-ge-custom/releases/tag/GE-Proton8-26

So right now we don't have a good runner for Bottles:

  • Outdated Wine-GE, doesn't work for many of my games.
  • New Proton-GE, but with the bad way of running it which has some stability issues (connects to Steam Linux Runtime, always had glitches with getting it to work).
  • Kron4ek, which is too bleeding-edge, can be very unstable, and is made by a warez admin from RuTracker. Don't like it. (Edit: And dotnet48 does not work inside it, always says that mscoree.dll cannot be found.)

UMU is desperately needed. I look forward to us all using Proton-GE and collaborating with Valve for 1 perfect environment everywhere. :)

@SeongGino
Copy link

SeongGino commented Nov 12, 2024

Honestly the most important part for me is having the fshack and the integrated gstreamer and video fixes integrated--two features that no other available runner seems to provide.

Which is unfortunate! Because Bottles has become my go-to, but the current implementation of Proton support leaves much to be desired, and I've been having to use Lutris in the meanwhile just to keep up-to-date with this forced change in GE updates... which while functional, is nowhere near as polished or friendly or functional as the Bottles experience.

I really, really hope that better Proton support is coming soon. Fingers crossed?

@Arcitec
Copy link

Arcitec commented Nov 16, 2024

@SeongGino Maybe use Heroic Launcher?

  • Settings > Advanced > Experimental > Use UMU as Proton Runtime
  • Download Proton-GE-Latest via the Wine Manager.
  • In Settings > Game Defaults configure it to use Proton-GE-Latest. Do NOT enable "Use Steam Runtime" (that's an old setting which uses Steam's own non-UMU runtime). I also recommend setting your common environments there, like PROTON_HIDE_NVIDIA_GPU=0, PROTON_ENABLE_NVAPI=1, PULSE_LATENCY_MSEC=30. Those are the ones I use. I also enable Fsync and "Auto-update DXVK-NVAPI", and all anticheat runtimes.
  • In Settings > General you choose installation path (where game data is downloaded when installing from stores) and prefix path (where the per-game wine prefixes are created).
  • Now use Library > Add Game, you can then set a Title. A prefix will be created per-title. Now you are playing with UMU and Proton-GE. With nice launcher for Epic and GOG games too. And this launcher makes it very easy to run custom one-time EXEs, install dependencies with the normal winetricks GUI, etc. Just click the game in the library, then look in the submenus for that game.
  • Whenever you install a game or add a custom game, you will see a checkbox for "Use Default Wine Settings". From what I understand, it forces all games to share a single prefix. I NEVER enable it. In fact, if you try to enable it, you will see a warning that sharing prefix between multiple games can lead to dependency conflicts. But it's up to you if you want to. If you enable it, it will use the Wine prefix path from Settings > Game Defaults > Wine > WinePrefix Folder. If you leave it off, it will use per-game prefixes in your normal heroic prefixes location.

@SeongGino
Copy link

@Arcitec I appreciate the thought, but I simply don't like Heroic's design and it's simply not the same workflow at all.

@Arcitec
Copy link

Arcitec commented Nov 17, 2024

@SeongGino I agree that Bottles has a better interface. And I used to dislike Heroic's UI design in the past.

But after getting used to it, it's totally fine, almost as good as Bottles. Even better in some ways. Bottles really wins in three areas: Easier installing dependencies (winetricks is ugly), some settings are easier to toggle via Bottles settings, and Bottles makes it possible to create multiple shared environments (Heroic only supports one shared environment for the games that don't use per-game prefixes).

Of course, I really look forward to Bottles Next:

https://usebottles.com/posts/2023-10-05-bottles-next-a-new-chapter/

That GUI is truly far better than anything from Bottles, Lutris or Heroic right now.

But will take some time to appear in any usable form:

https://www.reddit.com/r/linux_gaming/comments/1fwwlm9/comment/lqyxavp/

Anyway, for Heroic, you really should explore its settings, if you want to use the only UMU-Based launcher right now:

  • It has lots of styles/themes you can switch between.
  • Enable the experimental toggles to enable the new design.
  • Learn a bit and get used to its configuration UI.

image

image

image

@Arcitec
Copy link

Arcitec commented Nov 17, 2024

@mirkobrombin Regarding Bottles, even though you're clearly busy with Bottles Next, I wonder if it would be possible to change this into a dropdown instead?

Steam Runtime

  • Disabled
  • Steam Runtime
  • UMU Launcher

And if UMU is picked, Bottles downloads and auto-updates it internally.

From what I understand, UMU Launcher is pretty much a drop-in replacement for Steam Runtime and is literally based on the same code. I think it has some extra features like "game-fixes game ID detection databases" etc which would require more work, but at least a basic implementation where it runs the games without any game ID detection would be really appreciated.

Would this be feasible?

image


Edit: The situation in Bottles is not good at the moment. Tried to use the normal Steam Runtime to run the latest GE-Proton due to a game that fails in the abandoned Wine-GE-Proton runner. But it's not launching. It's always been problematic for me. Would really love to see UMU support instead. UMU is working so beautifully for me in Heroic already.

@SeongGino
Copy link

@Arcitec Good for you I guess? My original point still stands though, as is my lack of desire to use an alternative that doesn't have the same workflow (as well as a boatload of other problems when not being used as an EGS alternative).

@Arcitec
Copy link

Arcitec commented Nov 18, 2024

UMU support in Bottles would be the optimal solution of course.

@Qronikarz
Copy link
Contributor

The main developer of Bottles is already a part of the UMU and OpenWineComponents. I am sure it is already in works, but it probably won't be soon (maybe even only when Bottles Next drops)
Also, there is a blog post on Bottles blog addressing this issue: https://usebottles.com/posts/2024-09-24-umu-next/

I wonder if it would be possible to change this into a dropdown instead?

Quote from Bottles blog:

Implementing UMU requires more complex design work, as UMU needs to create and manage these bottles (wineprefix), but the architectural challenges don’t stop there. UMU is tightly connected to the Wine components that we define as “legacy” in Bottles—tools that aren’t implemented within Bottles’ architecture. This includes things like DLL overrides, drive management, Windows version control, virtual desktops, fullscreen capture, mouse warp, DPI settings, rendering modes, process management, or even dependency management itself, which is handled by Winetricks in UMU and other platforms. In Bottles, we have a dedicated infrastructure and a custom syntax to simplify and streamline the creation of new dependencies and installers.

Of course, that depends how you interpret it, but to me it seems like it can't be turned into a simple dropdown switch.

@mirkobrombin mirkobrombin pinned this issue Dec 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants