BG2EE not working on Linux

Comments

• little_duckling Member Posts: 16

  April 2016 edited April 2016

  Similar issue here for BG2EE 2.1 via Steam, but not 2.0. I have a similar Intel display controller, and the landscape is black:
  http://redmine.beamdog.com/issues/22793
  Mine:
  OpenGL renderer string: Mesa DRI Intel(R) 945GM x86/MMX/SSE2
  OpenGL version string: 2.1 Mesa 10.3.2
  Yours:
  OpenGL renderer string: Mesa DRI Intel(R) 945GME x86/MMX/SSE2
  OpenGL version string: 2.1 Mesa 10.3.2
  
  This Intel 945 line is fairly common.
  
  Were you running 2.0 or a beta? I was running 2.0 with the GraphicsBackend=0 in Baldur.lua and wasn't affected.
  
  I did see an issue with two shaders which would cause software rasterization (superduper slow rendering) if they were used with this Intel driver, explicitly unrolling their inner loops would fix that issue for the Intel driver. But those shaders weren't in use so fixing them for the Intel mesa driver didn't matter.
  
  EDIT: Oh, I see you were using 2.0.0.4 (and 1.3.2064).

  1
• little_duckling Member Posts: 16

  April 2016

  Looking elsewhere, you can try turning off the shaders in Baldur.lua:
  SetPrivateProfileString('Graphics','Shaders','0')
  
  But for me that doesn't appear to work beyond the menu. I get a segfault on a glTexImage2D call on the first in-game frame.

  1
• little_duckling Member Posts: 16

  April 2016 edited April 2016

  All right, took me a while to figure out what shaders were used during main game. I simplified fpSEAM.glsl and it works for me! I'll try to narrow down exactly what line is the issue.
  Put the attached fpSEAM.glsl in your override folder, and see if it helps your issue.
  
  OK WTF it says file not allowed. You're going to have to take off the .txt extension after downloading it.
  
  EDIT: If that doesn't help (which is a strong possibility since you said yours hadn't worked since 1.3) let me know & we can explore the other shaders. The wolfenstein analogy doesn't quite work as different games use different features/shaders. Writing shaders is difficult due to the many different cards/drivers and bugs/features/versions associated.

  fpSEAM.glsl.txt 2.6K

  Post edited by little_duckling on April 2016

  1
• Barbican Member Posts: 3

  April 2016 edited April 2016

  Wow, and I here I thought I had tried lots of things!
  
  Since my original post GOG has published two versions, 2.0.62 and 2.1.63.
  
  With 2.0.62 the game runs very slowly without fiddling with the overrides, but at least I get to see the lair and I'm able to navigate the initial conversation with Imoen. Using the modified fpSEAM.glsl doesn't seem to have any effect.
  
  With 2.1.63 the situation is back to the original (black screen), but using the modified fpSEAM.glsl speeds up things to approximately the same speed of 2.0.62.
  
  Also, maybe my post was a little misleading. I've never tried version 1.3; under "Game version" I just copied the string shown in the "gameinfo" file in the root directory, right now it shows "2.2.0.6 2.1" (even though the game itself shows "2.1.63", maybe it's a GOG thing).
  
  Tomorrow I'll try to tinker with apitrace to see whether there's something dodgy; I've just compiled it but it complains about a missing glxtrace.so. Anyway, I'm starting to fear that maybe the Linux version is not that much optimised and my computer is just not able to run it at a decent speed

  1
