Two Issues I'm Having With GZDoom v2.3.2

[NiTROACTiVE]

Hey guys, I'm having two issues with GZDoom v2.3.2.

First off, I'm getting too much information from the linetarget as of this version. I just want certain information, and the picture below shows what I want:



There's much more info from the bottom part of the image that couldn't be seen on the screen just so you know.

Secondly, whenever the screen melts to a different screen/level, it goes black, meaning you can't see the last image of the level/screen as the screen melts when you complete a level. There's even times where the screen will freeze to that image until it's done melting.

How can I fix these issues?

[Graf Zahl]

The linetarget issue has already been addressed for the next version.

The second one is something I have never seen, it works fine for me. What graphics hardware do you use?

[Erick194]

NiTROACTiVE said:

Secondly, whenever the screen melts to a different screen/level, it goes black, meaning you can't see the last image of the level/screen as the screen melts when you complete a level. There's even times where the screen will freeze to that image until it's done melting.

This happens to me as well, but seeing the source code I added these lines and it works well.

It depends on Graf Zahl wether he wants to add it or not

[Graf Zahl]

I wasn't even aware there was a bug. Can you make a pull request out of this?

[Erick194]

Yes, You can use the code, there's no problem. It depends on you.

[dpJudas]

Grabbing the code out of a screenshot is not what Graf had in mind I'm sure. :)

Anyhow, the code shouldn't be calling mBuffers->BindCurrentFB() when FGLRenderBuffers::IsEnabled() returned false. That is not an allowed call in that situation (no render buffers, no post processing render buffers can be bound).

[Graf Zahl]

_mental_ already committed a fix for this.

[Erick194]

Of course, I understand what you say but if it is not made in this way, the same problem will be there. I also have another alternative, I think there's not much difference

The Idea is fixing the bug, right?

I just downloaded the gzdoom-g2.4pre-799-g5d3244c version and it is still having the same bug, I think you missed to type GLRenderer->mBuffers->BindCurrentFB();

else if (gl.legacyMode)
{
     GLRenderer->mBuffers->BindCurrentFB();
     copyPixels();
}

[dpJudas]

Erick194 said:

The Idea is fixing the bug, right?

Yes, but if the fix doesn't deal with the true cause of the bug it will eventually break again. In this case, there's two modes of operation:

1) Render buffers are enabled and the creation of all render buffers succeeded. This is indicated by FGLRenderBuffers::IsEnabled() returning true. Post processing is available and its code paths are to be used.

2) Render buffers are not available. No render buffer textures or frame buffer objects exists. No further communication with mBuffers is allowed unless another mBuffers->Setup call re-enables render buffers.

What's important about this is that calling BindCurrentFB() under those conditions results in undefined behavior. You just happens to be so lucky that I keep a strict policy of clearing my handle variables to zero so that your line effectively means glBindFramebuffer(GL_FRAMEBUFFER, 0).

Now the real question is why do you need to explicitly bind the default FBO at this point? Either something elsewhere failed properly restoring the frame buffer binding, or that is expected behavior in the legacy code paths and what is missing is a call to glBindFramebuffer(GL_FRAMEBUFFER, 0), not mBuffers->BindCurrentFB().

[Erick194]

Forget about what I posted about the GZDoom I downloaded yesterday. I just downloaded The gzdoom-master, I compiled it and the bug is not there.
Checked in gzdoom-g2.4pre-812-g21ecd7 version