Black screen when viewing UI-centric view

I’ve encountered an odd bug in my project: on certain systems, one particular screen of the game renders an apparently solid-black screen.

If I recall correctly, I found that when I moved the mouse, the UI behind the black still responded with the expected audio-clips, indicating that the elements involved were functional, just not visible.

The screen in question is, effectively, a DirectGUI screen: it uses a variety of DirectGUI elements to compose a particular minigame.

However, there are other UI-based minigame-screens in the game, and they seem to render as expected–as far as I’ve seen only this one screen exhibits this bug.

I’ve seen it myself under Windows 8, but not under Ubuntu Linux. One other user, running Windows 10, also saw it.

In the case of my Windows installation, updating my graphics drivers seemed to help. The other user, however, reported that their graphics drivers were already up-to-date.

More strangely, that other user reported that the screen in question only blacked out when they were attempting to record it–when playing without the recording software, it was visible!

(To be specific, they were recording via Bandicam, and saw the black screen both in-game and in the recording.)

Looking at the code for the screen, I don’t see anything that looks like a potential problem: I’m not applying a custom shader, or any texture-modes, or anything like that. The most technical thing that I’m doing with the rendering, as far as I see, is applying a colour-scale to certain UI elements.

That said, it is a rather complex, multitudinous UI: a call to “analyze()” indicates that it has fully 200 nodes.

In case it’s useful, here’s the full output of calling “analyze()” on the primary root-node used by the UI:

200 total nodes (including 0 instances); 0 LODNodes.
181 transforms; 86% of nodes have some render attribute.
1 Geoms, with 1 GeomVertexDatas and 1 GeomVertexFormats, appear on 1 GeomNodes.
56 vertices, 56 normals, 0 colors, 56 texture coordinates.
GeomVertexData arrays occupy 2K memory.
GeomPrimitive arrays occupy 1K memory.
78 triangles:
  78 of these are on 12 tristrips (6.5 average tris per strip).
  0 of these are independent triangles.
2 textures, estimated minimum 2408K texture memory required.

Right now my only guess is that having so busy a UI is somehow overloading something–but that’s very much a guess.

So, any thoughts? What might be causing this…?

Hard to tell from your description alone. It would be useful to record that bit of the game using apitrace.

Unfortunately, it doesn’t seem to happen on my machine any more. I’ll ask the user to do so, I intend, however!

Update: I managed to reproduce the issue on my machine, and have made an APITrace recording:

Does the issue still happen with multisampling disabled?

I think that when I have my “antialiasing” feature disabled–which is generally the case–that multisampling is disabled. Specifically, I effectively call “setMultisamples(0)” on my “FrameBufferProperties” object when constructing my main buffer.

If that counts, then I believe that it does indeed still happen with multisampling disabled.

(However, I’ll boot into Windows quickly and check, I intend, and then edit this response with the result.)

[edit] To my frustration, the bug refused to appear when I booted into Windows. While apparently reliable on my user’s machine, it has proven quite fickle on mine. :/ [/edit]

That said, I’ve come to suspect that the problem may lie in my code. Specifically, I have code that automatically resizes the UI to fit various screen-configurations, and I think that some UI element is occasionally ending up hugely wide, thus making the UI terribly small, and leaving only (or mostly) blackness visible.

It might stem specifically from code that attempts to calculate the size of a GUI element–perhaps that’s unreliable, especially at construction-time…

There are definitely multisamples in the given trace, because I see framebuffer blit commands, which to my knowledge Panda only uses to resolve multisamples.

You’re right–I forgot to mention that when I booted into Windows to try to reproduce the issue, I found that I indeed had left antialiasing–and thus multisamples–on.

However, I also tried disabling it, to no avail. But, again, the bug refused to manifest in that session, meaning that the results of said session are perhaps not all that useful. :/