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

SDK Chan

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 ?
 
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.
 
-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 :)
 
SDK Chan said:
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 ?
Click to expand...
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.
 
You mean the umu project, right ?

Space Banana said:
If you require DXVK for better graphical performance or fsync/esync for better CPU performance, I recommend the Wine forks.
Click to expand...
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 ?

Space Banana said:
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.
Click to expand...
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) ?
 
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.
 
SDK Chan said:
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) ?
Click to expand...
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 said:
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.
Click to expand...
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
 
Space Banana said:
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.
Click to expand...
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 ?
 
SDK Chan said:
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 ?
Click to expand...
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.
 
Space Banana said:
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.
Click to expand...
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.
 
SDK Chan said:
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.
Click to expand...
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.
 
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. ;)
 
thindil said:
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.
Click to expand...
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.
 
SDK Chan said:
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.
Click to expand...
Thank you. Yes, it isn't abandoned. I'm using it mostly to test a new versions of wine-proton before I submit a patch. ;)
It may lag behind a bit with FreeBSD versions (it depends on availability of FreeBSD in GitHub Actions), but generally it is alive. Also, it will need a rewrite when FreeBSD 15 arrive, due to drop 32-bit support. Plus this will drop support for older versions of Wine. :rolleyes:
 
thindil said:
Thank you. Yes, it isn't abandoned. I'm using it mostly to test a new versions of wine-proton before I submit a patch. ;)
It may lag behind a bit with FreeBSD versions (it depends on availability of FreeBSD in GitHub Actions), but generally it is alive. Also, it will need a rewrite when FreeBSD 15 arrive, due to drop 32-bit support. Plus this will drop support for older versions of Wine. :rolleyes:
Click to expand...
FreeBSD 15 will drop 32-bit support or can it be still enabled through kernel config files ?
If FreeBSD will drop 32-bit support, how is wine going to continue to work on FreeBSD as it uses a multilib approach even for 64-bit games ? :-/

EDIT:
I found this interesting statement regarding 32-bit and the future of FreeBSD.
According to this quote:
FreeBSD is deprecating 32-bit platforms over the next couple of major
releases. We anticipate FreeBSD 15.0 will not include the armv6,
i386, and powerpc platforms, and FreeBSD 16.0 will not include armv7.
Support for executing 32-bit binaries on 64-bit kernels will be
retained through at least the lifetime of the stable/16 branch if not
longer. (There is currently no plan to remove support for 32-bit
binaries on 64-bit kernels.)
Click to expand...

Well, atleast some kind of mulitlib behaviour will continue on FreeBSD.
I know that unlike Linux, FreeBSD does not have multilib capabilities.
All the wine versions listed on your github page support 64-bit mode, I think.
 
1. FreeBSD will still support 32-bit executables, just the project will not deliver 32-bit version of the system in sense of 32-bit packages, image, etc.
2. Wine on FreeBSD uses the 32-bit version of the system to provide 32-bit libraries needed to run 32-bit Windows executables. The second step in installing Wine on FreeBSD is just downloading needed packages from 32-bit version of the system. This will stop working with FreeBSD 15, there will be no 32-bit packages available.
3. Wine itself can be build in multi-arch mode. It is a quite new feature in Wine (it appeared incomplete in Wine 8.0?, if I remember correctly), that's why it isn't enabled in FreeBSD. I plan to experiment a bit with this feature with the next version of wine-proton (10.0), so we can start testing, do it works on FreeBSD or not. This will require a lot of changes how Wine is maintained on FreeBSD. Fortunately, it should make installing and maintenance of Wine a lot easier. Additionally, wine-proton-ge and older versions of Wine doesn't have that feature, thus they won't be available in FreeBSD 15 and later. Sure, we can add multi-arch libraries to the system, like Linux doing it, but I think, the option with multi-arch in Wine will require a lot less work.

I hope I clarified my previous post a bit. ;)
 
Eventually it is a dumb question, but I am still curious.
Assuming I am on an AMD64 version of FreeBSD.
If I am using wine regardless the executable (32-bit, 64-bit) I want to execute, wine looks up the /usr/lib32 for shared libs, right ?

thindil said:
2. Wine on FreeBSD uses the 32-bit version of the system to provide 32-bit libraries needed to run 32-bit Windows executables. The second step in installing Wine on FreeBSD is just downloading needed packages from 32-bit version of the system. This will stop working with FreeBSD 15, there will be no 32-bit packages available.
Click to expand...
But wine also provides 32-bit libraries for some 64-bit applications, right ?
Some time there was wine-32, and wine-64, I assume.
But wine-32 got removed already from fresh ports ?
And now you have "wine" which calls either wine-64 or wine-32, I think.
On linux I always used "wine" to execute 32-bit, and 64-bit executables.
On FreeBSD, if I build/install wine, I get both 64-, and 32-bit shared libraries ?
So, I also get wine-64, and wine-32 which both can be called through wine ?

