X³: TC and AP - Linux support thread

[duozerk]

Hello,

I recently installed X3AP for Linux (through steam).
Everything in the game seems to be working well (thus far) but I seem to have a big issue with what I assume to be some textures; specifically the clouds textures on all planets and what I assume to be some sort of semi-transparent "glare" texture when looking at remote stars.

Screenshots, planet issue:

https://i.imgur.com/rNTXk6W.jpg
https://i.imgur.com/OsfrQK7.jpg
https://i.imgur.com/noarXga.jpg

"Glare" issue:

https://i.imgur.com/mAd24nm.jpg

I assume the root cause is the same for both.
My system information: Debian Jessie amd64; NVidia Geforce 660M (and also an intel card, running the game through it has the same issue, see below).
The game is the very latest steam version, unmodded. The bonus pack is installed (through innoextract due to the lack of a linux port).
My graphic drivers are also the very latest, proprietary nvidia ones (the 9th February 361.28 release); installed in an attempt at fixing the issue - was previously using ~6 months old drivers with the same issue.
What I have tried:

• Changing all graphics parameters (including the greyed out AA one through config.yaml, resolution, glow, etc.); running the game windowed as well; to no effect.
• Updating my graphic drivers (no results).
• Starting a new game with a different start script (the screenshots above come from a Humble Merchant one) - no result.
• Checking the files integrity in steam (everything OK, no anomaly).
• Running the game through my Intel card (I have optimus) instead of the nvidia one; the game runs fine but has the same issue.
• Checking the "Run previous version" checkbox.
• Launching the game directly with steam closed (still going through testandlaunch).
• Launching X3AP_main and X3AP_main_b11 (I assume this stands for "build11") directly without going through the config tool first (with or without going through testandlaunch).
• Out of despair, I also tried tweaking LD_LIBRARY_PATH to use some system libraries instead of the steam/game ones (tried that for libGL* libs such as libGLEW) - no results either.
• Launching X3TC without AP; same issue.

None of it worked.
The fact that the issue occurs even with the intel card makes me suspect some sort of texture compression issue, perhaps ? note that in some systems, the planet looks mostly OK but a slight upper cloud layer is messed up the same way - weird lines instead of clear texture.
Also note on the above screenshots that on most planets, only part of the planet shows the issue.

I should also add that I played X3: Reunion years ago (the LGP preorder boxset - also participated in the LGP beta at the time) and I never saw such an issue through hundreds of hours of game time - this probably has low relevance though, since I suppose X3TC/AP improved on the graphics and the issue probably occurs on one of those improvements ?

In any case, this is a big issue for me because it completely breaks immersion; I'm also afraid some other texture issues will show up later in game (I only played for about an hour right now - no combat, for example). I was ecstatic when I discovered that X3TC not only was released for Linux, but that X3AP had been released as well, and I'd really like to be able to play this game.

Does anyone have any suggestion / tweaks I could try, or an idea of where this issue could come from ? even some sort of graphics improval mod that would replace those textures may be a solution, maybe ? or possibly converting the problematic texture to another format that the game could understand as well ?

Thanks in advance !

[Edit] Forgot to add, I also tried searching for similar issues on Google to no effect; and also tried looking through this very topic for similar issues with no results either (a "search topic" feature on this forum would be a great addition, by the way). Finally, I also looked extensively through the game log (stdout & stderr) but nothing seems out of order - no "unable to load texture" or really any error message that seems relevant.

[Edit2] Updated my forum profile to link to my steam account to prove ownership of the games in case this is required.

[Edit3] I have performed a more extensive search on the forums and it seems to be the exact same issue as another forum user, Gligli, reported previously: http://forum.egosoft.com/viewtopic.php? ... 68#4482968; however, there was never any follow up. I did send a PM to that user just in case. At least I know I'm not alone !

[duozerk]

Please disregard my previous message - I found the source of the "issue" and fixed it (after a few hours messing with the mesa env variables to try and find a root cause...).

Basically, my bumblebee setup was completely messed up for 32 bits apps (and only for those) since a recent update; so when I was trying to run the game through bumblebee, it went through the mesa libGL/my intel card.

The X3 log pretty clearly showed a GL vendor string saying Intel/MESA DRI instead of the expected NVIDIA / Geforce 660M but somehow I missed it... :-/

No wonder I had the same results using the Intel card or the nvidia one... it always used the intel one (despite the optimus hardware led on my laptop lighting up).

It means the issue does occur when playing through my intel card, by the way; I assume this is due to old Mesa libraries ? although those are the latest Jessie ones.

In any case, I can finally play Thanks !

[Yggdrasill]

