I read エロゲ and haunt AO3. I’ve been learning Japanese for far too long. I like GNOME, KDE, and Sway.
Those instances defederated from lemmy.comfysnug.space. @neo@lemmy.comfysnug.space contacted them and a few others about refederating a few months ago; I don’t know the current status.
Relevant threads:
I also had a pretty terrible experience with Fedora KDE not too long ago. Too many issues to count. In the end, I couldn’t start a Plasma session from the display manager anymore so I gave up.
I really wanted to like Fedora, but…well, Fedora does not seem to like me. My experience on Arch KDE has been great. Like night and day. Still a few small bugs, but annoyances and not showstoppers. My experience with GNOME on Arch has been fantastic. Only one program was broken in GNOME that isn’t in KDE. It makes me wonder why I ever tried to leave…
I don’t have a lot of experience with this, but if you want more logs, you can try upping the WINEDEBUG
debug channel: https://wiki.winehq.org/Debug_Channels
Oh does it not add new entries for every new DXVK release anymore?
Looks like the last time a verb for a new DXVK version was added was dxvk2010
or DXVK 2.1, in February this year. We’re up to DXVK 2.3 now. Because the Winetricks codebase is around 20,000 lines of shellscript and I’m not the best at reading shellscript…I don’t think the dxvk
verb updates the Wineprefix’s DXVK version based on what the newest version is. I think that’s just an alternate way of installing DXVK; you can pull the latest stable release, or you can install a particular version.
I think executing a particular verb for a DXVK version would override whatever DXVK dlls you currently have installed in that prefix, too. I have no idea how to check what DXVK version is installed a particular Wineprefix, though.
even though it says DXVK (Latest) and that it’s from year 2023
That’s based on the verb metadata; not what version of DXVK you currently have installed. A contributor bumped the year for the dxvk
verb from 2017 to 2023 in a commit in February this year.
Oh I had no idea about this, and I normally just use winetrick’s GUI while using it so I would’ve had to look up how to update dxvk if not for you explaining it.
Happy if it helps. I’ve never used the GUI, but it’s awesome that they managed to create a functioning GUI frontend with shellscript. Insane, really. God I hate shellscript…
So far I haven’t had an issue with DXVK being too old, but I mostly play older games
You probably won’t get an issue with DXVK being “too old”, but newer versions of DXVK implement more features (particularly for D3D12) and include bug fixes to improve compatibility or performance. From the 2.3 release notes:
Fixed a minor issue with D3D9 feedback loop tracking.
Test Drive Unlimited 2: Fixed shadows on grass.
Tomb Raider Anniversary: Improved performance.
So you want to be running the latest version for better compatibility. That said, I mostly play visual novels. My biggest problems are still DRM and media playback, which DXVK has very little to do with.
Unrelated but I’ll check that guide out, I’ve had trouble playing VNs that are in Japanese, as without LANG=“ja_JP.UTF-8” wine /path/to/game.exe they won’t even run but even with it the fonts don’t work and are shown as empty boxes.
You’re the exact person this guide was written for! This sounds like an issue that’s easily fixed by installing fakejapanese
with winetricks
. More info here: https://wiki.comfysnug.space/doku.php?id=visualnovel:problems#japanese_characters_aren_t_displaying_properly
And if you have .txt
files in the game directory (like documentation or whatever) with garbled text, that’s probably because they’re encoded in Shift JIS. There’s an easy fix to make them readable: https://wiki.comfysnug.space/doku.php?id=visualnovel:problems#text_files_with_garbled_text
(That last one had me scratching my head for a very long time)
I had some problems with alt tabbing in really old versions of Warcraft 3 (1.27 and older)
Have you tried Gamescope? I experienced similar issues with a lot of older visual novels. Gamescope was the cure-all for windowing issues like this. That said, if WineD3D works better than DXVK for the game, there’s not much reason to look into it.
Reasonably sure, but willing to be corrected. See this section of the Winetricks code (it’s just shellscript):
# Don't install if already installed
if test "${WINETRICKS_FORCE}" != 1 && winetricks_is_installed "$1"; then
echo "$1 already installed, skipping"
return "${TRUE}"
fi
Followed by:
winetricks_is_installed()
{
unset _W_file _W_file_unix
if test "${installed_exe1}"; then
_W_file="${installed_exe1}"
elif test "${installed_file1}"; then
_W_file="${installed_file1}"
else
return "${FALSE}" # not installed
fi
# Test if the verb has been executed before
if ! grep -qw "$1" "${WINEPREFIX}/winetricks.log" 2>/dev/null; then
unset _W_file
return "${FALSE}" # not installed
fi
Winetricks determines whether a verb has been installed by writing and reading to a winetricks.log
file found in the root directory of the Wineprefix you’re working with. It also tests if the file actually exists too, but let’s just focus on winetricks.log
for simplicity.
The first time Winetricks installs the dxvk
verb, which takes the latest DXVK release at the time you run it, it writes dxvk
to the winetricks.log
file. When a new version of DXVK is released, and you run WINEPREFIX=~/.local/share/wineprefixes/whatever winetricks dxvk
, it will hit winetricks_is_installed
and read ~/.local/share/wineprefixes/whatever/winetricks.log
to see if DXVK is already is installed. It will see that dxvk
is in the log file and give up.
When I was writing the Visual Novels on GNU/Linux guide, I did a lot of experimentation with Winetricks. I installed dxvk
in a Wineprefix a few months ago and haven’t touched it since then. A new version of DXVK was released three weeks ago. When executing the dxvk
verb in that Wineprefix again, I get:
Executing w_do_call dxvk
dxvk already installed, skipping
Years ago, Winetricks would write a new verb definition for every new DXVK release. Presumably when it was much less stable. You can see remnants of that with the 100+ verbs for installing particular DXVK versions. Now it just takes the latest stable release. Yay for the maintainers, because that’s a lot less work. As a side effect, Winetricks doesn’t have a way of updating it normally.
Why doesn’t Winetricks have the ability to update verbs? Well, you’re often installing very specific versions of a native DLL to override the builtin Wine component. You don’t want that changing on you randomly. The w_get_github_latest_release
function, which extracts the latest release, was created purely for and only used for DXVK. DXVK is the only component that really works like this in Winetricks.
There is an easy way of updating DXVK anyway. Just run Winetricks with --force
:
WINEPREFIX=~/.local/share/wineprefixes/whatever winetricks --force dxvk
Now, admittedly, I misspoke about Winetricks “not supporting updating DXVK”. I learned this option exists just now. So you can force-update it with --force
, which bypasses winetricks_is_installed
and installs the latest version of DXVK. Guide has been updated accordingly; thank you for making me look into this again!
If you want to play visual novels, you should watch out for games encumbered by DRM.
It’s possible to play non-Steam games without Lutris, Bottles, or Heroic Games Launcher, though it’s a little more annoying. The easiest way to install DXVK in a Wineprefix is using Winetricks. Just run WINEPREFIX=~/.local/share/wineprefixes/name winetricks dxvk
.
The problem is Winetricks doesn’t support updating DXVK. Lutris makes managing DXVK a lot easier; you can turn it on or off and it will update DXVK and other compatibility components automatically.
Vulkan support is of course required for DXVK to work, but DXVK isn’t your only option for Direct3D translation. You can also use Wine’s OpenGL translation layer, WineD3D, which requires no setup. The downside is that WineD3D’s compatibility and performance is generally not as good as DXVK for the same versions of the Direct3D APIs. However, if your GPU doesn’t support Vulkan, then you need to use WineD3D.
On the other hand, if your GPU does support Vulkan, Lutris’ documentation provides a good place to start on installing Vulkan support for your distribution: https://github.com/lutris/docs/blob/master/InstallingDrivers.md
I wrote a guide explaining how the various components of Wine work to make games compatible. That might help you understand what exactly you need to do if you’re not using a Wine manager. And, if you want to make things easier when working in the terminal, you can try these Quick-Access Shell Functions the Winetricks wiki provides.
I keep wanting to buy it because of the amazing sales pitch, except it provides zero value to me. I already use my laptop in bed, lol… and if I’m going outside, I’m not going to be playing games. It doesn’t even make sense to pack for going overseas because my laptop works great for that. And it doesn’t work very well as a new computer because it’s likely far more underpowered than my other computers for video editing and other work I need to do, but is nonetheless a cool feature.
Not that it matters at all. Valve still don’t sell it in my country.
When developers need to draw graphics on the screen, they use an API like Direct3D (or DirectX) or Vulkan to accomplish it. Direct3D only works on Windows. Vulkan works on many operating systems. Vulkan replaced OpenGL.
DXVK translates DirectX calls, which only work on Windows, to Vulkan calls, which will work on Linux and other operating systems. It’s so good at this that it’s better than commercial game engines like Unity. DXVK is a separate project from Wine. Wine also uses wined3d to convert older Direct 3D calls to OpenGL calls, for the same effect.
Lastly, there’s VKD3D, which is Wine’s own Direct3D12 ➜ Vulkan compatibility layer. Valve forked this and created VKD3D-Proton, which is specifically designed for games, as opposed to general software.
Yes, it’s a bit confusing.
I was aware of the Game Porting Toolkit announcement. In fact, I first learned of it from CodeWeavers, who noticed Apple used their code to develop it.
We are ecstatic that Apple chose to use CrossOver’s source code as their emulation solution for the Game Porting Toolkit. We have decades of experience creating ports with Wine, and we are very pleased that Apple is recognizing that Wine is a fantastic solution for running Windows games on macOS. We did not work with Apple on this tool, but we would be delighted to work with any game developers who try out the Game Porting Toolkit and see the massive potential that Wine offers. Our PortJump™ team has perfected the art and science of creating ports of Windows applications using our Wine technology, and we welcome inquiries about how we can help get your game working on macOS.
I don’t play games on macOS, but my understanding was the same as yours; that it was a testing tool for developers to test out how the game might work on macOS. That’s how it was presented. I didn’t think it was meant to be used by macOS users.
In any case, CrossOver is intended to be used by macOS users (and the GPT uses the same code, as enthusiastically explained above), and it has a good graphical interface. I think these factors make it obvious to recommend CrossOver as the canonical solution for playing Windows games on macOS.
macOS has made it difficult for both game developers and Wine developers to support the platform by letting their OpenGL support rot, removing 32-bit support, ignoring Vulkan and coming out with their own graphics API, Metal. Wine is in a worse state than on GNU/Linux. There aren’t many native games available for macOS.
That being said, your best bet is likely CrossOver. They employ the principle Wine developers, worked with Valve on Proton, and have put a lot of effort into supporting macOS. They’ve got a free trial with complete functionality you can try out.
But if the games you’re playing have native releases for macOS, that’s not something you need to worry about. There are just so few games available on macOS that I assumed they don’t. Now, I only have an Intel iMac which I never play games on so I couldn’t tell you how the newer ARM laptops perform.
The Steam and Lutris Runtimes do a good job of ensuring a good experience on most distributions. The only things that can really screw you up are graphics drivers and really low-level dependencies, like glibc. You’re more likely to have issues with Wine, DXVK, and those components than the distribution’s packages.
I use Arch Linux, and there are occasional breakages. However, that’s the sort of thing you expect with Arch. openSUSE and Fedora, from my understanding, are far more rigorous about quality-checking and ensuring a good experience for users. Fedora is not a “true” rolling release distribution as it still has major versions, but openSUSE Tumbleweed is.
I personally don’t think the kind of stability these operating systems are offering makes sense for a desktop. For a server distribution, you absolutely want that kind of stability—mostly because it’s difficult to keep on top of upgrades while balancing downtime and your services requiring certain versions of dependencies. You can bridge the gap between newer releases of software with Flatpak and Snap on stable distributions, for the most part.
Fedora is probably a good compromise between completely rolling and stable. It’s particularly attractive to me for all of the security configurations they’ve made out of the box. One of these days, I’ll switch to Fedora or openSUSE…
I believe many developers have started testing and optimizing their games for Proton
I’ve always been curious as to what this process looks like. If they encounter a crash, unless they have a Wine developer on staff, it isn’t as if they can send a patch for Proton. And then there’s the period of time between Valve commissioning the fix and releasing a new version of Proton. All they can really do is open an issue with Valve, as far as I know. They can certainly make changes for the Steam Deck experience, though.
As others have mentioned, many multiplayer games have anti-cheat, which is more likely not to work in Proton than it is. This area may continue to improve. See http://areweanticheatyet.com
Personally, I play a lot of Japanese visual novels, which usually aren’t released on Steam. Games encumbered with PlayDRM from DLsite will work in Wine, but all games from DMM are encumbered with DRM that doesn’t work in Wine. Wine is a compatibility layer for Windows games that makes them work on GNU/Linux, in case you weren’t aware.
On the other hand, many physical releases of visual novels aren’t encumbered with DRM, so they work fine in Wine. AlphaROM can be worked around by inputting your serial key into the SETTEC website. More information here: https://wiki.comfysnug.space/doku.php?id=visualnovel:problems#drm_and_region_restrictions
Newer games might not be optimized for Linux in the first place
This is usually not true. There aren’t many native GNU/Linux games today; most of them are played using Proton, Steam’s compatibility layer for Windows games. There is no inherent penalty in translating Direct3D calls to Vulkan calls. Vulkan has the potential to be faster than Direct3D, actually. Native games may not be as optimized as the Windows counterpart, but as most of these are small indie games, performance is usually not an issue anyway.
And finally, let’s say I make the switch. What Linux distro should I use?
It’s a good idea to use a rolling release distribution. This is mostly to get the latest drivers; Steam and Lutris both ship a runtime with most of the dependencies you need to play games otherwise, though installing Wine on Ubuntu and Debian is harder, for example. Fedora and openSUSE are good choices. openSUSE in particular has robust graphical tools for package management and other activities which other distributions might force you to use the command line for.
I think a rolling release distribution is a good choice for a general desktop anyway. You’re running the latest software, which means the latest bug fixes and security fixes.
If it doesn’t work in Wine (the only reason I’ve encountered so far is DRM), I just run it in a Windows VM. I play mostly visual novels, so it’s not that much slower. For Anti-Cheat games, I boot into my Windows 10 installation. I still haven’t quite figured out what I’m going to do with that installation come October 2025.