ZDoom

GZDoom has a feature where when you activate the menu by pressing [ESC], the scene below takes on a yellow cast. This effect can be controlled from the Display Options->"Menu Dim" and "Dim Color" controls.

The first bug, is that the "Menu Dim" amount defaults to "-1", but the slider in the "Menu Dim" menu only ranges from 0 to 1. So the moment you make an adjustment to "Menu Dim" slider, you can not recover the default behavior, unless you go to the console [~] and type "dimamount -1". The range of this slider should be extended to include the value -1.

The second bug, is that in stereo 3D modes, the right eye view gets a dim effect in the opposite color. See the screen shot mosaic below.



The upper left panel shows the normal in-game scene.

The upper right panel is the same view, with the menu activated. Notice that the background shows the standard yellow cast. This view also shows the menu dim slider, whose range should be extended.

The lower panels show the same thing in stereo 3D side-by-side squished mode. Pay special attention to the right half of the lower right image. Instead of a yellow cast, this one is blue (the right-eye view). Properly, both eye views should instead show the same yellow cast. Notice too that the "Dim Color" in the menu is blue also. Weird.

This effect can be observed both by a) activating the menu [ESC], or by b) activating the map view [TAB]. All of the stereo 3D modes that show both eye views at once are subject to this problem.

I observed this problem in gzdoom 3.7.2, and also in a build I made from a very recent version of the master branch.

EDIT:
The blue-right-eye problem was NOT present in gzdoom version 3.3.2
The blue-right-eye problem was present in gzdoom version 3.5.1
In between, in gzdoom versions 3.4.0, 3.4.1, and 3.5.0, it's impossible to tell; the menu and map are not visible at all in these stereo 3D modes in these versions.

The right eye menu dim color is not actually the exact opposite color; it's rather got the RED and BLUE channels swapped. So maybe there's a BGR vs RGB thing going on here.

EDIT: And in addition to affecting the menu dim and map overlay, the color shift also affects the berserk pack effect [IDBEHOLDS], to be blue on the right instead of red. (I had previously tested the radiation suit effect [IDBEHOLDR], but because it's green, it looks OK).

It appears this blue-right-eye issue arose during a major 2D Drawer refactoring on March 28-29 2018.

The problem is probably here in hw_draw2d.cpp, in function Draw2D():
This works fine when Draw2D() is called just once per frame. But in stereo 3D, Draw2D() is called twice per frame. Notice that "swap" trick that is used to convert from BGRA color space to RGBA. For the second pass, the color gets swapped back to what it was originally. That's why the right eye image is red/blue swapped for effects like this.

I'm still trying to figure out what the correct solution to this problem is.

The last good commit was https://github.com/coelckers/gzdoom/com ... 100742df03
The first testable bugged commit was https://github.com/coelckers/gzdoom/com ... 9648f0ba32

The comparison of the two is here (it's big)
https://github.com/coelckers/gzdoom/com ... 9648f0ba32

Are the presentation textures being drawn as RGBA?

If so, maybe the textures should be drawn as BGRA and use a post-process shader to swap them to RGBA, instead, that way everything stays in its native format until the very last step.

It also begs the question, though: are post-process shaders being run twice in the second eye? What about the actual presentation shaders? Because if so - then that's the real issue that needs to be fixed. Presentation shaders and post-process shaders should each only be run once per screen, respectively.

Rachael wrote:Are the presentation textures being drawn as RGBA?

If so, maybe the textures should be drawn as BGRA and use a post-process shader to swap them to RGBA, instead, that way everything stays in its native format until the very last step.

It also begs the question, though: are post-process shaders being run twice in the second eye? What about the actual presentation shaders? Because if so - then that's the real issue that needs to be fixed. Presentation shaders and post-process shaders should each only be run once per screen, respectively.

Draw2D() is called multiple times during one per-eye loop in gl_stereo3d.cpp. That's what's causing this bug. After that loop is all done, there's a PresentStereo() call, which delegates to a per-stereo-mode Present() implementation, which tends to call DrawPresentTexture() multiple times. I'm not sure where the post-processing fits into all this.

In any case, I created the simplest fix I could think of, which copies the vertices before modifying them. This change could have a performance impact, but I'm guessing it's negligible. I issued a pull request here:
https://github.com/coelckers/gzdoom/pull/757

A better fix would be to set a flag and do the swapping only once.

Graf Zahl wrote:A better fix would be to set a flag and do the swapping only once.

OK. I pushed up a flag-based approach in place of the previous one. This take should have no performance impact.