Set any kind of LB resolution (found in 16:9 aspect ratio menu) and you'll see hom where the statusbar is.
It's not showing under the image, but I belive the hud is trying to be rendered below the screen (because I see the hud burder, and a hom where the hud should be, but for some reason the screenshot didn't registered that área)
EDIT: It does't happen in windowed mode, only fullscreen
No. It's a 16:9 screen letterboxed on a 4:3 screen. And from the image it looks like some value is still from that 4:3 screen which causes the status bar to be drawn in the wrong place.
I'm not sure I fully understand. Let's say I've selected 1920x1080 LB in the menu options and gone full screen. What physical monitor resolution does it mode switch to? What should the viewport size be for the scene and what should it be for the 2D/screen?
Okay, got it. For windowed mode it stays at 1920x1080, and for fullscreen the "true height" becomes 1440. Makes me wonder if I should try get rid of GetTrueHeight() entirely as the present shader code letterboxes it automatically.
What I mean is the GetClientHeight function I added to the video classes makes GetTrueHeight redundant. I think I can reduce the entire thing into calculating two viewport boxes (mScreenViewport and mSceneViewport) and then deal with the letterboxing exclusively in the CopyToBackbuffer function.
I've changed it so that FGLRenderer::SetOutputViewport calculates where all the gzdoom glViewport locations are. It outputs three rects:
mOutputLetterbox - The final location in the back buffer where the game is rendered. For LB resolutions it will be located so there's a black bar above it and below. For non-LB it should be covering the entire back buffer. For windowed mode it is located so there might be bars to the left and right instead, depending on how the user sizes the window.
mScreenViewport - The location where gzdoom renders 2D. It has the values that glViewport needs to cover the entire screen.
mSceneViewport - The box where the scene is rendered.
To fix the map lines issue I've changed it so that the screen is up scaled during rendering rather in CopyToBackbuffer. I've added a debug gl_scale_viewport cvar that can be set to false to enable the old behavior.
The PR also fixes the post processing bug ticket. The bloom pass was grabbing pixels from non-scene parts of the screen when not using a maximized HUD.
I've got glCheckFramebufferStatus failed: GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT error with this pull request on macOS.
GZDoom's master branch works fine.
FGLRenderBuffers::CheckFrameBufferCompleteness(this=0x0000608000121680) + 338 at gl_renderbuffers.cpp:388
FGLRenderBuffers::CreateFrameBuffer(this=0x0000608000121680, colorbuffer=0, depthstencil=1, colorIsARenderBuffer=false) + 212 at gl_renderbuffers.cpp:352
FGLRenderBuffers::CreateScene(this=0x0000608000121680, width=0, height=0, samples=1) + 371 at gl_renderbuffers.cpp:199
FGLRenderBuffers::Setup(this=0x0000608000121680, width=0, height=0, sceneWidth=0, sceneHeight=0) + 132 at gl_renderbuffers.cpp:151
FGLRenderer::Begin2D(this=0x000000010220d840) + 76 at gl_renderer.cpp:289
OpenGLFrameBuffer::Begin2D(this=0x0000000101afe600, (null)=false) + 290 at gl_framebuffer.cpp:370
OpenGLFrameBuffer::InitializeState(this=0x0000000101afe600) + 385 at gl_framebuffer.cpp:165
OpenGLFrameBuffer::OpenGLFrameBuffer(this=0x0000000101afe600, hMonitor=0x0000000000000000, width=1280, height=800, bits=32, refreshHz=60, fullscreen=false) + 435 at gl_framebuffer.cpp:107
OpenGLFrameBuffer::OpenGLFrameBuffer(this=0x0000000101afe600, hMonitor=0x0000000000000000, width=1280, height=800, bits=32, refreshHz=60, fullscreen=false) + 78 at gl_framebuffer.cpp:96
CocoaVideo::CreateFrameBuffer(this=0x0000618000049f30, width=1280, height=800, fullscreen=false, old=0x0000000000000000) + 412 at i_video.mm:596
gzdoom`I_SetMode(width=0x00007fff5fbfd2a0, height=0x00007fff5fbfd29c, old=0x0000000000000000) + 103 at i_video.mm:1285
gzdoom`V_DoModeSetup(width=1280, height=800, bits=8) + 48 at v_video.cpp:1249
gzdoom`IVideo::SetResolution(this=0x0000618000049f30, width=1280, height=800, bits=8) + 206 at v_video.cpp:1391
gzdoom`V_Init2() + 268 at v_video.cpp:1519
gzdoom`D_DoomMain() + 5789 at d_main.cpp:2575
Also, a bit unrelated to this particular issue, I tried to enable Core Profile on macOS. It shows nothing more than a black screen.
Launching GZDoom from Apple's OpenGL profiler revealed lots of GL errors.
Apple's implementation is known to be very picky (or strict to the spec, depending on point of view).
If you can debug on Mac hardware probably it makes sense to give it a try.
Seems this is due to the SDLGLFB::GetClientWidth + SDLGLFB::GetClientHeight functions returning 0, thus making it create 0x0 buffers. The GL errors are probably due to it trying to create a 0x0 texture before aborting with the incomplete attachment check.
Ideally those functions would return the size of the OpenGL frame buffer on Mac. It is essentially the view size, but in backing size rather than device independent pixels. Looking into fixing this and adding that to the PR.
About the core profile: from what I've understood from Graf the core profile doesn't support persistent mapping on Mac, which it needs to render anything.
dpJudas wrote:About the core profile: from what I've understood from Graf the core profile doesn't support persistent mapping on Mac, which it needs to render anything.
Correct. But I have started work on it, the 2D part should be done. But at the moment the main vertex buffer that's being created will not work on a core profile and that may just be reason enough for failure.
