DaemonEngine / Daemon

The Dæmon game engine. With some bits of ioq3 and XreaL.
https://unvanquished.net
BSD 3-Clause "New" or "Revised" License
296 stars 60 forks source link

Rendering breakage when using GL hacks like mumble-overlay or simplescreenrecorder GL capture #499

Open illwieckz opened 3 years ago

illwieckz commented 3 years ago

This is a regression as both usages worked well in 0.51.

Those GL hacks are expected to mess with OpenGL so at some point we may expect bugs, but it worked properly on 0.51. Also such usage is not rare, for example Steam comes by default with an overlay so games are expected to not break with such kind of usages.

Mumble Overlay

If you use the mumble overlay (mumble-overlay ./daemon), you get those graphical problems:

mumble overlay breakage

mumble overlay breakage

mumble overlay breakage

mumble overlay breakage

mumble overlay breakage

mumble overlay breakage

mumble overlay breakage

mumble overlay breakage

mumble overlay breakage

The fonts and UI things are weirdly rendered, the depth is broken, and the minimap scale is wrong.

SimpleScreenRecorder

If you use SimpleScreenRecorder OpenGL capture, other errors are seen, including GL error logs:

simplescreenrecorder gl capture breakage

simplescreenrecorder gl capture breakage

simplescreenrecorder gl capture breakage

simplescreenrecorder gl capture breakage

simplescreenrecorder gl capture breakage

For the first screenshot with SSR, the OpenGL capture was started after the map was loaded, and the map looks good but there are many error logs. As soon as a map is loaded after GL capture is started, the render is garbage, even sometime completely black.

Tip: you can run a terminal as application to capture with GL in SSR, so, when you start the real GL application from that terminal, the GL capture works. This is handy for debug builds with options you want to set by command line.

illwieckz commented 3 years ago

With mumble-overlay I reproduce the bug with those configs:

GL_VENDOR: NVIDIA Corporation
GL_RENDERER: Quadro K1100M/PCIe/SSE2
GL_VERSION: 3.2.0 NVIDIA 390.143
GL_SHADING_LANGUAGE_VERSION: 1.50 NVIDIA via Cg compiler
GL_MAX_VERTEX_UNIFORM_COMPONENTS 4096
Using GPU vertex skinning with max 233 bones in a single pass
GL_VENDOR: AMD 
GL_RENDERER: AMD Radeon (TM) R9 390 Series (HAWAII, DRM 3.38.0, 5.8.0-59-generic, LLVM 11.0.0) 
GL_VERSION: 4.6 (Core Profile) Mesa 21.0.1 
GL_SHADING_LANGUAGE_VERSION: 4.60 
GL_MAX_VERTEX_UNIFORM_COMPONENTS 16384
Using GPU vertex skinning with max 256 bones in a single pass 

But not this one:

GL_VENDOR: Intel Open Source Technology Center
GL_RENDERER: Mesa DRI Intel(R) 965GM (CL)
GL_VERSION: 2.1 Mesa 20.0.8
GL_SHADING_LANGUAGE_VERSION: 1.20
GL_MAX_VERTEX_UNIFORM_COMPONENTS 16384
Using GPU vertex skinning with max 256 bones in a single pass
ghost commented 2 years ago

I investigated a bit today, bisecting around gave no result at all or, to be exact, every builds since 0.50 was broken, including 0.50. Before the older point, I could not get things to build anyway (broken deps).

What did shown some useful result though is, recompiling 0.51.2's daemon gave the same problem, so I think it is very likely related to something in one of the libraries.