GzDooM pre-1905 + Black screen

[dpJudas]

Thanks for testing.

For AMD: When you resize the window gzdoom recreates the frame buffer objects with the new dimensions. It seems the initial frame buffer creation has the 'black screen' effect - why I'm not sure.

For Intel: I have no idea why the title background is black when you can see game menus and the credits image. Possibly some Begin2D state artifact - see below.

Dj, can't you just add a resize call when playing in windowed mode and a change resolution call when playing in fullscreen mode? this way you'll fix all these weird stuff :p

The problem is that the zdoom codebase dates back to 1993. In the DOS age writing to video memory was just something you did whenever you felt like it, and the zdoom codebase as a result inherited a very unhealthy attitude to who draws on the screen. There are 10 different places where things might call a function called Begin2D that basically says "oh btw I'd like to draw something now kthxbye!" without any regard to whether we are drawing in 3D (player sprites) or 2D, to a texture, screen, taking a screenshot, a save game thumbnail, or a wipe effect. Sometimes the call might not even be needed but called "just in case" or as a hack to make sure certain render states were initialized.

I could perhaps get around the key issue by applying another hack ala what you're describing, but it just means something will break again the next time some poor soul even glances at this part of the code. It might take a little longer time and more pain, but the root causes for this needs to be dealt with - and that's what I'm trying to do. Basically I'm starting to realize that FGLRenderer needs to know what we are rendering much better than it does today, so that a call to Begin2D doesn't have to second guess what viewport box it needs to use.

[Graf Zahl]

I think it's time to really clean that up, unfortunately it will take quite a bit of testing to weed out the unneeded Begin2D calls. That whole stuff got added when ZDoom got its D3D backend and the hardware accelerated 2D drawer, but instead of defining it cleanly it was more or less hacked in, because it was convenient. Needless to say, it has been a cause for trouble in GZDoom ever since - and is part of the reason why some things had to be done rather hackishly.

[dpJudas]

I can do that if you'd like. The only catch is that such work probably needs to start in the zdoom codebase first. Right now I'm trying to add a temporary workaround in FGLRenderer to fix what we have in gzdoom, but after that I can start the more fundamental video fixes in zdoom.

[ibm5155]

I don't know if that's going to help with anything but, I'm playing/breaking the Begin2D function and seeing what's going on

---

Testing the void FGLRenderer::Begin2D() from gl_renderer.cpp
result 1: blocking the first 3 calls to be executed resulted in an inverted doom 2 background image, but The frame wasnt updating, resize doesn't fixes the image.
result 2: blocking the first 50 calls resulted in a red screen, after some seconds the doom 2 background image is showed and nothing more can be done (if I start a new game I can only see a black background), but, if I start a new game while the red background is showed, the game actually start and everything Works just fine.
result 3: the less blocks I do, the less time the red background stays at the screen.0
result 4: blocking the first 50 calls but allowing the (first or second or third) call resulted in a black screen, but if resized I could see and operate everything..
result 5: blocking the first 500 calls but allowing the 4th call resulted in an inverted doom 2 background image, resizing the window would do nothing.
result 6: all the previous results also happens with the intel GPU BUT, instead of a red background color it's a black background instead, it requires at least one of the first 3 calls to be made for making the game Works just fine (ex: call 0 , ignore 1, ignore 2 do the rest), if you jump the first 3 calls you'll only see an inverted doom 2 background image and you could do nothing about it...
-I cannot do nothing when I see the inverted doom 2 background image.

I belive it's an start, at least the problem is related to some of the first 3 Begin2D calls

[Akiradlc]

Just tested with version g2.2pre-2013-g4e8a96a on my Radeon 7790 and latest Crimson drivers: black screen output still persists, plus i got black lines randomly that appear and stay in the screen from times to times.
Complete restart get rid of the lines until they appear again...

On the notebook integrated Intel, just black screen some times, no black artifact lines apparently. Though i did not played too much on the notebook.

[Akiradlc]

Happy to say the black screen at start bug is gone for me with build g2.2pre-2021-gac80ffc (opened it about 80 times in a row just to test if it were going to happen at all), but the persistent black lines still there. Some buffer management error maybe?

In the screenshot there are only two, but the more time you play, more of them eventually appear and stay stuck in the screen.

[dpJudas]

That is great news, Akiradlc!

I have a theory the black lines might be because of shaders generating NaN values. There seem to be differing behavior between vendors on how they react to that (especially with regard to blend operations): http://stackoverflow.com/questions/9446 ... gl-shaders

The easiest way to test this theory is to stop using floating point render buffers. Basically switch from GL_RGBA16F to GL_RGBA16. As gzdoom doesn't really generate any overbright values today there shouldn't be any need for floats (yet). I'll compile a PR changing this in a couple of hours.

Based on earlier reports from ibm5155 I suspect one of the shaders doing this might be the fuzz shader, although I certainly can't rule out my post processing shaders until I've carefully studied them.

[ibm5155]

