I played through the whole game as it currently exists in the main Steam branch with no unfixable, not already documented errors. After credits scrolled I decided to look up the status of the Xen beta to find out the full play-through had been pushed to the Open Beta branch just the day before!
I had to delete the
glshaders.cfg file to get the Beta to load.
I noticed the FPS issue at the first Xen title sequence, but the game was totally still playable for a while. I posted in Discord about it as well:
I also have the FPS issue, running
It seems to be location based. I first hit the ‘lag wall’ at the same time the chapter text Xen appears on screen, and the music starts.
If I keep walking forward when the speed returns everything is fine. If I go back into the cave I hit the lag wall all over again. And a third time when I leave the cave again
I dropped my graphics settings to as low as I could get them, and attempted to modify the
mat_queue_mode setting, but couldn’t figure out where it needed to be set.
Here’s a collection of screenshots I took with
Here’s a pastebin of everything in my console: https://pastebin.com/HsTidbBn
Here’s the status and getpos results:
] status hostname: Black Mesa version : 100001/24 100001 insecure map : bm_c4a1a at: -6382 x, -791 y, 9109 z tags : players : 1 humans, 0 bots (1 max) edicts : 2061 used of 4096 max # userid name uniqueid connected ping loss state adr # 3 "No one of consequence" STEAM_ID_PENDING 02:54 15 0 active loopback ] getpos setpos -6382.572266 -791.250793 9109.290039;setang -10.877665 82.221359 0.000000
Here’s some info about my system:
$ uname -a Linux Wheatley 4.18.0-25-generic #26~18.04.1-Ubuntu SMP Thu Jun 27 07:28:31 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
$ sudo lshw > lshw.txt
I noticed I have two Black Mesa folders in
~/.local/share/Steam/steamapps/common/. One is
Black Mesa/ and the other is
Black Mesa/ is the main folder, while
Black mesa/'s files all share a timestamp of when I updated to the Beta branch:
$ ls -al total 44 drwxr--r-- 3 aaron aaron 4096 Dec 7 21:42 . drwxr--r-- 3 aaron aaron 4096 Dec 7 21:42 .. -rw-rw-r-- 1 aaron aaron 925 Dec 7 21:42 gamestate.txt -rw-rw-r-- 1 aaron aaron 13179 Dec 7 21:42 glshaders.cfg -rw-rw-r-- 1 aaron aaron 4422 Dec 7 21:42 modelsounds.cache drwxr--r-- 2 aaron aaron 4096 Dec 7 21:42 sound -rw-rw-r-- 1 aaron aaron 0 Dec 7 21:42 stats.txt -rw-rw-r-- 1 aaron aaron 4 Dec 7 21:42 voice_ban.dt
No idea if this is intentional or related, but figured it’s worth noting
Ran another test, this time starting the game from CLI, here’s logs:
I was running HTOP at the time, the game was making use of multi-threading at first, but after hitting the wall a single core was at 100% and the rest were low util.
I noticed two
matqueue0 processes pretty high on the CPU usage list when first starting, but they seemed to disappear after the wall.
More system information–
I don’t believe this is a strict graphics driver issue; the GPU even works on [email protected]
But in case it is anyway,
$ glxinfo | grep OpenGL OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce GTX 1070 Ti/PCIe/SSE2 OpenGL core profile version string: 4.6.0 NVIDIA 430.50 OpenGL core profile shading language version string: 4.60 NVIDIA OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 4.6.0 NVIDIA 430.50 OpenGL shading language version string: 4.60 NVIDIA OpenGL context flags: (none) OpenGL profile mask: (none) OpenGL extensions: OpenGL ES profile version string: OpenGL ES 3.2 NVIDIA 430.50 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20 OpenGL ES profile extensions:
Are there other logs that might prove useful?
Should I try to capture kernel logs during a test?