STK 0.9.1 - Fullscreen bug

[halol]

Hello,

I run STK on Linux Mint 17.2 with a Radeon HD 6670 (radeon-crimson-15.12-15.302 driver). My desktop resolution is 1600x1200, but I play STK at 1024x768 in fullscreen mode for better performance. Worked perfectly with STK 0.8.

With 0.9.1, when I switch to fullscreen it looks like STK is not properly 'resized': I can only see the top left corner of the screen, as if it was using the 1600x1200 resolution but got displayed on a 1024x768 screen. I tried with various resolutions but I always run into the same problem. I also tried to delete my 0.8 data/preferences, but still no luck.
Is there an option that I should try to fix this?

So far the only solution I found to enjoy the game in fullscreen mode is to use the 1600x1200 resolution. Unfortunately the performance is then way too bad, there is no way I can play like this.

Note: I just tested the nightly build and fullscreen seems to be working fine again (the game crashes quickly but that's another story). So it looks like the bug is fixed in the latest code. But I would still be interested in a potential solution to make it possible for me to use the current released version...

Thanks.

[Auria]

Hi,

it's good if the bug is already fixed, I don't have any tips to fix last stable release unfortunately.
Maybe we should instead focus on fixing this crash you're having with the recent version? Also is this "nightly" downloaded from somewhere or self-built?

[deve]

@halol are you 100% sure that you are running STK version 0.9.1? I don't see STK in their own repositories, and they say that Mint 17.2 is based on Ubuntu 14.04 (which has STK 0.8.1). I'm asking because I fixed one bug with fullscreen just before 0.9.1 release and I didn't modify anything later. So it seems strange that current git version works fine for you, but 0.9.1 doesn't.

If I understand correctly, the resolution is properly changed to 1024x768, but STK still tries to draw on a big 1600x1200 screen?

I suppose that there is something wrong with window manager or graphics drivers. I noticed something similar on Unity window manager with different games. You can try to use different window manager to run STK, for example from second tty:

{l Code}: {l Select All Code}

xinit openbox -- :1

You can also post here Xorg and STK logs:

{l Code}: {l Select All Code}

cat $HOME/.config/supertuxkart/0.8.2/stdout.log
sudo cat /var/log/Xorg.0.log
uname -a
glxinfo | grep Open


Also what is your window manager? I could try to reproduce it on my computer.

And as Auria said, maybe better try to provide us some info about the crash and we could try to fix it. If you can compile STK yourself, the backtrace from debugger would be probably very useful.

[halol]

Thanks for the feedback.

If I understand correctly, the resolution is properly changed to 1024x768, but STK still tries to draw on a big 1600x1200 screen?

=> indeed, this is what it looks like

My current window manager is cinnamon. I'll try with a different one, but I find it strange both 0.8 and the nightly build are correctly displayed with the same window manager while 0.9.1 isn't. It seems to me that the issue is more likely with 0.9.1 than with the window manager...

My current version of STK is coming from:
http://ppa.launchpad.net/stk/dev/ubuntu
Should be the released 0.9.1 as far as I can tell.

But just to be sure that the problem isn't coming from the package, I downloaded the tar.gz from the STK site: same problem.

The nightly build that I tested was coming from (64 bits version):
http://samuncle.net/wp-content/themes/samtheme/stkn.php
Since it was crashing before I could even start a race, I deleted it. I just downloaded it again to give it another try and so far so good: no fullscreen issue and no crash...

If I run into another crash I'll be sure to collect all the relevant information.

Thanks.

[deve]

This nightly build is from 10.02.2013 and is three years old It is very similar to 0.8 version that you had previously.

Since version 0.9 we are using window manager fullscreen if it's available. It allows to use alt+tab and other shortcuts, for example for volume management, so it works differently than in STK 0.8.

Do you have such problems with games which use SDL2? They generally use the same method for changing to fullscreen.

You can workaround it in a lot of ways, but you need to find the one that will work for you. You can for example write small script which changes resolution and then runs the game; or that runs STK in separate X server which has 1024x768 resolution by default.

Please attach at least stdout.log file from 0.9.1 version. It can be found in /home/user/.config/supertuxkart/0.8.2/stdout.log. If there is something wrong in STK, maybe it will say something.

[halol]

This nightly build is from 10.02.2013 and is three years old It is very similar to 0.8 version that you had previously.

OK ... now I feel so stupid!

I tested with Openbox, same problem. I also downloaded what I hope is the latest source code and compiled it. Still no luck.

See below the output that you asked for. Please note that I can recompile STK with the debug option if it helps...

{l Code}: {l Select All Code}

~$ uname -a
Linux rufus 3.16.0-38-generic #52~14.04.1-Ubuntu SMP Fri May 8 09:43:57 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

{l Code}: {l Select All Code}

~$ glxinfo | grep Open
OpenGL vendor string: Advanced Micro Devices, Inc.
OpenGL renderer string: AMD Radeon HD 6670
OpenGL core profile version string: 4.3.13416 Core Profile Context 14.501.1003
OpenGL core profile shading language version string: 4.40
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 4.5.13416 Compatibility Profile Context 14.501.1003
OpenGL shading language version string: 4.40
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile
OpenGL extensions:

The stdout and Xorg log are in the attached tar.bz2 (NB: the log is coming from 0.9.1)

[halol]

I forgot to mention, but the log was generated with the following sequence:
- start the game (windowed mode, 1024x768)
- switch to fullscreen and apply (game restarts).
- 'cancel' fullscreen by pressing Esc (game restarts).
- exit the game.

Also, I don't have the problem with LBreakout2 for example (not completely sure but I believe that it is an SDL game).

[deve]

Your logs look fine for me.

LBreakout2 uses SDL 1.2. The SDL2 uses different fullscreen method than old SDL1. It is used by a lot of commercial games (for example Half-Life 2) and some updated open-source games (for example Supertux 0.4).

Anyway I prepared a patch, which will print a bit more information to the console:
http://deve.koliber.pl/stk/fullscreen.diff
It is prepared for stable STK 0.9.1. Could you run it on your pc? If this will report wrong dimensions somewhere, then we will try to find the reason.

[halol]

Thanks for the patch.

I got an error when I tried to apply it:

{l Code}: {l Select All Code}

error: patch failed: src/graphics/irr_driver.cpp:516
error: src/graphics/irr_driver.cpp: patch does not apply

I took a closer look at irr_driver.cpp, and it looks like there is a whole section that is 'missing' in the patch compared to the source code (between CVS->init() and m_spherical_harmonics = ...). So I removed it temporarily, applied the patch and then added the missing section back... I hope that this was the correct thing to do.

The stdout.log didn't include your DBG statements so I just redirected the output to a file (attached). It should contain the relevant information. The following snippet seems to capture the problem:

{l Code}: {l Select All Code}

DBG: check if xrandr is available
DBG: xrandr is available
DBG: Change resolution to: 1024x768
DBG: Successfully changed.
DBG: Creating window with following size:
DBG:    Width: 1024
DBG:    Height: 768
DBG: Use WM fullscreen
DBG: Dimensions of already changed to fullscreen window:
DBG: Width: 1600
DBG: Height: 1200

I tried supertux (v0.4), and it turns out that I also have issues with the fullscreen mode (nothing similar to what I have with supertuxkart though, and a lot more difficult to explain: the screen is completely messed up). It looks like yamagi-quake2 is also using SDL2, I'll give it a try when I'll find some spare time.

[halol]

Just tested quake2: fullscreen is also broken... so it looks like the problem is coming from my environment rather than from the game.

[deve]

@halol Most probably yes.

I wonder what we can do to handle it in STK. It looks like resolution is changed properly and then window manager gets our fullscreen request. But when we read current window size, we get dimensions which are bigger than current screen resolution.

This function (I mean XGetGeometry(display, window, &tmp, &x, &y, &Width, &Height, &borderWidth, &bits)) is required and we can't just ignore it because we need to know real window size (without borders, etc.).

In theory we could ignore it in fullscreen mode and assume that the window size is precisely equal to our screen size (or that it can't be bigger). But again I know at least one specific case when it's not true. For example when you have two monitors at the same position:

{l Code}: {l Select All Code}

 _______________________
|              |        |
|              |        |
|      1       |        |
|              |   2    |
|______________|        |
|                       |
|                       |
|_______________________|


and (1) is your primary screen. Some window managers for some reason decide that they will resize your window to the resolution of your secondary monitor.

I will look if it can be handled in better way.

To workaround it, you can probably change line

{l Code}: {l Select All Code}

if (netWM)

to

{l Code}: {l Select All Code}

if (false)

in CIrrDeviceLinux.cpp. It will force to use old fullscreen method. If STK 0.8 works fine for you, then this hopefully should work too.

[halol]

To workaround it, you can probably change line

{l Code}: {l Select All Code}

if (netWM)

to

{l Code}: {l Select All Code}

if (false)

in CIrrDeviceLinux.cpp. It will force to use old fullscreen method. If STK 0.8 works fine for you, then this hopefully should work too.

Thanks for the suggestion. Unfortunately it doesn't fully work either: the window has the correct size (1024x768) but it is not properly positioned on the screen. It is centered on a 1600x1200 display when the actual resolution is 1024x768, so it is located in the bottom right corner of the screen and is partially off-screen.

I can move it back to the top left corner manually, or as you suggested earlier I can also start another X session with the resolution I want, so let's not loose too much time on this. The most annoying thing is simply that I haven't figured out what's broken... this will not doubt come to haunt me again later!