A year or so back I was planning on writing a congratulatory article to show my appreciation to Dave Airlie for fixing a long standing bug in Mesa that prevented users of older AMD Radeon HD cards from enjoying Trine Enchanted Edition on the free graphics stack. Bug 91808 resulted in a variety of graphical artifacts which, while not interfering with the gameplay, still put me off using that version of Trine.
After several years and a great deal of evident frustration on his part, Airlie was able to track down the root of the problem and at long last was able to push a fix to master in May 2018. Airlie and developers like him are often the unsung heroes of FOSS development, and I wanted to give him a well deserved public pat on the back for his effort in fixing a bug which would only have affected such a small number of people.
Unfortunately my research into this led me down an entirely different rabbit hole when I discovered the report for Bug 66067. A much more subtle misrendering of the game's colours and lighting, this bug is present in both Trine 2 and Trine Enchanted Edition. Unlike the previous instance where it was an issue in the drivers that was the culprit, this issue is present in the game binaries themselves.
Trine Enchanted Edition when affected by Mesa bugs 91808 and 66067.
Unlike the proprietary vendor drivers provided by Nvidia and AMD, the free Mesa stack as a rule does not implement application specific fixes and instead adheres more strictly to the standards outlined by Khronos Group and other similar bodies. There are a number of reasons for this, mostly relating to adhering to a higher standard of code quality, and thus limiting the maintenance overhead for the FOSS developers.
In developing their games Frozenbyte made certain mistakes related to texture sampling and shadow sampling which were not technically in line with specifications, but are still accommodated for by most vendor drivers. The result is that the game will only render correctly for AMD users on Mesa when provided with specific patches that allow it to mimic the same incorrect behaviour found in the proprietary blob.
Applying these patches is nontrivial for the uninitiated, but through the use of Arch Build System I was able to spin my own Mesa packages to play through my copies of both Trine Enchanted Edition and Trine 2: Complete Story as the developer originally intended. The proper solution would be for Frozenbyte to patch their games to adhere to the correct Cg standard, but that now seems very unlikely.
Trine Enchanted Edition rendering correctly with a patched Mesa.
Frozenbyte was an early adopter of Linux, first through the porting house Alternative Games and then later through their own in-house development starting with Trine 2. The Humble Frozenbyte Bundle in April 2011 was the first Humble Bundle I ever purchased, and I got a lot of enjoyment from their games through the first half of our soon to close decade. As recently as 2016 their game Shadwen was released with full Linux support.
Since then a lot has changed over at Frozenbyte. The studio no longer has the same depth of Linux savvy programmers it once had, and following the release of Shadwen has been teaming up with publishers more intent on the console market. Its last three titles have all lacked Linux support, and with the release of Trine 4: The Nightmare Prince last month, the series is no longer fully represented on our platform.
Lacklustre Linux sales and internal restructuring following the lukewarm reception on all fronts to the third release in the franchise Trine 3: The Artifacts of Power appear to have taken Frozenbyte out of the Linux market for good. With even their old games struggling to run well on the Mesa graphics stack, it marks a sad end to a series that once provided so much colour to our platform.
UPDATE: Daniel Scharrer got in touch in the comments to provide some technical clarifications and share his LD_PRELOAD hack that solves the problem at the application rather than the driver level.
Those wanting to try the series can find Trine: Ultimate Collection on either GOG.com or Steam. Note that as stated before Trine 4: The Nightmare Prince does not currently have Linux support.
Article taken from GamingOnLinux.com.
Tip: Click to enlarge, the arrow keys to switch between them.
It honestly doesn't look terrible on Mesa, but it is absolutely worse. It was claimed in one of the bug reports from years ago that some puzzles are unsolvable from the borked colors/lighting/shadows. No idea if this is still true with today's Mesa.
Main menu background
Mesa:
Proton:
From level 1, Astral Academy (starting point)
Mesa:
Proton:
From level 2, Academy Hallways
Mesa:
Proton:
edit: added 2 more comparison image sets
Last edited by dpanter on 21 November 2019 at 10:03 pm UTC
But your GPU has supports up to OpenGL 4.5 (at least with core profiles).
[hamish@Gehirn ~]$ glxinfo | grep "OpenGL core profile version"
OpenGL core profile version string: 3.3 (Core Profile) Mesa 19.2.4
OpenGL core profile version string: 3.3 (Core Profile) Mesa 19.2.4
[hamish@Gehirn ~]$That said, I just tried launching Trine 3 with Mesa overriding the OpenGL version to 4.1 and it does work.
export MESA_GL_VERSION_OVERRIDE=4.1 MESA_GLSL_VERSION_OVERRIDE=410
./trine3.shI can also confirm that Daniel Scharrer's LD_PRELOAD hack does fix the issues with Trine 2, so I have appended it to the end of the article.
But your GPU has supports up to OpenGL 4.5 (at least with core profiles).[hamish@Gehirn ~]$ glxinfo | grep "OpenGL core profile version"
OpenGL core profile version string: 3.3 (Core Profile) Mesa 19.2.4
OpenGL core profile version string: 3.3 (Core Profile) Mesa 19.2.4
[hamish@Gehirn ~]$
That said, I just tried launching Trine 3 with Mesa overriding the OpenGL version to 4.1 and it does work.
export MESA_GL_VERSION_OVERRIDE=4.1 MESA_GLSL_VERSION_OVERRIDE=410
./trine3.sh
I can also confirm that Daniel Scharrer's LD_PRELOAD hack does fix the issues with Trine 2, so I have appended it to the end of the article.
Me bad, you're one tier down: https://www.phoronix.com/scan.php?page=news_item&px=R600g-OpenGL-4.5-Hits
I would say this story is a good example of the benefits we could have from games being FOSS.I had thought of mentioning this, but I could really turn this topic into an article in and of itself.
The original Unreal Tournament is stuck with a similar issue on Mesa that makes the old native build unable to launch. Enemy Territory: Quake Wars is plagued with the wchar bug when using modern versions of glibc.
Playing both of these games through WINE is now often easier than doing so natively, due to it being a stable environment. Both modern Windows and Linux are moving targets.
Frozenbyte released some of its source code in the past as part of the Humble Frozenbyte Bundle, although I doubt they are likely to do so again any time soon.
I just tried the old Enemy Territory: Quake Wars demo on an updated Arch and it works fine. Some bad screen tearing though.
I may not have read the article well enough, but Trine and Trine 2 renders fine on my system with Mesa Aco. I guess there are fixes not in a release yet?
It renders fine, but there seems to be some subtle issues with lighting, as hinted in the screenshots a few posts above yours :)
@Desum, I thought only YoRHa-2B could use that profile pic :P
Last edited by MayeulC on 21 November 2019 at 6:02 pm UTC
I may not have read the article well enough, but Trine and Trine 2 renders fine on my system with Mesa Aco. I guess there are fixes not in a release yet?
I just tried the old Enemy Territory: Quake Wars demo on an updated Arch and it works fine. Some bad screen tearing though.I am going to reply to both of you here since the question I would put to both of you is the same. Are you sure you are not being affected? For both games the problems are subtle and hard to spot at first.
dpanter posted some comparison shots that do a good job showing some of the rendering differences in Trine, while with ET:QW the easiest to spot issue is that text strings will be missing their final character. Which, while annoying, would not be that much of a problem if it were not for the fact that the same bug causes segmentation faults under certain conditions.
What is really vexing with ET:QW is that it is not even really a bug in the game itself, but in the old GCC compiler that was used to build it. Just rebuilding the game on a modern setup would solve the issue.
Installed Trine 4 here, but the game still locked at 30fps. Uninstalled.I can not speak for Trine 4 exactly, but in the other Trine games there was a toggle for controlling the FPS cap in the game settings, which by default is set to 30 FPS.
I can't help but wonder if the texture resolution and/or filtering is the same between the versions, even with the exact same settings. Can all these differences be attributed to the lighting alone?
Wait, I'm confused. Is dscharrer's fix only needed for Trine 1 and Trine 2 or also for Trine 3?Just the first two Trine games. I needed to override the OpenGL version to run Trine 3, but that was very specific to my generation of graphics card. Daniel's fix is needed to render Trine and Trine 2 correctly on all AMD cards using Mesa and the free graphics stack.
Thanks for clearing that up! :)Wait, I'm confused. Is dscharrer's fix only needed for Trine 1 and Trine 2 or also for Trine 3?Just the first two Trine games. I needed to override the OpenGL version to run Trine 3, but that was very specific to my generation of graphics card. Daniel's fix is needed to render Trine and Trine 2 correctly on all AMD cards using Mesa and the free graphics stack.
user@debian:~$ glxinfo | grep -i opengl
OpenGL vendor string: X.Org
OpenGL renderer string: AMD CAYMAN (DRM 2.50.0 / 5.3.0-3-amd64, LLVM 9.0.0)
OpenGL core profile version string: 4.3 (Core Profile) Mesa 19.2.6
OpenGL core profile shading language version string: 4.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.1 Mesa 19.2.6
OpenGL shading language version string: 1.40
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 19.2.6
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10
OpenGL ES profile extensions:
user@debian:~$user@debian:~$ apt-cache policy gcc-multilib libgl1-mesa-dev libgl1-mesa-dev:i386 pkg-config
gcc-multilib:
Installed: 4:9.2.1-3.1
Candidate: 4:9.2.1-3.1
Version table:
*** 4:9.2.1-3.1 500
500 http://ftp.ca.debian.org/debian bullseye/main amd64 Packages
100 /var/lib/dpkg/status
libgl1-mesa-dev:
Installed: 19.2.6-1
Candidate: 19.2.6-1
Version table:
*** 19.2.6-1 500
500 http://ftp.ca.debian.org/debian bullseye/main amd64 Packages
100 /var/lib/dpkg/status
libgl1-mesa-dev:i386:
Installed: 19.2.6-1
Candidate: 19.2.6-1
Version table:
*** 19.2.6-1 500
500 http://ftp.ca.debian.org/debian bullseye/main i386 Packages
100 /var/lib/dpkg/status
pkg-config:
Installed: 0.29-6
Candidate: 0.29-6
Version table:
*** 0.29-6 500
500 http://ftp.ca.debian.org/debian bullseye/main amd64 Packages
100 /var/lib/dpkg/status
user@debian:~$For both Trine 1 and 2, I put a copy of the trinefix.c file in the same directory as the trine1.sh and trine2.sh files and set the Properties --> Set Launch Options to "sh trinefix.c %command%" (without the quotes).
Doing so doesn't visually start anything (unlike when I remove the "sh trinefix.c %command%" (without the quotes) from the Properties --> Set Launch Options window). However, using Task Manager, I see three processes: "sh -c trinefix.c '/home/user/.steam/debian-installation/steamapps/common/Trine/_enchanted_edition_/trine1.sh'" (without the outermost (double) quotes), "trine1.sh" (without the quotes) and "[trine1.sh]" (without the quotes). They are each apparently using 0% of my CPU and 24.5 MiB, 7.1 MiB and 0 bytes, respectively.
I also noticed that there are trinefix directories in the Trine 1 and 2 directories, each with a 32 and 64 bit subdirectory, each with a trinefix.so file in there, so at least something seems to be getting done.
Did I do something wrong? Is the comment in trinefix.c about which dependencies I need to install missing some dependencies? If so, which one(s)?
If someone could help me out with this, I would really appreciate it!
cd "~/.steam/debian-installation/steamapps/common/Trine/_enchanted_edition_/"
sh trinefix.c ./trine1.shThat works for me with the Humble Store versions I was using.
Last edited by Hamish on 5 January 2020 at 3:49 am UTC
Try launching the game outside of Steam by changing into the directory and launching the game from a terminal like so:Thanks again for the response.
cd "~/.steam/debian-installation/steamapps/common/Trine/_enchanted_edition_/"
sh trinefix.c ./trine1.sh
That works for me with the Humble Store versions I was using.
I didn't occur to me to run it from outside of Steam, but it's good that you said that because now I have an error message.:
user@debian:~/.steam/debian-installation/steamapps/common/Trine/_enchanted_edition_$ cd ~/.steam/debian-installation/steamapps/common/Trine/_enchanted_edition_/
user@debian:~/.steam/debian-installation/steamapps/common/Trine/_enchanted_edition_$ sh trinefix.c ./trine1.sh
[trinefix] attached to sh: 0x7f6a4c55a3b0 (nil) (nil) (nil)
[trinefix] attached to mkdir: 0x7fb91f2a53b0 0x7fb91f2a5490 (nil) (nil)
[trinefix] attached to readlink: 0x7f64dce143b0 (nil) (nil) (nil)
[trinefix] attached to dirname: 0x7f9297e023b0 (nil) (nil) (nil)
[trinefix] attached to chmod: 0x7faf3ee403b0 (nil) (nil) (nil)
./bin/trine1_linux_launcher_32bit: error while loading shared libraries: libgtk-x11-2.0.so.0: cannot open shared object file: No such file or directory
user@debian:~/.steam/debian-installation/steamapps/common/Trine/_enchanted_edition_$Do you know how to deal with that, by any chance?
https://packages.debian.org/buster/libgtk2.0-0
EDIT: And make sure you have the i386 package since it is a 32-bit application.
Last edited by Hamish on 6 January 2020 at 3:55 am UTC
Patreon
PayPal
See more from me