Should I use Wine, Wine-Proton or Wine-Proton-GE ?

[SDK Chan]

I am planning to move my game collection from Linux over to FreeBSD.
As far as I know FreeBSD currently has Wine, and Wine-Proton available.

The games I attempt to play are:
-> Kingdom Hearts collection
-> Nier Replicant/Automata
-> Resident Evil + Remakes
-> Alice Madness Returns
-> Final Fantasy 15 and 16

Did someone succeed porting Glorious Eggrolls patches over to Wine or Wine-Proton ?
DXVK seems to work, but how is the state of VKD3D for directx 12 ?

 

[jardows]

Most everything I play is much older, but I have far more success in games "just working" with wine-proton than with standard wine. I can't say anything about -GE, as I've never heard of it before.

 

[SDK Chan]

-GE are additional patches which allow broader compatibility with games (newer games) while maintaining the compatibility to older games.
Wine itself often breaks between updates so, if you want to play game X chances could be low to play game X again after wine updates.
Wine-GE tries to avoid that.
The best experience I could make was with Wine-GE, but that was back then on linux, but on FreeBSD I am going to try Wine-Proton first, then

 

[Space Banana]

I am planning to move my game collection from Linux over to FreeBSD.
As far as I know FreeBSD currently has Wine, and Wine-Proton available.

The games I attempt to play are:
-> Kingdom Hearts collection
-> Nier Replicant/Automata
-> Resident Evil + Remakes
-> Alice Madness Returns
-> Final Fantasy 15 and 16

Did someone succeed porting Glorious Eggrolls patches over to Wine or Wine-Proton ?
DXVK seems to work, but how is the state of VKD3D for directx 12 ?

Proton, Wine-GE and Proton-GE have a few things out of the box:

• DXVK support (though might require manual setup on your wine prefix)
• Fshack (makes fullscreen behave like borderless) (still bypasses compositor and vsync I think, depends on DE)
• Esync and Fsync (CPU performance improvements)

If you require DXVK for better graphical performance or fsync/esync for better CPU performance, I recommend the Wine forks. If you want/need fshack or you require a patch that is present in Proton that's another reason to want them. If you don't require any of this then vanilla Wine does the job very well.
Though note that wine-ge is no longer maintained, all efforts shifted fully to proton-ge which requires an emulation/setup/whatever of the Steam runtime or something like that. This applies to Linux, idk if the wine-proton package on FreeBSD requires any Steam runtime setup.

 

[SDK Chan]

You mean the umu project, right ?

If you require DXVK for better graphical performance or fsync/esync for better CPU performance, I recommend the Wine forks.

I require DXVK, VKD3D mostly for Vulkan support, and asynchronous shader compiling as OpenGL has mostly broken graphics in many games.
I thought that FreeBSD only has vanilla Wine, and Wine-Proton, or are there any forks outside of fresh ports which are compatible with FreeBSD ?

Though note that wine-ge is no longer maintained, all efforts shifted fully to proton-ge which requires an emulation/setup/whatever of the Steam runtime or something like that.

Yes, wine-ge is no more, but aren't the patches not mostly the same ?
I mean proton-ge is a heavy modified wine version, but if you just pull out the relevant patches, and put them into wine, or wine-proton, won't you have something like wine + proton patches + ge patches (wine-proton-ge) ?

 

[Space Banana]

I forgot to add that wine-staging (or wine-devel) has better audio resampling. When playing audio files that have low sample rates, they will sound crisp instead of muffled and slightly crackled. Once this patch is added to Proton and all the wine forks out there, the usecase for running something like Lutris or Bottles will be significantly diminished, which is what I'm aiming for because these 2 programs are a mess both because of Flatpak and because of the developers' own ideology and decisions.

 

[Space Banana]

You mean the umu project, right ?


I require DXVK, VKD3D mostly for Vulkan support, and asynchronous shader compiling as OpenGL has mostly broken graphics in many games.
I thought that FreeBSD only has vanilla Wine, and Wine-Proton, or are there any forks outside of fresh ports which are compatible with FreeBSD ?


Yes, wine-ge is no more, but aren't the patches not mostly the same ?
I mean proton is a heavy modified wine version, but if you just pull out the relevant patches, and put them into wine, or wine-proton, won't you have something like wine + proton patches + ge patches (wine-proton-ge) ?

