OK, the one-pixel yellow line at the bottom of the screen just under the HUD is back. It is absent until you actvate the menu in-game; as soon as you press the ESC key, a thin yellow line appears at the bottom. This persists over starting a new game, too. This is present in at least one way in 2.1.3 as well; in GZDoom 1.0.18, playing W3D-TC, whenever a sliding door opens or closes you can see the movement of the door "through" the one-pixel gap.
Screenshot: (1280x1024 with 10-pixel black border added; otherwise defect is too small to see):
That yellow strip is always there. It appears yellow when a colour fade is used.
It's infact a little strip of void if you like which keeps whatever info was sent there last. I too have noticed it's existence, but don't find it all that annoying.
I thought it was an inaccuracy in the hud placement code.
What I don't get is why it only manifests once the menu is triggered with the ESC key; or is it an HOM-like effect? Anyway, seems to me the viewport height should be derived as (screen_height minus scaled_statusbar_height), with the scaled statusbar positioned flush to the bottom of the screen; that ought to fix it.
Interestingly enough, JFSW and JFDuke3D have an occasional similar problem; again these are OpenGL ports of traditional 2.5D S/W rendered FPS games... there's probably a moral there somewhere
This has nothing to do with 2.5d. Only with the fact that the coordinate scaling to 1024 pixels height creates an imprecision in the calculation which results in an off-by-one result.
I wouldn't know how difficult it is to fix, but can't you just like, fill the last row of the viewport's pixels with the top row of status bar pixels (in other words, just copy 1 x 320 pixels from the top of the status bar) if the screen resolution is in multiples of 1024?
Just a guess. I know jack about ZDoom coding and I would understand if it's not that easy or it just won't work that way.
EDIT: And just wondering, what was wrong with that unintended bug that Randy fixed? Eventhough it was a bug, I thought it did a good job in "fixing" it. I certainly didn't think it was a bug and assumed it was fixed (see my post before Graf's above)! I would just leave it "unfixed", heh.
That's all easier said than done. The status bar is drawn on a virtual 320x200 screen but when scaling the coordinates it calculates different values for the status bar's top plus the status bar's height and the bottom of the screen. This isn't easily fixable by 'just' drawing an additional line to the screen and most certainly not by drawing the screen one pixel too tall. That's just not correct.