I put in my old Radeon 5870 and compiled an earlier mesa driver (before commit 07c65b85eada8dd34019763b6e82ed4257a9b4a6) from the git repositories. I still have my Radeon R9 380 in the system, and it is the default card, but I use PRIME to offload X3TC onto the Radeon 5870 using the driver before the issue appeared. It works quite well, though a temporary workaround.

If anyone here has an older card that was supported by mesa in mid-2014 and you have abysmal performance with any UI on the screen (particularly text, it seems), then you can do a git reset --hard 07c65b85eada8dd34019763b6e82ed4257a9b4a6^1 after cloning the mesa git repos and compile that, using $LIBGL_DRIVERS_PATH pointing to the newly compiled drivers when running the game. If you have a newer card, you'll have to either replace it with an old one or put in an older one to run alongside it, offloading to it with PRIME or perhaps using VGA passthrough (my system doesn't support it), though you still need to compile the drivers.

You'll probably want to just compile them without permanently using them, so I'd highly recommend using $LIBGL_DRIVERS_PATH to use the older drivers for X3TC only.

I suspect the issue is with mesa, and so I'll probably make a bug report to them.

[EoD]

I put in my old Radeon 5870 and compiled an earlier mesa driver (before commit 07c65b85eada8dd34019763b6e82ed4257a9b4a6) from the git repositories. I still have my Radeon R9 380 in the system, and it is the default card, but I use PRIME to offload X3TC onto the Radeon 5870 using the driver before the issue appeared. It works quite well, though a temporary workaround.

If anyone here has an older card that was supported by mesa in mid-2014 and you have abysmal performance with any UI on the screen (particularly text, it seems), then you can do a git reset --hard 07c65b85eada8dd34019763b6e82ed4257a9b4a6^1 after cloning the mesa git repos and compile that, using $LIBGL_DRIVERS_PATH pointing to the newly compiled drivers when running the game. If you have a newer card, you'll have to either replace it with an old one or put in an older one to run alongside it, offloading to it with PRIME or perhaps using VGA passthrough (my system doesn't support it), though you still need to compile the drivers.

You'll probably want to just compile them without permanently using them, so I'd highly recommend using $LIBGL_DRIVERS_PATH to use the older drivers for X3TC only.

I suspect the issue is with mesa, and so I'll probably make a bug report to them.

On both my Tonga (R9 380X, amdgpu+radeonsi) and my Barts (HD 6870, radeon+r600) I have between 1 and 8 fps while being docked at a station. I was not able to revert the mentioned commit due to build issues with my setup.

Code: Select all

$ glxinfo | grep OpenGL
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD TONGA (DRM 3.1.0, LLVM 3.8.0)
OpenGL core profile version string: 4.1 (Core Profile) Mesa 11.3.0-devel (git-39e9cf6)
OpenGL core profile shading language version string: 4.10
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

Code: Select all

$ DRI_PRIME=1 glxinfo | grep OpenGL
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD BARTS (DRM 2.43.0, LLVM 3.8.0)
OpenGL core profile version string: 3.3 (Core Profile) Mesa 11.3.0-devel (git-39e9cf6)
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

Has this issue been reported upstream somewhere?

[Yggdrasill]

No, I have been intending to do so for a while and then never got around to it. It doesn't help that apitrace and other tools result in just garbage output that is not relevant.

The only clue I have is the commit where it was introduced and the fact that the issue seems to intensify as more text appears on the screen, but that latter observation may be incorrect.

[EoD]

No, I have been intending to do so for a while and then never got around to it. It doesn't help that apitrace and other tools result in just garbage output that is not relevant.

The only clue I have is the commit where it was introduced and the fact that the issue seems to intensify as more text appears on the screen, but that latter observation may be incorrect.

I did record the apitrace for the issue, but due to Apitrace' issue 234 the replay is super slow if you do not use "apitrace replay -b xxx.trace".
Simple main menu trace: X3TC_slow_apitrace.trace
Full trace with enabling/disabling overlay: X3TC_overlay_bug.trace

Code: Select all

...
Mesa: User error: GL_INVALID_OPERATION in glUniform4("_gl_LightSource[2].attenuation"@8 has 3 components, not 4)
Mesa: User error: GL_INVALID_OPERATION in glUniform4("_gl_LightSource[2].attenuation"@8 has 3 components, not 4)
Mesa: User error: GL_INVALID_OPERATION in glUniform4("_gl_LightSource[2].attenuation"@8 has 3 components, not 4)
Mesa: User error: GL_INVALID_OPERATION in glUniform4("_gl_LightSource[2].attenuation"@8 has 3 components, not 4)
Mesa: User error: GL_INVALID_OPERATION in glUniform4("_gl_LightSource[2].attenuation"@8 has 3 components, not 4)
Mesa: User error: GL_INVALID_OPERATION in glUniform4("_gl_LightSource[2].attenuation"@8 has 3 components, not 4)
...