I heard about umu but never tried it, though I know that proton-ge existed before umu and using it outside Steam was "unsupported". Either way you most likely only have wine, wine-devel and wine-proton on FreeBSD, I never heard of anything else other than wine helpers and launchers.

 

[Space Banana]

I heard about umu but never tried it, though I know that proton-ge existed before umu and using it outside Steam was "unsupported". Either way you most likely only have wine, wine-devel and wine-proton on FreeBSD, I never heard of anything else other than wine helpers and launchers.

The craziest thing is how Glorious Eggroll (I think that's his name) uses a Discord server for issues instead of Github issues. That's pure insanity

 

[SDK Chan]

I forgot to add that wine-staging (or wine-devel) has better audio resampling. When playing audio files that have low sample rates, they will sound crisp instead of muffled and slightly crackled. Once this patch is added to Proton and all the wine forks out there, the usecase for running something like Lutris or Bottles will be significantly diminished, which is what I'm aiming for because these 2 programs are a mess both because of Flatpak and because of the developers' own ideology and decisions.

Isn't the audio resampling not system dependent ?
As far as I know you can use OSS directly with wine through faudio, I think.
Maybe the audio resampling part can be down-patched to the current wine versions ?

 

[Space Banana]

Isn't the audio resampling not system dependent ?
As far as I know you can use OSS directly with wine through faudio, I think.
Maybe the audio resampling part can be down-patched to the current wine versions ?

I know that this audio issue happens on both Pulseaudio and Pipewire when using wine, but it's fixed on wine-staging, lutris-wine and wine-ge. Outside wine, it's program-dependant how audio is resampled. On FreeBSD's OSS I have no idea, I wanted to give a try to FreeBSD gaming on bare metal but the iGPU on that machine is badly supported it seems.

 

[SDK Chan]

I know that this audio issue happens on both Pulseaudio and Pipewire when using wine, but it's fixed on wine-staging, lutris-wine and wine-ge. Outside wine, it's program-dependant how audio is resampled.

I always used wine with pure alsa, because Pulseaudio gave me underruns, and audio crackling.
Switching last year to Pipewire solved everything, I also cannot remember any sound problems due to resampling.

It is sad that not many videos showing FreeBSDs gaming performance with wine are out there, and the most don't really show popular games.
I know that one user on the forums does youtube videos from time to time.

 

[Space Banana]

I always used wine with pure alsa, because Pulseaudio gave me underruns, and audio crackling.
Switching last year to Pipewire solved everything, I also cannot remember any sound problems due to resampling.

It is sad that not many videos showing FreeBSDs gaming performance with wine are out there, and the most don't really show popular games.
I know that one user on the forums does youtube videos from time to time.

I still have audio crackling on Pipewire but only when I'm using too much CPU with multitasking (for example screen sharing and gaming). This can be fixed on both Pipewire and Pulseaudio by increasing the min, normal and max audio latency levels (quantum size iirc). I think wine uses the minimum level while most applications use the normal level, and browsers use the maximum quantum size I believe.

 

[thindil]

I had some successes with porting wine-proton-ge to FreeBSD, but only older versions. If you want to check, you can look here: https://github.com/thindil/wine-freesbie. Now I mostly use wine-proton. It has some FreeBSD specific patches too. Plus, by default it uses PulseAudio, which works a lot better (at least, for me) on FreeBSD than OSS or alsa. And it has a mainainer.

In FreeBSD repositories, you can also find wine-devel for development versions of Wine. But for now, there is no wine staging support.

Fsync/esync is a pure Linux concept, it doesn't work on FreeBSD.

 

[SDK Chan]

I had some successes with porting wine-proton-ge to FreeBSD, but only older versions. If you want to check, you can look here: https://github.com/thindil/wine-freesbie. Now I mostly use wine-proton. It has some FreeBSD specific patches too. Plus, by default it uses PulseAudio, which works a lot better (at least, for me) on FreeBSD than OSS or alsa. And it has a mainainer.

Yes, wine-freesbie is a good wine-version switcher
That is actually exactly what I was looking for in case version x of wine-proton does not work, and I am glad that the project is not abandoned.