thindil said:
3. Wine itself can be build in multi-arch mode. It is a quite new feature in Wine (it appeared incomplete in Wine 8.0?, if I remember correctly), that's why it isn't enabled in FreeBSD. I plan to experiment a bit with this feature with the next version of wine-proton (10.0), so we can start testing, do it works on FreeBSD or not. This will require a lot of changes how Wine is maintained on FreeBSD. Fortunately, it should make installing and maintenance of Wine a lot easier.
Click to expand...
I think the part I described above is multi-arch-mode ? :-/
Either way 64 bit is just an extension of the 32 bit address space, I think.
This week I also want to install, and test wine out on FreeBSD.
If all goes well, I am going to consider to contribute to the FreeBSD wine port since games run a lot better than on Windows/Linux according to some videos on youtube, but I can tell more after testing.
Given the game in question works, though....
 
fff2024g said:
please add torchlight 2 to play with freebsd14.2 . i want to play it same. but don't find a good way to go..
Click to expand...

This looks like it'd work for the Windows GOG version in Wine (everything as normal user except pkg install):

Code: 
pkg install wine-devel wine-gecko-devel wine-mono-devel winetricks

Code: 
'/usr/local/share/wine/pkg32.sh' install wine-devel mesa-dri gstreamer1-plugins-good gstreamer1-plugins-ugly gstreamer1-libav libressl

Code: 
mkdir -p ~/'.wine' && WINEPREFIX=~/'.wine/Torchlight II' WINEARCH='win32' WINEDLLOVERRIDES='winemenubuilder.exe=d' wine ~/'Downloads/setup_torchlight_2_1.25.9.5b_(23102).exe'

Code: 
cd ~/'.wine/Torchlight II/drive_c/GOG Games/Torchlight 2' && WINEPREFIX=~/'.wine/Torchlight II' wine ~/'.wine/Torchlight II/drive_c/GOG Games/Torchlight 2/Torchlight2.exe'
 
SDK Chan said:
Assuming I am on an AMD64 version of FreeBSD.
If I am using wine regardless the executable (32-bit, 64-bit) I want to execute, wine looks up the /usr/lib32 for shared libs, right ?
Click to expand...
I'm not sniffing emulators/wine for quite a long time, so I could be wrong (based on basic knowledges in Makefile and ports framework), but...

Looking into pkg--plist of emulators/wine, there seems to be bin/wine and %%WINE64%%bin/wine64 (both should be installed under /usr/local/ by default).

(%%WINE64%% is expanded as nothing when built on amd64, thus, interpreted as bin/wine64 and expanded to make it a comment when built on i386, thus, ignored.)

So my assumption is that at least bin/wine requires libraries under /usr/lib32 and possibly bin/wine64, too, if somehow calls 32 bit windows dlls via its (if any) compat thunk layer (WoW32? not sure).

Maybe comments of the block starting from line 132 through 153 in emulators/wine/Makefile helps understanding a bit.

SDK Chan said:
But wine also provides 32-bit libraries for some 64-bit applications, right ?
Click to expand...
emulators/wine itself seems to contain 32bit shared objects like ws2_32.so and 32bit dlls like gdi32.dll.

SDK Chan said:
Some time there was wine-32, and wine-64, I assume.
But wine-32 got removed already from fresh ports ?
Click to expand...
My assumption is that bin/wine is 32 bit version (maybe same as %%WINE32%%bin/wine.bin, unless it's a script to initialize and call actual binary).

And if you really aware of the time 32bit binaries support on 64bit archs (like /usr/lib32 and corresponding kernel supports), you'd better monitoring changes to /usr/src/share/mk/src.opts.mk on main (aka -Current) branch, especially lines like below.

Makefile: 
# LIB32 is not supported on all 64-bit architectures.
.if (${__T:Maarch64*} != "" && ((defined(X_COMPILER_TYPE) && ${X_COMPILER_TYPE} != "gcc") || (!defined(X_COMPILER_TYPE) && ${COMPILER_TYPE} != "gcc"))) || ${__T} == "amd64" || ${__T} == "powerpc64"
__DEFAULT_YES_OPTIONS+=LIB32
.else
BROKEN_OPTIONS+=LIB32
.endif

Once 32bit compat libraries are dropped to be built by default, __DEFAULT_YES_OPTIONS+=LIB32 above would flip to __DEFAULT_NO_OPTIONS+=LIB32 to make things clear (hopefully).

And existence of tools/build/options/WITH_LIB32. If 32bit compat libraries supports are actually deleted from source codes, this file is no longer needed.

If this still remains, there can be a hope you can build FreeBSD from source locally with this option enabled by adding WITH_LIB32=yes in your /etc/src.conf.
 
The point of wine-proton is not performance and not compatibility, the port was added in support of linux-steam-utils and that's how it's supposed to be used. (The Linux Steam client is unable to work with vanilla Wine owing to the way the integration bits are implemented, that's all there is to it.)

thindil said:
multi-arch
Click to expand...
"mutiarch" is the name of Debian's brain-dead multilib implementation, that term has no relevance to Wine.

T-Aoki said:
emulators/wine itself seems to contain 32bit shared objects like ws2_32.so and 32bit dlls like gdi32.dll.
Click to expand...
Is the path lib/wine/x86_64-unix/ws2_32.so not enough of a clue?
 
You must log in or register to reply here.
Back
Top