This looks less like an apitrace issue, but like an application error to me. During the full trace one core is always on 100% and the GPU load is very low. But the fps jump from ~10fps to ~60fps (V-Sync) when the overlay is disabled. Does the application regulate the framerate to those awful values?

If you replay the apitrace you can actually see that the scene in the main menu and the scene without ingame-overlay there are many more frames drawn than the one with the overlay enabled.

[Yggdrasill]

That is indeed the error I've seen from apitrace as well, but it wouldn't explain why it still occurs when the HUD is hidden, yet the game runs at a smooth 60 FPS when it is. I don't think we can blame that error for the performance issues faced on Mesa.

Another thing to note, this issue with performance seems to be a lot like the Windows issue that AMD users have, though it might be a red herring.

[steve_v]

Hi all, new here... With problems, of course.
Just purchased X3: Terran War Pack (GOG, support req. also posted there), and I'm getting reproducible crashes to desktop.
Attempts to switch ship view with F1, F2 etc. result in CTD with "Segmentation Fault" logged to console. This occurs in both TC & AP, with or without preloading GOG library pack.

Repro: Start new game, press F1 or F2 (may take ~3 view switches) -> crash. No other actions in game. No savegame, as I don't get as far as saving before crashing.

Fiddling with graphics settings makes no difference, even on lowest preset / AA AF off etc.

Debian GNU/Linux 8.5, Nvidia 364.19, have tried Nvidia beta drivers to no avail.
Can provide detailed system spec, but not sure how to attach files on this board and don't really want to drop a massive WOT.
Any other logs I can provide?

Had a quick look through the Linux support thread but I don't see this specific issue... or maybe not looking hard enough.
Any advice? I'd kinda like to play this, but CTDs aren't much fun.

ED: Syestem logs say:
X3TC_main[2376]: segfault at fffdff39 ip 00000000f46645e6 sp 00000000ffca9c00 error 4 in libnvidia-glcore.so.364.19[f31c6000+1bf1000]

[Alan Phipps]

Moving above post to Linux support thread.

[Premislaus]

Hi! I'm currently on Linux, and I have some problems with performance - menus in X3:TC and AP causes stuttering. After new game and before hiding HUD (shift+h), I experience 1-13 FPS. After shift+h 30-70 FPS!

My specification:
openSUSE Tumbleweed (with KDE) and Ubuntu 16.04, both x86-64.
Mesa 11.2.2 and 12.1-devel (DRI2 and DRI3).
Kernel 4.6.2 in openSUSE, in Ubuntu maybe 4.4.
X.Org 1.18.3.

AMD A6-4400M.
Radeon HD 7520G (OpenGL 4.1) and 7670M (OpenGL 3.3).
6 GB of RAM.

This patch does not make difference - http://forum.egosoft.com/viewtopic.php?t=390501.

[X2-Illuminatus]

This patch does not make difference - http://forum.egosoft.com/viewtopic.php?t=390501

As described at the top of that post, this beta patch is for Windows only.

[pumpkinmountain]

Hi all

I've fired up X3TC for Linux and immeditely went to add some "basic sanity preservation" mods. But plugin manager lite is Windows only.

The SPK utils don't compile on a reasonably modern Linux, so I had to patch them. Patch here: http://forum.egosoft.com/viewtopic.php? ... 29#4617829

[steve_v]

So... any help for the CTDs I mentioned?
I'm simply avoiding using external view on certain ships for now (notably novas & mercurys) but I'm also seeing crashes on engaging kha'ak scouts (every time) and on undocking from internal station bays (occasionally, again only certain ships).

e.g.

Code: Select all

X3TC_main[20570]: segfault at 0 ip           (null) sp 00000000e772c2ac error 14 in X3TC_main[8048000+23a000]
X3TC_main[23419]: segfault at fffffff0 ip 00000000f60ffba2 sp 00000000ffa8a784 error 5 in libc-2.19.so[f607c000+1a7000]
X3TC_main[25801]: segfault at ffeb0170 ip 00000000f507e718 sp 00000000ffcce6c0 error 4 in libnvidia-glcore.so.364.19[f375d000+1bf1000]
X3TC_main[25922]: segfault at ffffffff ip 00000000080728fc sp 00000000ffd705a0 error 5 in X3TC_main[8048000+23a000]

