Getting Daikatana running on openSUSE with Wine.

What we started with

Our desktop ran openSUSE Leap 16.0, with KDE on X11 and a 1920 × 1080 display. We had the GOG offline Windows installer, setup_daikatana_1.0_(22142).exe. Despite that installer filename, the installed game was already version 1.2, the base required by the community 1.3 update.

We initially installed it using standalone UMU-Proton. The original 32-bit game reached its menu, but the picture was still 640 × 480 with black bars on the widescreen display. We wanted the Windows GOG game and its Windows patch running on this Linux desktop. The final setup used the distribution’s Wine 10.10, and no Steam client was required.

The examples below collect the final settings into a simpler Wine-only installation layout. Our actual repair reused the game files from the earlier Proton installation; the different game path is shown at the launch step. We verified that repaired installation, rather than rerunning a complete fresh install. Run the shell examples in Bash and adjust installer filenames or game paths to match your copy.

Get Wine and 32-bit compatibility working first

Before troubleshooting the game, we installed Wine from the standard openSUSE repositories. We also had to enable the kernel’s 32-bit x86 support for the compatibility setup we were testing. The Leap 16.0 release notes document the grub2-compat-ia32 package and the required reboot.

sudo zypper install wine wine-gecko grub2-compat-ia32

# Save your work, then reboot to apply the kernel setting.
sudo reboot

After rebooting, we checked the running kernel command line and Wine version:

wine --version
cat /proc/cmdline

# Our results included:
# wine-10.10
# ia32_emulation=1

We then verified that both 32-bit and 64-bit Windows test programs could run. That separated a host compatibility problem from a Daikatana problem. This kernel step records what our Leap 16.0 setup needed; it is not a claim that every Wine build or Linux distribution has the same requirement.

We stayed with Wine 10.10 from the distribution. We inspected a development build during troubleshooting but did not install it or add a development repository.

Give the game its own Wine environment

A Wine prefix is the directory containing an application’s Windows environment, registry and Wine configuration. Our working prefix is ~/.local/share/wineprefixes/daikatana-wine. We kept it separate from the earlier Proton prefix.

For a fresh Wine-only setup, download your GOG offline installer, initialise that prefix and open the installer like this. Choose C:\GOG Games\Daikatana as the destination to match the fresh-install examples below.

dk_prefix="$HOME/.local/share/wineprefixes/daikatana-wine"
dk_installer="$HOME/Downloads/setup_daikatana_1.0_(22142).exe"

mkdir -p "$dk_prefix"
WINEPREFIX="$dk_prefix" WINEARCH=win64 \
WINEDLLOVERRIDES="winemenubuilder.exe=d;mscoree,mshtml=" \
wineboot -u

WINEPREFIX="$dk_prefix" \
WINEDLLOVERRIDES="winemenubuilder.exe=d;mscoree,mshtml=" \
wine "$dk_installer"

WINEARCH=win64 selects a 64-bit prefix when it is first created. The DLL overrides suppress Wine’s automatic menu entries and its .NET/HTML components, which we did not need for this game. We supplied our own applications-menu entry after testing.

In our repair, the GOG files were already installed. We created the separate Wine prefix and pointed Wine at those existing files. We preserved the original Proton prefix, rather than running both compatibility tools against the same prefix.

Use the Windows 64-bit community patch

The community Daikatana 1.3 project adds widescreen support and a Windows 64-bit executable, among many other changes. Our tested build was 21 December 2025, using DK_EXE_122125_SLIM_x64.EXE from the maintainer’s release page. Download that Windows x64 SLIM installer to reproduce this version; it updates an existing game installation.

Close the game and back it up before patching. Our original backup included the whole game directory, launcher and prefix registry. This example preserves the game files, including any settings and saves stored inside them:

dk_game="$HOME/.local/share/wineprefixes/daikatana-wine/drive_c/GOG Games/Daikatana"
dk_backup="$HOME/.local/state/daikatana/backups/before-patch-$(date +%Y%m%d-%H%M%S)"

mkdir -p "$dk_backup"
cp -a "$dk_game" "$dk_backup/Daikatana"

We verified the downloaded x64 installer against its release asset’s SHA-256 digest. For the exact file above, this checks the hash and only opens the installer if it matches:

dk_patch="$HOME/Downloads/DK_EXE_122125_SLIM_x64.EXE"
dk_prefix="$HOME/.local/share/wineprefixes/daikatana-wine"

(
  printf '%s  %s\n' \
    '6149cc5ce11df93d75b60f1d007cebea3f524ae32f1e507622b173f94bbc5d1b' \
    "$dk_patch" | sha256sum --check - || exit 1

  WINEPREFIX="$dk_prefix" \
  WINEDLLOVERRIDES="winemenubuilder.exe=d;mscoree,mshtml=" \
  wine "$dk_patch"
)

Select the installed Daikatana directory in the patch installer. In the fresh Wine layout that is C:\GOG Games\Daikatana. Our original patch installation happened under Proton before the Wine repair; the example above opens the same Windows installer in the Wine-only layout.

We first tried the Windows 32-bit 1.3 patch. It enabled widescreen, but under our Proton setup the menu became a blurred, enlarged fragment after about a second. Installing the Win64 build resolved that menu corruption. That was progress, but we still needed to test the game beyond the menu.

The black screen needed a fresh configuration

With the Win64 patch under Proton, starting a game could produce a black screen while dialogue continued. Alternate renderer and timing settings did not produce a usable result on this machine. Moving the same patched executable into a fresh Wine environment while retaining the inherited game configuration also failed to give us a working setup.

The successful test used Wine 10.10 with a regenerated data/current.cfg, while retaining our small widescreen autoexec.cfg. We backed up the old configuration and both save directories before moving current.cfg aside, allowing the patched game to recreate its defaults on the next launch.

dk_game="$HOME/.local/share/wineprefixes/daikatana-wine/drive_c/GOG Games/Daikatana"
dk_backup="$HOME/.local/state/daikatana/backups/before-config-reset-$(date +%Y%m%d-%H%M%S)"

(
  cd "$dk_game/data" || exit 1
  mkdir -p "$dk_backup" || exit 1
  for item in current.cfg autoexec.cfg save save_x64; do
    if [ -e "$item" ]; then
      cp -a "$item" "$dk_backup/" || exit 1
    fi
  done
  if [ -f current.cfg ]; then
    mv current.cfg "$dk_backup/current.cfg.original" || exit 1
  fi
  touch portable.cfg
)

The empty data/portable.cfg tells the patch to keep settings and saves in the game’s data directory. If your installation previously used Documents/My Games, preserve those files as well before switching to portable mode. Our installation already used portable mode.

Keep the widescreen settings small and explicit

We kept the following in data/autoexec.cfg. For a new installation, create that text file; for an existing one, back it up and merge these settings with any bindings you want to keep.

// Use the patch's custom display mode.
set r_mode "0"
set r_customwidth "1920"
set r_customheight "1080"
set vid_fullscreen "1"

// Apply future game updates deliberately.
set cl_autoupdate "0"

r_mode 0 selects the patch’s custom resolution, with width and height set separately. These values matched our 1920 × 1080 monitor and gave us fullscreen without black side bars. Choose dimensions suitable for your own display.

cl_autoupdate 0 disables the game’s automatic update checks. We wanted to keep the verified build in place and apply future patches deliberately. It is a maintenance choice, not an established fix for the black screen.

The working Wine invocation

Start Wine in the game directory, using the dedicated prefix and the patched Windows executable. This version uses the fresh-install layout from the earlier examples:

(
  dk_prefix="$HOME/.local/share/wineprefixes/daikatana-wine"
  dk_game="$dk_prefix/drive_c/GOG Games/Daikatana"

  cd "$dk_game" || exit 1
  WINEPREFIX="$dk_prefix" \
  WINEDEBUG=-all \
  WINEDLLOVERRIDES="winemenubuilder.exe=d;mscoree,mshtml=" \
  /usr/bin/wine "$dk_game/daikatana.exe"
)

Our actual working game files remained under the original installation directory. To match that repaired layout, replace the dk_game assignment above with:

dk_game="$HOME/.local/share/wineprefixes/daikatana/drive_c/GOG Games/Daikatana"

