Packaging an old game, Savage 2

1

Hi there!

I’m trying to package Savage 2, a 2008 linux game, in flatpak. The objective is to be able to run it everywhere, in particular on a steam deck. And I’m very new to flatpak.

I wrote a manifest that works on debian 12 and on gentoo, see below. But the game does not start on a steam deck, and I struggle to understand how to debug it.

I don’t see an easy way to rebuild the game from source, so I have to use the binary from savage2.net. The manifest is pretty straightforward:

id: net.savage2.game
runtime: org.freedesktop.Platform
runtime-version: '24.08'
sdk: org.freedesktop.Sdk
command: savage2

modules:
  - name: ncurses
    config-opts:
      - --with-shared
      - --without-manpageus
      - --with-abi-version=5
    cleanup:
      - /bin
      - /include
      - /share
      - "*.a"
    sources:
      - type: archive
        url: http://ftp.gnu.org/gnu/ncurses/ncurses-6.3.tar.gz
        sha256: 97fc51ac2b085d4cde31ef4d2c3122c21abc217e9090a43a30fc5ec21684e059
  
  - name: glu
    buildsystem: meson
    sources:
      - type: archive
        url: https://archive.mesa3d.org/glu/glu-9.0.3.tar.xz
        sha256: bd43fe12f374b1192eb15fe20e45ff456b9bc26ab57f0eee919f96ca0f8a330f

  - name: savage2
    buildsystem: simple
    build-commands:
      - chmod +x Savage2-2.1.1.1-linux-x64-installer.run
      - ./Savage2-2.1.1.1-linux-x64-installer.run --prefix /app/savage2 --mode unattended
      - rm /app/savage2/libs/libstdc++.so.6
      - install -Dm755 savage2.sh /app/bin/savage2
    sources:
      - type: file
        url: https://masterserver1.talesofnewerth.com/downloads/Savage2-2.1.1.1-linux-x64-installer.run
        sha256: 438e37a997aad2655b27aff01732bebc4adbc3f105b0b3357ca2723c3cccc604
      - type: script
        dest-filename: savage2.sh
        commands:
          - cd /app/savage2
          # With flatpak-builder on debian 12, the game does not find libGLU.so.1 which is in /app/lib64.
          # This is a strange thing because it does not reproduce on gentoo with newer flatpak-builder.
          # I didn't understand the problem, but here's a workaround:
          - export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/app/lib64
          - ./savage2.bin

finish-args:
  - --share=network
  - --socket=x11
  - --share=ipc
  - --socket=pulseaudio
  - --device=dri
  - --filesystem=~/.savage2:create

On gentoo and debian, the game starts and works. On a steam deck, I see instead

(deck@steamdeck ~)$ flatpak run net.savage2.game
warning: The VAD has been replaced by a hack pending a complete rewrite
X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  1 (X_CreateWindow)
  Value in failed request:  0x0
  Serial number of failed request:  56
  Current serial number in output stream:  68

How does one debug this?
(The line warning: The VAD... is normal and expected)

2

Could you provide a list of all *.so files inside of the game archive? Some of those might need to be replaced

3

Hi. Sure, here they are:

/app/savage2/game/game.so
/app/savage2/game/cgame.so
/app/savage2/game/libgame_shared.so
/app/savage2/updater_x11.so
/app/savage2/editor/cgame.so
/app/savage2/vid_gl2.so
/app/savage2/libk2.so
/app/savage2/modelviewer/cgame.so
/app/savage2/libs/libcurl.so.4
/app/savage2/libs/libspeex.so.1
/app/savage2/libs/libfreetype.so.6
/app/savage2/libs/libfmodex64.so
/app/savage2/libs/libpng12.so.0
/app/savage2/libs/libspeexdsp.so.1
/app/savage2/libs/libgcc_s.so.1

I already remove some libraries in the manifest, and that’s enough to get the game running on both debian and gentoo.

In the meanwhile, I could launch the game on the steam deck if I set SetSave vid_xrandr "false". This, if I understand correctly, turns off using xrandr to detect screen settings. But on other systems this wasn’t necessary.

Inside the game, the xrandr business is probably happening in /app/savage2/vid_gl2.so. This is a part of the k2 game engine, and it should be close to noh/src/vid_gl2 at main · shawwn/noh · GitHub
So, if the problem is with the game and not the environment, it may be possible to fix something inside vid_gl2.so.