I have tried various GPU driver versions (inc. latest beta) as well as replacing the bundled libs with system versions (where possible), as suggested over on the GOG forums, to no avail.
I've had pretty much zero issues in other games on this system and I've got nothing pointing to hardware issues either, is the Linux port just broken or what? Hows the game run in wine? I'm not keen on that option at all but this getting is more than a little bit aggravating.

--Ed--
Yup, as I expected> Aside from less-than-stellar performance and missing music / voice the game runs just fine in wine, no crashes at all. I guess the Linux port is just broken.

Anyone know how to get sound working properly in wine then?

[steve_v]

Okay, for anyone running into this in the future: I seem to have solved my crashing issues.

Grabbed all the bundled libraries from steams runtime (contents of ~/.steam/bin32/steam-runtime/i386/usr/lib/i386-linux-gnu/) and dropped them in the "lib" directory that comes with the GOG release. Linked libGLEW.so.1.10.0 to libGLEW.so.1.9.
So far so good.

The steam runtime explains why steam users don't see this issue, but I'd still be curious as to exactly what was causing it... that's a whole host of libs I've just replaced & it feels like a sledgehammer solution to me. Anyone know how to debug this properly?

[andreihaiducul]

Grabbed all the bundled libraries from steams runtime (contents of ~/.steam/bin32/steam-runtime/i386/usr/lib/i386-linux-gnu/) and dropped them in the "lib" directory that comes with the GOG release. Linked libGLEW.so.1.10.0 to libGLEW.so.1.9.
So far so good.

Maybe GOG shipped some volatile libs (like stdc++ or libX11) that conflict with those linked to your OpenGL driver, as I've seen in some of their recent packages. You could try deleting all shipped libs except "third"-party ones like SDL or GLEW. If that doesn't work, you can use LD_LIBRARY_PATH instead of copying over the entire runtime from steam, like this:

Code: Select all

LD_LIBRARY_PATH="$HOME/.steam/steam/ubuntu12_32/steam-runtime/i386/lib/i386-linux-gnu:$HOME/.steam/steam/ubuntu12_32/steam-runtime/i386/usr/lib/i386-linux-gnu" ./start.sh

[steve_v]

You could try deleting all shipped libs except "third"-party ones like SDL or GLEW.

I did that first off, the only thing I couldn't remove (and hence use system copies) was the libav stuff, as Debian is a few versions ahead now.

Seems to me like it's the other way around - the conflict is not with the libs GOG is bundling, but something shipped with Debian. If I remove all the GOG libs bar libav*, it still crashes. Replacing those with steams copies (same version) - still crashes. Adding the entire steam runtime fixes it, but I lack the motivation right now to go through that lot one at a time to find out which specific library makes the difference.

The steam runtime does contain a bunch of X11 libs, and my hunch is that it's one of them, but it's some 160 files to check in total... which is why I was after a non trial-and-error way of pinning it down.

All I can say right now is it's not libGLEW, libSDL, or libav*. Crashes occur with any version of those that I have tried.

I know about LD_LIBRARY_PATH, it's just more convenient for me to copy them, as I don't usually have steam installed. Saves me wondering why the issue returns when I nuke steam again.

Ed--

Well bugger me, it was OpenAL all along.
System version: libopenal.so.1.15.1
Steam version: libopenal.so.1.13.0
It's not shipped with the GOG release. -> using system lib -> crashing.
Switching out that one library for the one in the steam runtime makes all the difference.

Can anyone else confirm this?

[tyk]

Well bugger me, it was OpenAL all along.
System version: libopenal.so.1.15.1
Steam version: libopenal.so.1.13.0
It's not shipped with the GOG release. -> using system lib -> crashing.
Switching out that one library for the one in the steam runtime makes all the difference.

Can anyone else confirm this?

Well, let me first say thank you. This information helped me solve my problem.

Using Steam's runtime with LD_LIBRARY_PATH resulted in a crash. So I had to replace the OpenAL library.

So now, the game does not crash by pressing F1/F2 if I do the following:
- Replace OpenAL in game's own lib directory with the version from Steam's runtime.
- Remove libXML from game's own lib directory so it is replaced with the system version (Ubuntu 16.04). If I don't do this, then the game will complain about the version being too old (although it still starts).
- Start the game without GOG's wrapper scripts by running ./X3AP_main

[steve_v]

Well, let me first say thank you. This information helped me solve my problem.

Glad to be of assistance.

[Akdor 1154]

Is there any word on the performance issues with HUD stemming from that git commit?

Jarrad

[OutsideTheNormalMoralCont]

Is there any way to edit .cat files in Linux? The mod I'm using apparently thought it would be funny to make the pHQ unusable and not say anything about it.