Jump to content
  • 0

[Linux] Unable to start game, hangs on black screen


kujeger

Question

I reported this back in the BB as well, but figure it's OK to repost it here, along with a workaround.

 

Essentially, if your OS version of libSDL2 does not match the one needed by the game, the libAkSoundEngine.so library freezes

and the game gets stuck at a black screen with 100% cpu use.

 

A workaround is to add this line under Launch Options in steam:

 

LD_PRELOAD=$LD_PRELOAD:./PillarsOfEternityII_Data/Plugins/x86_64/libSDL2-2.0.so %COMMAND%
(Original thread: https://forums.obsidian.net/topic/95886-linux-unable-to-start-game-hangs-on-black-screen/ )

 

edit: soulsource has another, neater workaround:

There's also another workaround: Instead of using LD_PRELOAD to force loading the libsdl2 version that's bundled along with the game, one can use a nifty feature of libsdl2, which gets explained here: https://plus.google.com/u/0/+RyanGordon/posts/TB8UfnDYu4U

 

Basically this feature allow to use the system installed libsdl2 version even if an application is statically linked against libsdl2 (the Unity player is statically linked against it...).

 

So, what I am doing in order to get the game running is to set the following environment variable (of course with the correct path to your system installed libsdl2):

SDL_DYNAMIC_API=/usr/lib64/libSDL2.so
My command line on Steam now looks like this:

SDL_DYNAMIC_API=/usr/lib64/libSDL2.so LC_ALL=C %command%
Edit:

Of course you can also use the same environment variable to use Steam's libsdl2, if you prefer. Just point it to

SDL_DYNAMIC_API=~/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0

 

Edited by kujeger
  • Like 4
Link to comment
Share on other sites

18 answers to this question

Recommended Posts

  • 0

working for me with that command:

cd "/media/stockage_hellblazer/SteamLibrary/steamapps/common/Pillars of Eternity II"

MESA_GL_VERSION_OVERRIDE=4.5 MESA_GLSL_VERSION_OVERRIDE=450 LD_PRELOAD=PillarsOfEternityII_Data/Plugins/x86_64/libSDL2-2.0.so DRI_PRIME=1 ./PillarsOfEternityII
 

Link to comment
Share on other sites

  • 0

I also had this issue until using your workaround even if the "symptom" was not the same. Now... it seems to work... but not without crashing my desktop manager (KDE).

Hm... A bit annoying. I hope it will be fixed. :)

Link to comment
Share on other sites

  • 0

An hour left to download so don't know if this problem pops up for me, but do you know if this is a Steam-only solution and what it might be for the GOG release?

 

This is what the start.sh file looks like for the FIRST Pillars game on my end.

#!/bin/bash
# GOG.com (www.gog.com)
# Pillars of Eternity

# Initialization
CURRENT_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
cd "${CURRENT_DIR}"
source support/gog_com.shlib

# Game info
GAME_NAME="$(get_gameinfo 1)"
VERSION="$(get_gameinfo 2)"
VERSION_DEV="$(get_gameinfo 3)"

# Actions
run_game() {
	echo "Running ${GAME_NAME}"
	local bin32_name="PillarsOfEternity"
	local bin64_name="PillarsOfEternity"
	local bin_path32="$CURRENT_DIR/game/"
	local bin_path64="$CURRENT_DIR/game/"
	local lib_path32="$CURRENT_DIR/game"
	local lib_path64="$CURRENT_DIR/game"
	execute_game "${bin32_name}" "${bin64_name}" "${bin_path32}" "${bin_path64}" "${lib_path32}" "${lib_path64}"
		
}

default() {
  run_game
}

# Options
define_option "-s" "--start" "start ${GAME_NAME} [default]" "run_game" "$@"

# Defaults
standard_options "$@"
Link to comment
Share on other sites

  • 0

An hour left to download so don't know if this problem pops up for me, but do you know if this is a Steam-only solution and what it might be for the GOG release?

 

This is what the start.sh file looks like for the FIRST Pillars game on my end.

#!/bin/bash
# GOG.com (www.gog.com)
# Pillars of Eternity

# Initialization
CURRENT_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
cd "${CURRENT_DIR}"
source support/gog_com.shlib

# Game info
GAME_NAME="$(get_gameinfo 1)"
VERSION="$(get_gameinfo 2)"
VERSION_DEV="$(get_gameinfo 3)"

