Note

这篇文章主要还是以archlinux为主，当然其余发行版本质上也就是软件包不同，其余的还是没区别的。

安装

首先，绝大部分的GALGAME其实只需要安装wine然后改一下LOCALE就能直接跑了，特别是如果你的游戏是在Steam上买的，那就更简单了，直接在steam里用proton启动就行了，这里针对的主要是一些老游戏，steam不支持，直接运行会出现一些奇奇怪怪的错误。

在写这篇文章之前，稍微调查了一下，发现有个挺好用的AIO启动工具叫bottles，稍微试用了一下，感觉还不错，帮你把所有东西都装好了。

wine与proton

说实话Proton的出现其实对GALGAME的兼容问题没有带来多大的改善，用wine运行不了的游戏，换成proton大多也不能运行。针对那些上了年代的GALGAME，准确地说是上了年代的引擎，proton确实也是无能为力，毕竟有些GAL到现在还还依赖着一堆奇怪的第三方库。

但怎么说呢，确实有时候换成proton又能成功运行了，所以还是把proton作为备用方案吧。

安装wine很简单：

sudo pacman -S --needed wine wine-gecko wine-mono winetricks

至于proton，推荐用archlinuxcn源安装，按照官方文档操作添加仓库，然后：

sudo pacman -S proton

proton安装完成后默认是启动不了的，它的执行文件在/usr/share/steam/compatibilitytools.d/proton/proton，但就算你把它添加到PATH再运行也是无法运行的。它需要一些环境变量：

STEAM_COMPAT_DATA_PATH: proton的prefix的存储位置：默认为 $HOME/.local/share/Steam/steamapps/compatdata/<GAME_ID>，当然非steam游戏自然没有对应的ID，随便填一个0即可，或者换个位置也行。
STEAM_COMPAT_CLIENT_INSTALL_PATH：应该是没啥用的，填steam的安装位置即可，默认为 $HOME/.local/share/Steam

然后就可以运行了：

proton run <path/to/game.exe>

如果觉得每次都写环境变量比较麻烦的话，也可以改一下proton的启动脚本，下面是我自己用的启动脚本。

#!/bin/python
import os
import sys

os.environ["STEAM_COMPAT_DATA_PATH"] = os.path.expanduser(
    "~/.local/share/Steam/steamapps/compatdata/0"
)
os.environ["STEAM_COMPAT_CLIENT_INSTALL_PATH"] = os.path.expanduser(
    "~/.local/share/Steam"
)
env_ = os.environ.copy()
proton_exe = "/usr/share/steam/compatibilitytools.d/proton/proton"
sys.path.append(os.path.dirname(proton_exe))

sys.argv[0] = proton_exe
with open(proton_exe, "r") as f:
    exec(f.read())

运行

LOCALE

参考archwiki，编辑 /etc/locale.gen，再执行 locale-gen 即可。运行汉化版和日文原版（或者有的老汉化仍然需要以日文环境启动），分别需要设置zh_CN.UTF-8与ja_JP.UTF-8。

WINE的话用 LC_ALL 这个环境变量一般来说兼容性更好，对于 proton，在我的环境下用这个环境变量会报错，只能用 LANG

依赖库

绝大部分GAL都是32位的程序，而它们播放音视频的时候往往会依赖32位的 gstreamer 及其各种插件，但大部分发行版默认都是不维护这些32位的插件的，在archlinux中，它们在AUR上有人维护，但更新非常不及时，而且build脚本非常不稳定，因此建议一旦确定版本后，如无必要，不要更新它们（但好像一直不更新也不是个办法）。

yay -S --needed               \
  gst-libav                   \
  gst-plugins-bad             \
  gst-plugins-bad-libs        \
  gst-plugins-base            \
  gst-plugins-base-libs       \
  gst-plugins-good            \
  gst-plugins-ugly            \
  gstreamer                   \
  lib32-gst-libav             \
  lib32-gst-plugins-bad       \
  lib32-gst-plugins-bad-libs  \
  lib32-gst-plugins-base      \
  lib32-gst-plugins-base-libs \
  lib32-gst-plugins-good      \
  lib32-gst-plugins-ugly      \
  lib32-gstreamer             \

Note

值得一提的是，如果觉得安装这些32位的依赖过于繁琐，也可以考虑AUR上的 wine-wow64 包，它不依赖于32位库，目前使用下来没有发现明显的兼容性问题。

环境配置

对于GALGAME来说，DXVK之类的高性能DX库并没有什么实质性的帮助，WINED3D的兼容性还是要好很多的。但安装一下也是可以的，也确实有些游戏开了DXVK就莫名能运行了。

winetricks -q wmp9 dxvk

这两个基本上可以无脑装，但winetricks里一些其他的库装之前还是要慎重。

native 与 builtin

首先要明确的是，WINE这个项目其实就是把所有Windows上的库在Linux上都实现了一遍，在Windows程序需要用到某个库的时候，使用Linux原生的库进行执行，你可以在/usr/lib/wine目录下看到这些wine重新实现了的库。但这并不意味着windows原生的DLL文件它就不能执行了，毕竟说到底也只是同样的x86机器码而已。只是直接转译运行一个windows下的组件，特别是较为底层的组件，确实可能会产生很多未知的错误。

因此，我们可以通过 WINEDLLOVERRIDES 这个环境变量，来临时告诉wine，哪个文件用wine内置的(builtin)，哪个用系统或本地的(native) 当然你也可以进行永久的修改，使用 winecfg 来进行图形化配置，或者找到你的 $WINEPREFIX/user.reg 中的 [Software\\Wine\\DllOverrides] 进行修改。例如使用winetricks安装dxvk时，它会默认使用dxvk的dll，而不是内置的wined3d，因此我们可以通过这样的配置，来强制wine使用builtin的库：

WINEDLLOVERRIDES="*d3d9,*d3d10,*d3d10_1,*d3d10core,*d3d11,*dxgi=b" wine <path/to/game.exe>

DE相关

结论上来说，如果想要更好的兼容性，最好是用一个x11的非平铺式窗口管理器。如果你不听劝想要用一个wayland下的平铺式桌面环境，那只能说前方是地狱啊，别问我为什么知道。

另外wine是支持运行在原生wayland下的，但这个wayland的实验性驱动只能说兼容性堪忧，但有的游戏开了却能正常运行，所以还是提一嘴，具体参考archwiki

UPDATE: 2024-11-26 目前 wine 9.22 版本已经将wayland作为默认选项了，只需要加一个DISPLAY=就可以运行在wayland下了，但兼容性确实还是不如X11，我的意见是再观望一下。

特别的，对于Wayland下的平铺式桌面管理器，有的GALGAME在windows下都会有缩放和拉伸的问题，更别说是会强制拉伸的平铺式桌面管理器，和将窗口拉伸与全屏的权限交给了用户的wayland了。一个可行的解决方案是合成器套娃，wayland是支持将一个合成器作为另一个合成器的窗口运行的，比如 cage，这个还是会有些奇怪的问题，比如在我的Hyprland下，它好像不能对齐鼠标位置；更推荐的还是valve自家为steamOS研发的合成器gamescope，出了问题可以试试改改--backend参数，在我的环境下设置成sdl比较稳定。

最后修改于 2024-11-26