ZDoom

You're right. _mental_ pointed that out to me. I reverted the "fix".

That doesn't look like a fix. (4/3) is always 1!

Only took 21 months. This is [url=https://github.com/coelckers/gzdoom/commit/e7bad7218f514334a851a6db19c7e83e027b8299]finally fixed[/url].

ST_X is set in DBaseStatusBar::SetScale () but the value here is not used whatsoever in calculating the actual bar, itself. I hacked in some really bogus and nonsensical values and the only thing I managed to do was change how the background was drawn. The first conditional path in that function for my configuration is that st_scale is usually set to -1 on my system, so the first block gets executed.

I should note that it is the bar that is in error, not the background; setting vid_aspect to correct the issue makes the bar look correct proportionally (it gets wider). This is comparing it against running "vid_scalemode 2" (320x200) as well.

This gets done in DBaseStatusBar::RefreshBackground () and the logic is not really clear to me either. My guess is that ST_X is not set correctly in this case.
I never noticed this because I normally do not use the statusbar.

[imgur]https://imgur.com/TWEWa49[/imgur]

This bug has been bothering me ever since my last monitor crapped out and I was stuck with a smaller screen.

When maximized (with titlebar and taskbar) GZDoom ends up at the resolution 1440x847 on my screen, which is between 16:9 and 16:10. In fact, the resulting resolution is almost perfectly 17:10.

Anyway, I've been trying to fix this bug for a long time now, but to no avail. I can't seem to find the code where it actually draws the status bar. I'd be willing to implement a fix - if only I knew where the code was that calculated the actual status bar drawing.

(Oddly enough, at this resolution, executing "vid_aspect 5" produces no noticable change to the game view, but oddly fixes this...)