# Actions
run_game() {
	echo "Running ${GAME_NAME}"
	local bin32_name="PillarsOfEternity"
	local bin64_name="PillarsOfEternity"
	local bin_path32="$CURRENT_DIR/game/"
	local bin_path64="$CURRENT_DIR/game/"
	local lib_path32="$CURRENT_DIR/game"
	local lib_path64="$CURRENT_DIR/game"
	execute_game "${bin32_name}" "${bin64_name}" "${bin_path32}" "${bin_path64}" "${lib_path32}" "${lib_path64}"
		
}

default() {
  run_game
}

# Options
define_option "-s" "--start" "start ${GAME_NAME} [default]" "run_game" "$@"

# Defaults
standard_options "$@"

 

That depends on GOG's packaging for the game, but if there's similar problem you could possibly add something like this to the top of the script:

export LD_PRELOAD=$LD_PRELOAD:./PillarsOfEternityII_Data/Plugins/x86_64/libSDL2-2.0.so
(you'd have to make sure the path to libSDL2-2.0.so matches)
  • Like 3
Link to comment
Share on other sites

  • 0

There's also another workaround: Instead of using LD_PRELOAD to force loading the libsdl2 version that's bundled along with the game, one can use a nifty feature of libsdl2, which gets explained here: https://plus.google.com/u/0/+RyanGordon/posts/TB8UfnDYu4U

 

Basically this feature allow to use the system installed libsdl2 version even if an application is statically linked against libsdl2 (the Unity player is statically linked against it...).

 

So, what I am doing in order to get the game running is to set the following environment variable (of course with the correct path to your system installed libsdl2):

SDL_DYNAMIC_API=/usr/lib64/libSDL2.so

My command line on Steam now looks like this:

SDL_DYNAMIC_API=/usr/lib64/libSDL2.so LC_ALL=C %command%

Edit:

Of course you can also use the same environment variable to use Steam's libsdl2, if you prefer. Just point it to

SDL_DYNAMIC_API=~/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0
Edited by soulsource
  • Like 3

Crystalmancer of the Obsidian Order

Link to comment
Share on other sites

  • 0

There's also another workaround: Instead of using LD_PRELOAD to force loading the libsdl2 version that's bundled along with the game, one can use a nifty feature of libsdl2, which gets explained here: https://plus.google.com/u/0/+RyanGordon/posts/TB8UfnDYu4U

 

Basically this feature allow to use the system installed libsdl2 version even if an application is statically linked against libsdl2 (the Unity player is statically linked against it...).

 

So, what I am doing in order to get the game running is to set the following environment variable (of course with the correct path to your system installed libsdl2):

SDL_DYNAMIC_API=/usr/lib64/libSDL2.so
My command line on Steam now looks like this:

SDL_DYNAMIC_API=/usr/lib64/libSDL2.so LC_ALL=C %command%
Edit:

Of course you can also use the same environment variable to use Steam's libsdl2, if you prefer. Just point it to

SDL_DYNAMIC_API=~/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0

 

Ah, I'd totally forgotten about that feature. I'll update my post, it's a much nicer workaround.
Link to comment
Share on other sites

  • 0
Guest Jamila

In my case, I had to launch the game like this:

MESA_GL_VERSION_OVERRIDE=4.5 MESA_GLSL_VERSION_OVERRIDE=450 LD_PRELOAD=./game/PillarsOfEternityII_Data/Plugins/x86_64/libSDL2-2.0.so DRI_PRIME=1 ./game/PillarsOfEternityII

To get over the game using OpenGL 3.0 but demanding 3.2 or higher and using system libSDL2. Moreover I had to compile wayland and wayland-egl, because libSDL2 supplied with the game is linked againts these libraries. This was rahther unexpected, as I do not use Wayland.

Link to comment
Share on other sites

  • 0

Thanks for the workaround! Why is the game statically linking SDL in the binary??

It's not the game itself, it's the Unity player. The game code actually tries to dynamically load libsdl2 (what afaik is the only option to use native libraries in C#), what fails if the libsdl version it tries to load differs from the one Unity is statically linked against.

Still, I'd also like to know the reasoning behind Unity being linked statically. The libsdl2 ABI is supposed not to change, so there should be no reason to ever statically link against it...

  • Like 1

Crystalmancer of the Obsidian Order

Link to comment
Share on other sites

  • 0

In my case, I had to launch the game like this:

MESA_GL_VERSION_OVERRIDE=4.5 MESA_GLSL_VERSION_OVERRIDE=450 LD_PRELOAD=./game/PillarsOfEternityII_Data/Plugins/x86_64/libSDL2-2.0.so DRI_PRIME=1 ./game/PillarsOfEternityII

To get over the game using OpenGL 3.0 but demanding 3.2 or higher and using system libSDL2. Moreover I had to compile wayland and wayland-egl, because libSDL2 supplied with the game is linked againts these libraries. This was rahther unexpected, as I do not use Wayland.

If you use the SDL_DYNAMIC_API environment variable instead of LD_PRELOAD, you can just tell libsdl to load your system libsdl2 (the one in /usr/lib64 or similar), which should not be linked against wayland, so you won't need to install it.

Edit: I haven't tried this though, no idea if the game code has the path to ./game/PillarsOfEternityII_Data/Plugins/x86_64/libSDL2-2.0.so hardcoded somewhere, in which case it will probably fail before SDL_DYNAMIC_API ever gets used.

Edited by soulsource

Crystalmancer of the Obsidian Order

Link to comment
Share on other sites

  • 0

Hi,

When starting the game via steam or directly from PoEII folder, i get the window's framing, but nothing else (no gauntlet cursor, no sound, no video). Alt-tab is still useable, and i must kill the process.

 

Tried via terminal too:

./PillarsOfEternityII --help
Set current directory to /media/stockage_hellblazer/SteamLibrary/steamapps/common/Pillars of Eternity II
Found path: /media/stockage_hellblazer/SteamLibrary/steamapps/common/Pillars of Eternity II/PillarsOfEternityII
Mono path[0] = '/media/stockage_hellblazer/SteamLibrary/steamapps/common/Pillars of Eternity II/PillarsOfEternityII_Data/Managed'
Mono path[1] = '/media/stockage_hellblazer/SteamLibrary/steamapps/common/Pillars of Eternity II/PillarsOfEternityII_Data/Mono'
Mono config path = '/media/stockage_hellblazer/SteamLibrary/steamapps/common/Pillars of Eternity II/PillarsOfEternityII_Data/Mono/etc'
Preloaded 'libdiscord-rpc.so'
Preloaded 'ScreenSelector.so'
Preloaded 'libAkFlanger.so'
Preloaded 'libAkHarmonizer.so'
Preloaded 'libAkPitchShifter.so'
Preloaded 'libAkSoundEngine.so'
Preloaded 'libAkStereoDelay.so'
Preloaded 'libAkTremolo.so'
Preloaded 'libMcDSP.so'
Preloaded 'libSDL2-2.0.so'
Preloaded 'libsteam_api.so'
Player data archive not found at `/media/stockage_hellblazer/SteamLibrary/steamapps/common/Pillars of Eternity II/PillarsOfEternityII_Data/data.unity3d`, using local filesystem

Check 3 times the game integrity. No luck.

 

I'm currently downloading again the game.

 

OS: Debian Linux

Kermel: 4.16.0.1-amd64

Graphics: Nvidia gtx 1060

Player.log.zip

Edited by thana54
Link to comment
Share on other sites

  • 0
Guest Jamila

 

In my case, I had to launch the game like this:

MESA_GL_VERSION_OVERRIDE=4.5 MESA_GLSL_VERSION_OVERRIDE=450 LD_PRELOAD=./game/PillarsOfEternityII_Data/Plugins/x86_64/libSDL2-2.0.so DRI_PRIME=1 ./game/PillarsOfEternityII

To get over the game using OpenGL 3.0 but demanding 3.2 or higher and using system libSDL2. Moreover I had to compile wayland and wayland-egl, because libSDL2 supplied with the game is linked againts these libraries. This was rahther unexpected, as I do not use Wayland.

If you use the SDL_DYNAMIC_API environment variable instead of LD_PRELOAD, you can just tell libsdl to load your system libsdl2 (the one in /usr/lib64 or similar), which should not be linked against wayland, so you won't need to install it.

Edit: I haven't tried this though, no idea if the game code has the path to ./game/PillarsOfEternityII_Data/Plugins/x86_64/libSDL2-2.0.so hardcoded somewhere, in which case it will probably fail before SDL_DYNAMIC_API ever gets used.

 

I think it just loads everything from Plugins directory.

Link to comment
Share on other sites

  • 0

Sorry folks to kick an old thread back up, however I am running Open Suse 15.0, and I had to run using this bash script, it will launch the steam app, and then I can run the game.  so in a file called Steam_Start.sh, I added this code to launch steam.  I think it's pretty much the same as the others, but compact?   Hopefully this can help anyone else using Open Suse( I would be curious if it also worked with other distro's ).

 

#!/bin/bash
 
STEAM_RUNTIME_PREFER_HOST_LIBRARIES=0 steam
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...