• little_duckling Member Posts: 16

  April 2016 edited April 2016

  With apitrace you can see any shader compilation warnings/errors by:
  apitrace trace --api gl ./BaldursGateII
  And you can exit the game after clicking through the intro movie as the shaders are compiled at startup.
  Then:
  apitrace replay BauldursGate.trace
  
  stdout of apitrace replay will show you any GLSL compilation warnings/errors. You'll see the shader program #'s. You'll need to look in the top of the dump to see which shaders those #'s correspond to. A shader program is composed of at least a vertex shader & a fragment shader, both of which will also have a #. e.g.
  vertex shader #1
  fragment shader #2
  shader program #3
  
  You'll see the text of the shaders in the dump, with the filename as a comment. You can copy that text and put them in a file in the override folder if you want to tweak with them. Only two shader programs were used during the main game rendering for me, #3 and the fpSEAM.glsl one. You may have others active if you have character outlines enabled for example (though I'm assuming you'd disabled those graphics options already).
  
  To tell which shaders were used in the main rendering loop, I made a trace just loading a game and immediately Alt+F4 exiting. grep the dump for 'glLoadProgram' to see which shaders are used. Different shaders will be used during different states of the game, e.g. intromovie, menu, main-game.
  
  Also, the Intel Mesa driver has user-space and kernel-space components (the kernel-space component is a kernel module). I'm using Debian Stable 3.16.0-4. If using debian, you can use a newer Intel Mesa driver (11.1.2 instead of 10.3.2) by upgrading to testing/unstable, or even throw unstable on a live-usb, install steam on that and 'ln -s' to your HDD's BG2EE and see if it works on your system before messing with your HDD install (actually I think BG2EE doesn't require steam to run? Try running ./BaldursGateII direct from unstable live-usb). Oh, I talk about it in the last comment on that redmine ticket if you want to look there.

  Post edited by little_duckling on April 2016

  1
• little_duckling Member Posts: 16

  April 2016 edited April 2016

  Oh, and 'ldd BaldursGateII' as a sanity check to make sure your system has all the libraries it might dynamically link to. I was initially missing libjson.so but IIRC the game ran fine without but I installed the relevant debian package anyway.
  apitrace is just one tool in the toolbox too. Looking in the debian package list:
  "intel-gpu-tools - tools for debugging the Intel graphics driver"
  I suppose you could look into that if you don't want to try upgrading to unstable's Intel Mesa.
  
  And I think this game is optimized fine and should run on your computer if we can get it not to revert to software rasterization (i.e. rendering stuff meant for GPU on the CPU). Hope that the apitrace replay gives a clue. glxtrace.so is probably in one of the libraries apitrace says to install; you don't need the optional libdwarf ones.

  1
• little_duckling Member Posts: 16

  April 2016

  Here are the explicitly unrolled fpSELECT.glsl and fpSprite.glsl files. My Intel Mesa driver had warnings with them saying software rasterization would occur if they were used. With the loops explicitly unrolled I no longer get those warnings. But these shaders weren't used when I run the game, I guess because I didn't have sprite outlines enabled. Hmm I ought to try enabling that.
  
  Try putting these in the override folder (without the .txt).

  fpSELECT.glsl.txt 4.3K

  fpSprite.glsl.txt 7.6K

  1
• little_duckling Member Posts: 16

  April 2016 edited April 2016

  Ok, I tried those unrolled ones with Sprite outlines and highlighting enabled, and I had about one game tick/frame every 4 seconds. It's clear to me now that fpSprite.glsl is associated with the black sprite outlines, and fpSELECT.glsl is associated with the sprite highlighting.
  
  In fpSprite.glsl I changed mSize from 5 to 1 (making kSize=0). I think this makes the black outline 1 pixel wide. Game appeared responsive until I highlighted someone. There was no warning about being unable to flatten the loops as the loops are essentially 'for(int x = 0; x<=0; ++x)'.
  
  In fpSELECT.glsl I changed kSize from 3 to 1. Still got a warning about the loops as they're 'for(int x=-1; x<=1; ++x)'. Unable to change kSize to 0 as the logic didn't appear to work that way (would result in a divide by zero). I guess that could be further optimized if analyzed further. Responsive now when highlighting. Explicit loop unrolling may help speed things up as I still got that warning.
  
  For your (and anyone later's) convenience, these are attached (remove the .2.txt extensions, this forum refused to allow me to attach new ones with same name so I put the .2 in there).
  
  Based on everything I've seen, I'm now guessing this Intel Mesa 10.3.2 driver and/or our hardware has an issue with too many Texture2D calls per fragment (1-2 per fragment seems ok, and seems to really slow down in the 4-25 range). This appears to be the same thing with the fpSEAM.glsl in the redmine ticket I made. Not sure if things would be better with Intel Mesa 11.1.2 and our hardware.
  
  Per your OP, you say it worked fine on Windows (with outlines enabled and OpenGL not DirectX?). If so, then it must be the 10.3.2 Intel Mesa driver being deficient and not the hardware.
  
  One optimization they could consider is, given that these are 2D sprites they're post-processing every single frame of a scene, they could move that post-processing step into pre-processing the game assets (so calculate the outline w/ 25 Texture2D calls per fragment once per sprite keyframe). I.e. ship additional sprites with the outlines/highlighting included, making use of the alpha channel. This would meet their goal of supporting older chipsets and additionally hardware that the originals would run on. I wonder if this is how ToEE implemented their blue sprite outlines?

  fpSELECT.glsl.2.txt 2K

  fpSprite.glsl.2.txt 1.7K

  Post edited by little_duckling on April 2016

  1
• Barbican Member Posts: 3

  April 2016

  little_duckling said:

  (though I'm assuming you'd disabled those graphics options already).

  Oh my, I hadn't look into the Graphic Options since my original install, and I could swear that then there wasn't any option to disable Sprite outlines and Highlighting; in fact I was surprised by the meagre number of options. I've just disabled them both and it works now! (using the modified fpSEAM.glsl that you've kindly provided).

  little_duckling said:

  you can use a newer Intel Mesa driver (11.1.2 instead of 10.3.2) by upgrading to testing/unstable, or even throw unstable on a live-usb, install steam on that and 'ln -s' to your HDD's BG2EE and see if it works on your system before messing with your HDD install (actually I think BG2EE doesn't require steam to run? Try running ./BaldursGateII direct from unstable live-usb).

  I tried the original install on Ubuntu 15.10, but I don't remember exactly which version of the driver it used ( I guess that one more recent than the one used by Jessie, though). Anyway, I'll try again (maybe using the new 16.04) and report back. I don't know about the Steam one, but at least the GOG install can be run from a Live CD without problems.

  little_duckling said:

  One optimization they could consider is, given that these are 2D sprites they're post-processing every single frame of a scene, they could move that post-processing step into pre-processing the game assets (so calculate the outline w/ 25 Texture2D calls per fragment once per sprite keyframe). I.e. ship additional sprites with the outlines/highlighting included, making use of the alpha channel. This would meet their goal of supporting older chipsets and additionally hardware that the originals would run on.

  Well, obviously I don't know about the specifics of the game engine, but that certainly makes sense.
  
  
  Thanks a lot for all the trouble, mate! You investigation into the problem was most impressive, and thanks to your posts and your redmine ticket I've learnt about some tools (like apitrace) that might come handy in the future. Let me know if I can be of any help trying anything!

  0