There's a bug in the way the reported resolutions are calculated for vid_showcurrentscaling in LZDoom (GZDoom gets the calculation right).
The game seems to apply vid_scalefactor to the reported 'real resolution,' resulting in both a falsely reported 'real resolution' as well as a falsely reported 'emulated resolution.'
E.g., at an actual resolution of 1920 x 1080 with vid_scalefactor set to 0.5, the 'real resolution' is reported to be 960 x 540 where it should be 1920 x 1080 and the 'emulated resolution' is reported to be 480 x 270 where it should be 960 x 540.
Calculation bug in vid_showcurrentscaling
Moderator: GZDoom Developers
Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
- Ihavequestions
- Posts: 163
- Joined: Mon Jul 12, 2021 1:45 pm
- Graphics Processor: nVidia with Vulkan support
- drfrag
- Vintage GZDoom Developer
- Posts: 3141
- Joined: Fri Apr 23, 2004 3:51 am
- Location: Spain
- Contact:
Re: Calculation bug in vid_showcurrentscaling
I think it's fixed, vid_scaletowidth and vid_scaletoheight were also broken.
GetClientWidth() and GetClientHeight() were not available then so i used GetWith() and GetGeight() and they were not the same. Now i've added virtuals to DFrameBuffer.
Hope i've done it right.
https://github.com/drfrag666/gzdoom/com ... f2940bb048
GetClientWidth() and GetClientHeight() were not available then so i used GetWith() and GetGeight() and they were not the same. Now i've added virtuals to DFrameBuffer.
Hope i've done it right.
https://github.com/drfrag666/gzdoom/com ... f2940bb048