Linux version of The Guild of Thieves doesn't start for me any more

Comments

• stefan

  November 2019 edited November 2019

  Hi Erik,
  yes, we are aware of the problem and a Guild update is in the works. This is a conflict between the bundled Qt version and the included libs with some libs on newer distros, resulting in problems with libharfbuzz and libfontconfig.
  Will send PM with update on the matter.
  Best,
  Stefan
• eriktorbjorn

  February 2020

  I didn't notice until today, but apparently the game was updated recently and now it seems to work fine again. Thanks!
• eriktorbjorn

  February 2020

  Oh wait, I spoke too soon. We had a private discussion about a problem where the game usually hangs for me when leaving the mill, and that problem still seems to persist.
• stefan

  February 2020

  Strange. Do you perhaps still have access to the test build I sent? Actually the test build and the version on itch should be identical. Can you perhaps test again with setting the Qsg_render_loop variable to threaded?
• eriktorbjorn

  February 2020

  @stefan said:
  Strange. Do you perhaps still have access to the test build I sent? Actually the test build and the version on itch should be identical. Can you perhaps test again with setting the Qsg_render_loop variable to threaded?

  I had actually removed them, but fortunately I could recover them from a backup.

  As it turns out, the TheGuild-linux-1.3.3.9.AppImage file in my Itch directory isn't quite identical to the one you sent me. The only differences are in the TheGuild.wrapper file:

  `
  --- squashfs-root-1.3.3.9-prerelease/usr/bin/TheGuild.wrapper 2020-02-10 18:21:12.172788658 +0100
  +++ squashfs-root-1.3.3.9-itch/usr/bin/TheGuild.wrapper 2020-02-10 18:21:23.000681232 +0100
  
  {
  if [ -z "$SKIP" ] ; then
  if [ $NUMBER_OF_ARGS -eq 0 ] ; then

  • exec env QSG_RENDER_LOOP=threaded "${BIN}"

  • exec "${BIN}"
    else

  • exec env QSG_RENDER_LOOP=threaded "${BIN}" "${args[@]}"

  • exec "${BIN}" "${args[@]}"
    fi
    fi
    }
    `

  The one that sets QSG_RENDER_LOOP to "threaded" (i.e. the test build) works for me. The one that doesn't (i.e. the one on Itch) hangs.
• stefan

  February 2020

  Thanks a lot for trying. This is really strange. IIRC you have a graphics card with hardware acceleration, don't you? But it seems, for some reason Qt falls back to the basic render loop (pushing all rendering onto the cpu), although this shouldn't happen when hardware accelaration is available. Can you perhaps run glxinfo |grep render and check whether it uses llvmpipe?
• eriktorbjorn

  February 2020

  @stefan said:
  Can you perhaps run glxinfo |grep render and check whether it uses llvmpipe?

  I assume you mean the OpenGL renderer string, and not all the extensions that just happen to include the word "render" in their names:

  "OpenGL renderer string: AMD BONAIRE (DRM 2.50.0, 5.4.0-3-amd64, LLVM 9.0.1)"

  (I haven't enabled the experimental Vulkan support, though. I've been tempted, but I don't think I have anything that would need it.)
• stefan

  February 2020

  Thanks, yes. This suggests that it doesn't use llvmpipe. So actually, it should use the threaded renderer. So either the Qt docs are wrong (they say that the renderer is always threaded except for llvmpipe rendering) or there is something going wrong in Qt with detecting your renderer.
• stefan

  February 2020

  Ok, the Qt docs are a little different now since I tread them the last time: "The non-threaded render loop is currently used by default on Windows with ANGLE or a non-default opengl32 implementation, macOS with OpenGL, and Linux with some drivers. For the latter this is mostly a precautionary measure, as not all combinations of OpenGL drivers and windowing systems have been tested. At the same time implementations like ANGLE or Mesa llvmpipe are not able to function properly with threaded rendering at all so not using threaded rendering is essential for these."

  So, perhaps, your machine is using a driver that Qt defaults to non-threaded rendering.
  Hmm, I guess, always forcing the threaded renderer might cause problems on other machines. Perhaps I can add a small option to the wrapper script which enables the threaded renderer.
• eriktorbjorn

  May 2020

  I don't know if this is a clue or not, but as an experiment I turned off the Image Scaling ("Resize images to fit") setting and pulled down the picture to always be visible. (Though that doesn't seem to work quite as well has I had hoped, because if I enter a room without a picture, the picture is hidden and then I have to pull it down again later.)

  Then I tried walking back and forth between Inside the mill and Golden Wheatfield again. It doesn't hang, but sometimes when i leave the mill the picture for the Golden Wheatfield isn't shown. If I walk back into the mill again, the picture there isn't animated.

  I still get the feeling that there is some problem that's triggered by going from a room with an animated picture to one with a static picture, but I'm not familiar enough with the game to know if there are any other such cases I could easily test.

  If I leave Image Scaling on, the game still often hangs for me when leaving the mill.
• stefan

  May 2020

  Thanks for the observation. I will intensivly test this again as soon as Corona gives me a break. Guild is the only remaster so far which had original animations. Perhaps there IS something wrong with the animations. Would be much easier if I could trigger the problem somehow, but except for the high cpu usage because of the threading problem we discussed I couldn't get the program to hang. But I will have another go at it.
• eriktorbjorn

  June 2020

  @stefan said:
  But I will have another go at it.

  Is there anything I can do to help debugging it? I can compile the code from the brahman Github repository (once I figured out that the build system doesn't like if the directory it's in has spaces in its name), but I don't know where to go from there, or even if that's the way to go.
• stefan

  June 2020

  Thanks a lot for the offer! Will send PM so we can try to sort this out. Since I am cross-compiling my compiling workflow ist somewhat different than it is described in the repo