[3.7.2] Video scaling/res refactor broke Project MSX

Bugs that have been investigated and resolved somehow.

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.
User avatar
Korell
Posts: 439
Joined: Sun May 28, 2017 1:01 pm

Re: [3.7.2] Video scaling/res refactor broke Project MSX

Post by Korell »

Rachael wrote:Hmm.. try this...

diff = w * 240 / h - 320
This actually seems really quite close.

Any 4:3 (e.g. 800x600) would result in 0 which is correct.
Any 5:4 (e.g. 1280×1024) would result in -20 (rather than the 0 he specifies).
Any 16:9 (e.g. 1920x1080) gives 320/3 = 106.67 (rather than the 117 he specifies).
Any 16:10 (e.g. 1680x1050) gives 64 (rather than the 67 he specifies).

So this may be usable, but I've no idea what it would do to the HUD elements with ultrawidescreen or multi-monitor setups.
Taking a 21:9 monitor resolution (though by pixels they aren't exactly 21:9 - https://en.wikipedia.org/wiki/21:9_aspe ... r_monitors) of 2560×1080 it would give a diff value of 248.89.
User avatar
KeksDose
 
 
Posts: 595
Joined: Thu Jul 05, 2007 6:13 pm
Contact:

Re: [3.7.2] Video scaling/res refactor broke Project MSX

Post by KeksDose »

There are two aspect ratios that give diff = 0, so there is no linear polynomial in the aspect ratio (like Rachael's approach) to solve this. It's poking in the dark. You should ask the guy how he got those values.

edit: But it is the correct way to get the "centre box origin".

edit 2: It could be that height and width get factored in separately, somehow, and later, the function was reduced to just aspect ratio special values. Again, guessing.

edit 3: It's best if we knew exactly what diff is supposed to accomplish.
User avatar
Korell
Posts: 439
Joined: Sun May 28, 2017 1:01 pm

Re: [3.7.2] Video scaling/res refactor broke Project MSX

Post by Korell »

Okay, I've tried using the diff as defined in Racheal's post, and with the image scaling fix I'd already tried it now gives the following results:

The HUD image scales accordingly, regardless of the aspect ratio of the screen resolution / window size. -> Good
The error messages written into the code no longer appear as I removed those IsXtoY functions. -> Good
The HUD flashes stopped working completely. -> Bad
The grenade numbers no longer appear across the HUD in any aspect ratio. -> Good
The HUD elements for the health, shield, ammo and grenade count no longer seem to reposition towards the edges in widescreen and ultrawidescreen aspect ratios (tested using various vid_setscale values) and instead always seem to occupy the same central area. -> Bad

So diff is definitely controlling the positioning of the HUD elements, but he hard-coded values to make them work for a series of aspect ratios. The code even has a comment about not being bothered enough to do 5:4 properly, so using some set values. This is probably why it still has a diff of 0.

At this point it looks like it needs some proper ACS knowledge to fix rather than my more general coding ability to do a simple replacement of the functions with some variables and calculated values, so I'm going to have to favour the use of the vid_setscale option to force 16:9 by using 1920x1080, but then those with ultrawidescreen and multi-monitor setups would end up with a pillarboxed display, whilst those with 4:3 and 16:10 screens would end up with a letterboxed display.

Can vid_setscale be used within the command line or an autoexec.cfg?

EDIT: Yep, it can be used within a CFG file and called via +exec.
Post Reply

Return to “Closed Bugs [GZDoom]”