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.
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.ibm5155 wrote: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
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.