Linux Mint related issues with windowed mode and screen resolution

[Mangobile]

Anything Linux related, e.g. bugs or problems with a specific distribution.

[sgbeal]

Crashed during config, now refuses to start

The first thing i did after starting TMR was go to the configuration to change the screen resolution to 1440x900 (i think) and disable full-screen mode. When i clicked the Apply button it crashed my window manager 3 times in a row and left the app window in some weird state (only about 50 pixels wide and 1000 pixels tall), so i had to kill it. Since then, TMR will no longer start. i tried uninstalling and reinstalling it, also tried disabling Steam Cloud sync (because i've had cloud sync of corrupt game data cause similar problems in other games before), but no change. When i start the app via the "Play" button Steam, it tries to start for 1-2 seconds, then immediately dies. The TMR window never appears, not even briefly.

When i use the "browse local files" option to Steam i can find no log files or config files, only static game files ($HOME/.local/share/Steam/steamapps/common/Tactics Maiden).

What can i do to force it to return to a default state so that i can start it again?

Platform: Linux Mint 19 on x64.

[sgbeal]

i reconfigured my Steam startup script to retain debug output from steam, and on startup TMR simply says:

Found path: /home/stephan/.local/share/Steam/steamapps/common/Tactics Maiden/TacticsMaiden.x86_64
Mono path[0] = '/home/stephan/.local/share/Steam/steamapps/common/Tactics Maiden/TacticsMaiden_Data/Managed'
Mono path[1] = '/home/stephan/.local/share/Steam/steamapps/common/Tactics Maiden/TacticsMaiden_Data/Mono'
Mono config path = '/home/stephan/.local/share/Steam/steamapps/common/Tactics Maiden/TacticsMaiden_Data/Mono/etc'
displaymanager : xrandr version warning. 1.5
client has 4 screens
displaymanager screen (0)(HDMI-0): 1920 x 1200
Using libudev for joystick management


Importing game controller configs



That's all it says - no error messages.

[sgbeal]

i was able to install and start it on my laptop (a different machine but the same OS), but i don't actually use Steam on that machine (the screen's too small). Changing to windowed mode also killed the window manager on that machine.

[sgbeal]

Update: after launching it twice on my laptop, it did the exact same thing as on my desktop: the window suddenly changed to some absurd size (about 50x1000 pixels) and could not be resized. After closing it, TMR can no longer be opened. Clicking on "play" behaves like it will start up, but only for 1-2 seconds, then it stops. The TMR window never appears.

[sgbeal]

Update: i found some config and log files outside of steam:

[stephan@lapdog:~/.config/unity3d/Mangobile/Tactics Maiden]$ cat Player.log

Selecting FBConfig
GLX_FBCONFIG_ID=121
GLX_BUFFER_SIZE=32
GLX_DOUBLEBUFFER=1
GLX_RED_SIZE=8
GLX_GREEN_SIZE=8
GLX_BLUE_SIZE=8
GLX_ALPHA_SIZE=8
GLX_DEPTH_SIZE=24
GLX_STENCIL_SIZE=8
GLX_SAMPLES_ARB=0
GLX_SAMPLE_BUFFERS_ARB=0
GLX_STEREO=0
GLX_CONFIG_CAVEAT=NONE

Desktop is 1366 x 768 @ 60 Hz
Invalid resolution: 29 x 713
Failed to initialize ScreenManager


the 29x713 resolution is what i estimated above as 50x1000 pixels.

After deleting that directory and starting TMR, it runs, but i'm now afraid to disable full-screen mode because doing that permanently killed the app on to machines. (But i also hate running any app in full-screen mode.)

[Mangobile]

Sorry, just have seen your post now.
Alright, first things first.

In order to restore the default state just change to the following directory:
cd ~/.config/unity3d/Mangobile/Tactics*

There you remove the configuration file:
rm OptionsNew

That's it. This is the ONLY file you should tamper with.

I'm using both gnome and unity desktop managers on Ubuntu 18.04.1 with no issues at all.
I can vaguely remember someone mentioning general issues with the Unity3D engine and Mint Linux in particular, but I don't want to spread any wrong rumors, so I start doing some research now.

Would it be a feasible for you not to use windowed mode for the time being?

[Mangobile]

Alright, there are definitely issues with Unity3d and windowed mode under Linux.
Actually not only on Mint, but also on Ubuntu in a few cases, as I've seen just now.

Here's what we can try:
The next time you'll start TMR on Linux, you'll see Unity's 3d original screen resolution dialog. For my card most of the resolutions were working, but some of them were crashing my whole gnome desktop as well.

So if you want to use windowed mode under Linux, you have to do some trial and error.
Some of the resolutions will hopefully work (like in my case).

If your'e stuck, remember to just delete the NewOptions configuration file as described above.
Let me know how this is working out for you.


P.S. I start to understand why most of the big companies don't offer Linux support. That's quite adventurous ;).

[Mangobile]

Ha! I've found a way how it works fine for me on gnome:
Select a resolution that is slightly smaller than the best resolution your GPU offers, but DONT use windowed mode yet.
Despite the non-windowed mode, you see a window bar at the top (at least that's the case for gnome). Drag this bar down, and you're in windowed mode suddenly and can resize the window as you see fit. No crashes in this case.

[sgbeal]

Thanks for the responses :). i tried several different options with the new resolution dialog and most crashed without ever starting the app (and no OptionsNew was left behind). i discovered that it works fine, in windowed mode, if i select a relatively low resolution, e.g. 1280x720. That's perfectly fine for me. My desktop is running at 1920x1200. i have not yet discovered what maximum resolution i can select before crashing it, but any resolution of 1600xAnything or higher crashes TMR. That's not a big deal, though - i don't mind 1280xSomething.