Keep dk_prefix pointing to daikatana-wine. The executable’s storage directory and Wine’s prefix do not have to be the same directory. This let us retain the original game data and saves while using a separate Wine environment.

WINEDEBUG=-all quiets Wine’s diagnostic output. We removed temporary renderer experiments and logging flags from the final launch. The successful run loaded the intro and first map, and exited normally when we closed it.

Make the working setup easy to launch again

We put the working invocation in ~/.local/bin/daikatana and pointed the applications-menu entry at it. Create ~/.local/bin if needed, then save this script there, selecting the appropriate dk_game path:

#!/bin/sh
export WINEPREFIX="$HOME/.local/share/wineprefixes/daikatana-wine"
export WINEDEBUG="${WINEDEBUG:--all}"
export WINEDLLOVERRIDES="winemenubuilder.exe=d;mscoree,mshtml="

# Fresh Wine-only layout; use the retained game path above for our repair.
dk_game="$WINEPREFIX/drive_c/GOG Games/Daikatana"
dk_state="$HOME/.local/state/daikatana"
mkdir -p "$dk_state" || exit 1

exec 9>"$dk_state/launch.lock"
if ! /usr/bin/flock -n 9; then
  if command -v wmctrl >/dev/null 2>&1; then
    wmctrl -a "Daikatana 1.3beta Win64" 2>/dev/null || true
  fi
  exit 0
fi

if [ -f "$dk_state/startup.log" ]; then
  cp "$dk_state/startup.log" "$dk_state/startup-previous.log"
fi

cd "$dk_game" || exit 1
# Keep the shell alive so it retains the lock while Wine runs.
/usr/bin/wine "$dk_game/daikatana.exe" "$@" \
  >"$dk_state/startup.log" 2>&1
dk_result=$?
exit "$dk_result"

The flock lock prevents repeated clicks on this launcher from starting duplicate copies. Keeping the shell alive around Wine retains that lock. On our KDE/X11 desktop, wmctrl also brings the existing game window forward; the script skips that convenience if the command is unavailable.

We verified that the lock stayed held during play and that a second launch did not create another game window or overwrite the active log. Cold Wine startup could still take roughly 30 seconds, so a slow first launch was a reason to wait and inspect the log before clicking again.

The launcher keeps the latest output in ~/.local/state/daikatana/startup.log and copies the preceding run to startup-previous.log. Once saved, make it executable and add the menu entry:

chmod +x "$HOME/.local/bin/daikatana"
mkdir -p "$HOME/.local/share/applications"

cat > "$HOME/.local/share/applications/daikatana.desktop" <<EOF
[Desktop Entry]
Type=Application
Name=Daikatana
Comment=Play the GOG edition of Daikatana
Exec="$HOME/.local/bin/daikatana"
TryExec=$HOME/.local/bin/daikatana
Icon=applications-games
Terminal=false
Categories=Game;ActionGame;
StartupNotify=false
StartupWMClass=daikatana.exe
EOF

This example uses a generic Games icon. Our final shortcut uses the packaged GOG icon, and we validated the desktop entry and refreshed KDE’s menu cache. StartupWMClass=daikatana.exe matches the window class observed under Wine.

What we verified

We checked the result through the final applications-menu shortcut as well as the direct Wine launch:

• The Win64 menu rendered correctly at 1920 × 1080 fullscreen.
• Both opening cinematics played before the first level.
• The first playable map loaded and we could move around.
• The tested game run closed normally.
• Repeated launcher clicks kept a single instance running.

We preserved the previous launcher, settings, saves and Proton environment. We have not established full-campaign stability, multiplayer behaviour or save compatibility across future patch versions.

The useful lesson was to test each milestone separately. The Win64 patch fixed our visible menu problem; the fresh Wine environment and regenerated settings were the combination that got us into the game. Recording the versions, paths and launch settings made that result something we could repeat from the desktop.

What we learned

What we, I, learned from this is that Wine sucks, sorry not sorry, we need another project, like Raven (https://github.com/mirkobrombin/raven) to implement Windows on Linux transparently. The problem is that for a regular user, someone who doesn't work in IT, this level of configuration is basically impossible. I go into more detail on this in the LinuxToGo project, but the basic summary of this is that effectively it doesn't work. This level of configuration is bascially a party trick.