supertux
supertux copied to clipboard
OpenGL 2.1 hardware: SuperTux fails to load with "X connection to :0 broken (explicit kill or server shutdown)"
SuperTux v0.6.2 (Ubuntu PPA), v0.6.3 (official AppImage)
test@iMac-4:~$ inxi -b
System: Host: iMac-4 Kernel: 5.13.0-35-generic x86_64 bits: 64 Desktop: KDE Plasma 5.18.8
Distro: Ubuntu 20.04.4 LTS (Focal Fossa)
Machine: Type: Desktop System: Apple product: iMac5,1 v: 1.0 serial: <superuser/root required>
Mobo: Apple model: Mac-F4228EC8 v: DVT serial: <superuser/root required> BIOS: Apple
v: IM51.88Z.0090.B09.0706270921 date: 06/27/07
CPU: Dual Core: Intel Core2 T7400 type: MCP speed: 1572 MHz min/max: 1000/2167 MHz
Graphics: Device-1: Advanced Micro Devices [AMD/ATI] RV530/M56-P [Mobility Radeon X1600] driver: radeon v: kernel
Display: x11 server: X.Org 1.20.13 driver: radeon FAILED: ati unloaded: fbdev,modesetting,vesa
resolution: 1680x1050~60Hz
OpenGL: renderer: ATI RV530 v: 2.1 Mesa 22.1.0-devel (git-177805c 2022-03-13 focal-oibaf-ppa)
Network: Device-1: Marvell 88E8053 PCI-E Gigabit Ethernet driver: sky2
Device-2: Broadcom and subsidiaries BCM4360 802.11ac Wireless Network Adapter driver: wl
Drives: Local Storage: total: 232.89 GiB used: 131.14 GiB (56.3%)
Info: Processes: 182 Uptime: 1d 21m 05m Memory: 2.90 GiB used: 1.07 GiB (36.8%) Shell: bash inxi: 3.0.38
Expected behavior
SuperTux should work also at OpenGL 2.1 ~~and OpenGL ES 1.0~~ class hardware. Update: The Debian SuperTux page containing the OpenGL ES 1.0 compatibility is outdated.
Actual behavior
SuperTux doesn't launch always when started from terminal, in my case it fails with X connection to :0 broken (explicit kill or server shutdown).
However, for whatever reason it is possible to start SuperTux via the shortcut in the Start menu when it is installed via the official Ubuntu PPA. For me this works in 9 of 10 times.
Steps to reproduce actual behavior
Starting SuperTux on modern systems with reduced OpenGL version MESA_GL_VERSION_OVERRIDE=2.1 will show the mentioned incompatibility.
Additional debugging information
It is unclear if this is a building problem of SuperTux or a problem in Mesa. According to the corresponding Mesa bug report 6143 the following warning message appears:
[WARNING] /build/supertux-T63d5E/supertux-0.6.2/src/video/video_system.cpp:52 Error creating GLVideoSystem-330core, using GLVideoSystem-20 fallback: GLVideoSystem: GlewError: Missing GL version
SuperTux does not support OpenGL 1.0.
If OpenGL causes problems, a temporary solution can be to launch SuperTux with --renderer sdl. This will run the game properly, although some minor effects, like empty bonus block reflections and water refraction, won't work.
Hi Semphriss and thanks for this useful information.
It really works with supertux2 --renderer sdl from the command line. :+1: And this is true for both version, SuperTux v0.6.2 (Ubuntu PPA) and v0.6.3 (official AppImage).
So what do you think, where is the root of problem, is this a building issue of SuperTux or a problem in Mesa?
~~PS OpenGL ES 1.0 is the mobile variant of OpenGL 2.1 and therefore the feature-set should be similar. Ergo, my old ATI RV530 based GPU is OpenGL 2.1 compatible and on the same time also OpenGL ES 1.0.~~
Update: My assumption seems to be wrong. OpenGL 2.1 is more similar to OpenGL ES 2.0, and the Debian page below is outdated.
I have found this SuperTux OpenGL ES 1.0 information at the following Debian SuperTux page here.
SuperTux should support every version of OpenGL through the SDL renderer, which provides the necessary compatibility; normally, when SuperTux is launched, it tries to load the OpenGL 3.3 renderer, then the OpenGL 2.0 renderer, then the SDL renderer. However, this expects any of the former renderers to fail gracefully, which doesn't necessarily always happen, so SuperTux crashes (or fails in some way) and we need to instruct people to launch the game from the CLI with --renderer sdl.
I'm afraid this is all the expertise I can provide. I'm not really familiar with OpenGL compatibility, so someone else should look into it.
I don't believe this is a device issue; SuperTux has plenty of issues with OpenGL that don't happen with any other game, so the issue is probably on our end. But given that most problems happen with little to no description, it's very difficult for us to trace back to the root of the problem. If you know somebody who is familiar with OpenGL and who would be ready to do some debugging, and let us know what the issue is, we would gladly accept a fix.
If you're familiar with debuggers and you want to give it a try (but I'm not sure if it'd work), you could try compiling from source and add -DCMAKE_CXX_FLAGS-ggdb to the CMake command, and try to run SuperTux in gdb and see if you can get a stack trace; that would give us a head start.
For the record, SuperTux is working from CLI also perfectly well when it is launched with --renderer opengl20. :+1:
However it doesn't work for me with parameter --renderer opengl and --renderer auto. With these parameter I get again the X connection to :0 broken (explicit kill or server shutdown) error.
So it looks that this topic is not really a "typical" OpenGL problem, for me this looks more like an issue in the "fallback mechanism" of SuperTux.
Could you check if #2186 fixes fallback issue? You can get binaries here: https://github.com/SuperTux/supertux/actions/runs/2017569332
Great, the ubuntu-latest-64-gcc-Release-appimage build works now perfectly well! :1st_place_medal:
So this new OpenGL fallback variant has solved the problem, thanks! :+1:
By the way, I tried also the glbinding appimage but this one fails. However, maybe this should effecively fail on lower OpenGL based systems, output is:
test@iMac-4:~/Downloads/SuperTux$ ./SuperTux-v0.6.3-522-g449c7b4bf.glibc2.29-x86_64.AppImage
supertux2: /build/glbinding-3fpaYH/glbinding-2.1.1/source/glbinding/source/AbstractFunction.cpp:58: glbinding::AbstractFunction::State& glbinding::AbstractFunction::state(int) const: Assertion `pos > -1' failed.
Error: signal 6:
supertux2(_ZN12ErrorHandler17print_stack_traceEv+0x2f)[0x555f11f8f85f]
supertux2(_ZN12ErrorHandler12handle_errorEi+0x3b)[0x555f11f8f8eb]
/lib/x86_64-linux-gnu/libc.so.6(+0x430c0)[0x7fe2bb3bc0c0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcb)[0x7fe2bb3bc03b]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x12b)[0x7fe2bb39b859]
/lib/x86_64-linux-gnu/libc.so.6(+0x22729)[0x7fe2bb39b729]
/lib/x86_64-linux-gnu/libc.so.6(+0x34006)[0x7fe2bb3ad006]
/tmp/.mount_SuperTQRGuvU/lib/x86_64-linux-gnu/libglbinding.so.2(+0x1e7526)[0x7fe2bbb31526]
/tmp/.mount_SuperTQRGuvU/lib/x86_64-linux-gnu/libglbinding.so.2(_ZNK9glbinding16AbstractFunction7addressEv+0xd)[0x7fe2bbb3162d]
/tmp/.mount_SuperTQRGuvU/lib/x86_64-linux-gnu/libglbinding.so.2(+0x2b4d47)[0x7fe2bbbfed47]
supertux2(_Z14check_gl_errorPKci+0x33)[0x555f11fe31c3]
supertux2(_ZN13GLVideoSystem17create_gl_contextEv+0x3d)[0x555f11fe1b1d]
supertux2(_ZN13GLVideoSystemC2Ebb+0x58)[0x555f11fe2e88]
supertux2(_ZN11VideoSystem6createENS_4EnumE+0xd9)[0x555f11e59fc9]
supertux2(_ZN4Main11launch_gameERK20CommandLineArguments+0x179)[0x555f11dc5699]
supertux2(_ZN4Main3runEiPPc+0x393)[0x555f11dc72a3]
supertux2(main+0x4e)[0x555f11d0d6ce]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x7fe2bb39d0b3]
supertux2(_start+0x2e)[0x555f11d4118e]