I tried the build gzdoom-g2.2pre-2021-gac80ffc but the screen remains black '-' (at least only in fullscreen mode now nop)
Also, some interesting happening that I saw.
I started gzdoom in windowed mode, I changed my default vídeo adapter and then I pressed alt+enter, the result wasn't a black screen, but I could only view the last frame before the screen went into fullscreen mode :S
....
You may see those lines when you view some transparent (spectre) object (I didn't tested it now but if you look at the map those lines will go out the screen.
EDIT: maybe the same is happening with fullscreen mode, but since there last "valid" frame is black, it only shows black (why do I continue to do guessing since Idk almost nothing about gl )
EDIT2: I tried to run it again, and nop, it's not working again in neither windowed and fullscreen mode D:
EDIT3: the weird lines with intel here are actually working, BUt at the first try, the map is just black but I can see the transparent objects, if I reload the map it does nothing, unless I load another map and then the map with the transparente objects...
heck, this opengl game is crazy

EDIT4: changing GL_RGBA16F to GL_RGBA16 fixed those black lines/dots on amd
EDIT5: now gzdoom decided to work in windowed and fullscreen mode with the amd gpu... (for intel there's only missing the menu background in fullscreen mode and the other map...)
LAST EDIT: sometimes it just decides to not work (when I change the resolution), and that affects gzdoom even if I close it and open it again...

[dpJudas]

Pull request: https://github.com/coelckers/gzdoom/pull/81

Changes the format from RGBA16F to RGBA16. We don't need the floating point part for the moment and it ensures we cannot possibly get any NaN values in the buffers. Also updated all the post process shaders to make sure they will never try to do a sqrt or pow of negative values.

One interesting aspect I noticed is that if contrast is set really high then it would certainly have attempted to do a pow of a negative value. This problem is present even in the original code I used as basis for the present shader: https://github.com/coelckers/gzdoom/blo ... r.cpp#L251. If contrast is 3.0f then the val passed into pow will be -254 when i = 0.

I fixed this in the shader by adding a val = max(val, 0), but left it as-is in DoSetGamma. I wonder if there could be a connection between this and some of the complaints about hardware gamma not working for everyone?

[Akiradlc]

Complementing my last post about the build g2.2pre-2021-gac80ffc:
Just tried it on the HD 4000 notebook, it just does not run in fullscreen, no matter what i do.
Tried switching in-game menu, editing the ini file, alt-enter shortcut, nothing makes it run in fullscreen. It goes to fullscreen but only with sound, the screen stays black.
Windowed it works normally, can play without problems, and apparently (not 100% sure cause did not spent too much time playing to test) the black lines does not happen. Maybe it's a AMD only glitch?

Also, but not related to topic: just tried the vid_maxfps cvar in the notebook because with vsync the game stutters horribly, and without it the fps goes to 200+ making the notebook go supernova temperatures and the fan to spin in max like a turbine. It just did not work, made it vid_maxfps 60 to cap the fps to 60 but it still goes all the way up to 200 and so on. Is it deprecated or broken?

[dpJudas]

Try turn off hardware gamma for full screen - does that make any difference? You could also try the next build (when it shows up) - it contains some shader changes that makes absolutely sure all buffer values stays within acceptable ranges.

About vid_maxfps: I haven't changed anything related to this or how it swaps the default frame buffer. Graf probably has a better idea about that one than me.

[Graf Zahl]

vid_maxfps is not implemented for OpenGL, i.e. at best it just inherits some functionality from the software renderer. Try setting vid_vsync to 1 instead.

[Akiradlc]

Try setting vid_vsync to 1 instead.

It's what i use on my PC, the Radeon can more than handle it, but on the notebook's Intel it becomes a stuttering mess with vsync, even it being able to produce more than 200 fps without any frame cap and the vid_fps cvar showing constant 60.
This is probably the Intel drivers or performance problem, if i enable a mere 2x AA for example the fps fluctuates wildly with no apparent reason to.
It's a weak GPU and probably a isolated case of bad chip/driver performance, plus chances are i am to blame my OS state or even the notebook's internal components age showing.

Back on topic: sad to say that the black screen at start happened in my Radeon today with build g2.2pre-2021-gac80ffc. I said it was not happening (it indeed did not happen in my 80 inits trial run), but it now seems it just became really hard to occur, but do at some point.
Going to try the new g2.2pre-2024-g0e2d9af build and see.

[Graf Zahl]

Yes, that's an Intel problem. I noticed similar issues on my system when I activated its HD 4000 to do some tests. When VSync is on it always waits for the next vertical blank, and often this means that the game switches between 30 and 60 fps.

[Akiradlc]

Reporting: Apparently i have no more display issues with build g2.2pre-2024-g0e2d9af on my Radeon. Completed chapter 1 of Doom, plus opened and closed GZDoom more than a hundred times while making and tweaking two mods of mine (creating your own hud is very exhaustive when you can't live preview how things are coming up in-game (write, save, open, test, close, repeat...).

As for the Intel, i still can't make it run in fullscreen, no matter what i try. Windowed works just fine (even enabling tonemapping and antialiasing), but fullscreen is simply impossible on the notebook.
Anyone else having the same issue with Intel gpus?