[sgbeal]

Ooops - i spoke too soon. It still crashed with the lower resolution, just at a later point. Selecting 1600xSomething, non-Windowed, now causes it to start up Windowed with a resolution of 1920x1145. Weird.

In any case, i can get as far as the first mission, so it seems to be working :).

Thanks again for the help!

PS: i agree completely about Linux graphics/game support even though it's my only OS since almost 20 years (and my second OS since 25 years). i don't blame game developers for not supporting it - supporting its millions of distributions and variables is impossible. Most of my gaming is on Android. Even so, i truly appreciate you offering a Linux port :).

[sgbeal]

Update: i was able to play through the first mission, but after exiting, it now crashes again every time i start it, regardless of which resolution or window/non-window mode i choose :/. Deleting OptionsNew doesn't resolve it.

Player.log says:

[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
TacticsMaiden.x86_64: ../../src/xcb_io.c:259: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.


Then comes a long stack trace starting at libmono. It traces through libmono and my local libraries (libpthread, libc, libX11) then ends in TacticsMaiden.x86_64().

=================================================================
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================

(then lots of harmless messages, then...)

XError: BadMatch (invalid parameter attributes) (error 8, opcode 156/34, serial 101, XID 0720000e, display 0x28de030


i'll report back if i find a workaround.

[sgbeal]

Update: selecting 1024x768 windowed mode _seemed_ to work reliably. i was able to repeatedly start and quit the game without it crashing. Then i went to the Gameplay Config to change some options (disable treasure stealers, boss spawns, and enable automatic treasure chest collection), and now it crashes again on startup.

Deleting OptionsNew did not solve it, but i tried starting it again 3 times in a row, each time selecting 1024x768 windowed mode, and on the 3rd time it started. It's very unpredictable, almost as if it's a threading problem (libpthread was in the stack tracei saw earlier).

After it started, i immediately exited and started it again with the same resolution, and it crashed the window manager again and resized the window to that weird "impossible" size.

Is it conceivable that there's a threading race condition during startup?

[Mangobile]

As soon as I have a little bit more time, I'll check whether there's a more stable version of the Unity3d engine which addresses this particular problem.
I'm using a slightly older Unity3d version actually, one that has turned out to be quite stable in most cases so far. Well, obviously it's not very stable for Linux.
But that's a general problem with these engines. There's always something not working, and you have to find the version that makes the least problems for your particular game.

[Mangobile]

Alright, let's see what we can do about the problems on Linux Mint.
I've spent a few hours now going through various Unity3D and Linux forums, as well as doing a few experiments.

There are 2 things that look quite promising so far on my machine:

1) I've uploaded a new version V 3.2.15, having removed everything that could be somehow critical in terms of GPU related crashes: Antialiasing, Anisotropic filtering, soft particles, and so on.
With my bad eye sight I probably shouldn't be the one to judge, but I hardly see any difference for a 2D app anyway.

2) (At least for the moment) I've decoupled the linux version of TMR from the Steam launcher, so you can simply start the executable in the shell. (Steam achievements are not working in this case). Not only should that make your life for further testing easier, but there's also something else you can try:
Starting the 32-bit version instead of the 64-bit version. This is only working, of course, if you've installed the required 32-bit libraries to run 32-bit apps.
There was one guy who said all his Unity crash problems disappeared once he switched to the 32-bit version of his (other) game. While I didn't find the reasoning very convincing, it might be worth a shot.

On my machine the Tactics Maiden executables are located here:
~/.local/share/Steam

The exact folder seems to vary from case to case, but you seem to be savvy enough to figure that out on your own with find and grep.

You can start the 32 bit version using:
./TacticsMaiden.x86
or
./TacticsMaiden.x86 -show-screen-selector
if you want to start Unity's default configuration tool first

Please, let me know whether you can see any kind of improvement.

P.S.: For the record, here's the behavior on my Ubuntu 18.04.1 distribution.
So far it hasn't crashed while playing the game.
However, it does crash now and then if I change the resolution.
It doesn't seem to do so in a deterministic way, unfortunately. So your idea about a race condition might be spot on.

[sgbeal]

After the update i was able to start it and exit it 3 times in a row using the normal Steam launcher approach (selecting the default full-screen resolution), but i see the message "Steam disabled" in the top/right of the screen, even though it was started via Steam. On my 4th, 5th, and 6ths attempts to start it via Steam, it crashed at startup, after the window frame appeared but before anything was rendered to it.

Starting it with TacticsMaiden.x86_64 worked exactly half of the time: it crashed once, then started up twice, then crashed again. It both crashes, the window frane appeared but it crashed before anything could be rendered to it.

After installing the 32-bit libraries, TacticsMaiden.x86 started up 3 times in a row, but then crashed at startup the next 4 times, then started up again the 8th time i tried (so it crashed half the time, just like x86_64).

After each crash, Player log says the same thing:

TacticsMaiden.x86: ../../src/xcb_io.c:259: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.
...
XError: BadMatch (invalid parameter attributes) (error 8, opcode 156/34, serial 99, XID 0760000e, display 0xa76cb10