[3.7.2] Video scaling/res refactor broke Project MSX

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.

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies

BBCode is OFF
Smilies are ON

Topic review
   

Expand view Topic review: [3.7.2] Video scaling/res refactor broke Project MSX

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

by Korell » Mon Feb 11, 2019 3:19 pm

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.

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

by KeksDose » Mon Feb 11, 2019 6:14 am

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.

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

by Korell » Mon Feb 11, 2019 4:46 am

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.

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

by Graf Zahl » Mon Feb 11, 2019 1:29 am

Se7eNytes wrote:I modified CommanderZ's code to support more resolutions in a slightly less hardcoded way awhile back, though I don't know how easily this could be adapted into something usable by Project MSX. It should support any(?) 4:3, 16:9, 16:10, or 17:10 resolution.

The main problem here still is that with arbitrary window sizes any assumption about aspect ratios is bogus by default.
Of course with ACS providing little to no help with placing content it will be a bit hard to do this right.

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

by rollingcrow » Sun Feb 10, 2019 7:44 pm

I modified CommanderZ's code to support more resolutions in a slightly less hardcoded way awhile back, though I don't know how easily this could be adapted into something usable by Project MSX. It should support any(?) 4:3, 16:9, 16:10, or 17:10 resolution.

Code: Select all

/*
	Heavily modified version of CommanderZ's old widescreen HUDMessage script.
	Now supports any supported aspect ratio rather than hardcoded resolutions.
*/ 

int res4to3 = 1.33333333333;
//int res5to4 = 1.25;
int res16to9a = 1.77777777778;
int res16to9b = 1.77864583; // For 1366x768
int res16to10 = 1.6;
int res17to10 = 1.7;

function void HudMessageStr(int type, int id, int imageWidth, int imageHeight, int time, int fadeTime, int alpha)
{ 
	int hudScreenWidth = imageHeight * 4 / 3 * imageWidth / imageHeight;
	int hudScreenHeight = imageHeight;

	if ((FixedDiv(GetScreenWidth(), GetScreenHeight())) == res4to3)
	{
		hudScreenWidth = hudScreenWidth / 4 * 3;
	}

	/*
	if ((FixedDiv(GetScreenWidth(), GetScreenHeight())) == res5to4)
	{
		hudScreenWidth = hudScreenWidth / 5 * 4;
		Log(s:"Sorry, unsupported resolution!");
	}
	*/

	else if ((FixedDiv(GetScreenWidth(), GetScreenHeight())) == res16to9a)
	{
		hudScreenWidth = hudScreenWidth / 16 * 9;
	}
	
	else if ((FixedDiv(GetScreenWidth(), GetScreenHeight())) == res16to9b)
	{
		hudScreenWidth = hudScreenWidth / 16 * 9;
	}

	else if ((FixedDiv(GetScreenWidth(), GetScreenHeight())) == res16to10)
	{
		hudScreenWidth = hudScreenWidth / 16 * 10;
	}

	else if ((FixedDiv(GetScreenWidth(), GetScreenHeight())) == res17to10)
	{
		hudScreenWidth = hudScreenWidth / 17 * 10;
	}

	else
	{
		Log(s:"Sorry, unsupported resolution!");
	}	

	// ---
   
	SetHudSize(hudScreenWidth, hudScreenHeight, 1);
	HudMessage(s:"a"; type, id, CR_Untranslated, (hudScreenWidth / 2) * 65536, (hudScreenHeight / 2) * 65536, time, fadeTime, alpha);
}
Sample use:

Code: Select all

Script "PlayerFatigue" ENTER
{
	SetFont("BlkVig");
	
	if (CheckInventory("Fatigue") <= 10000)
	{
		HudMessageStr(HUDMSG_ALPHA | HUDMSG_FADEOUT | HUDMSG_LAYER_UNDERHUD | HUDMSG_NOTWITHFULLMAP, 101, 1920, 1080, 0.0, 1.0, 1.0);
	}

   // snip
}

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

by Rachael » Sun Feb 10, 2019 6:32 pm

Hmm.. try this...

diff = w * 240 / h - 320

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

by Korell » Sun Feb 10, 2019 6:18 pm

Rachael wrote:My guess is diff is calculated this way:

diff = ((w/h) - (320/240)) * 320

Not positive about that, but give it a shot and see what happens.
1920x1080 screen resolution would then give:
((1920/1080) - (320/240)) * 320 = 1280/9, so this doesn't give the value he's using for this aspect ratio. I just can't see what he's doing here.

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

by Rachael » Sun Feb 10, 2019 6:15 pm

If it doesn't work because of the calculation being integral, as I suspect with ACS, try converting the formula to fixed point:

diff = (((w * 65536)/h) - (320 * 65536/240)) * 320 / 65536

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

by Rachael » Sun Feb 10, 2019 6:09 pm

My guess is diff is calculated this way:

diff = ((w/h) - (320/240)) * 320

Not positive about that, but give it a shot and see what happens.

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

by Korell » Sun Feb 10, 2019 6:04 pm

Rachael wrote:To get the aspect ratio it's very simple: For all aspect ratios other than 21:9 (which is actually something else, I don't remember completely) it's a simple w/h division. So 1920x1080 is 1920/1080 which reduced equals 16/9 - matching the 16:9 aspect ratio. 1024x768 is 1024/768 which reduces down to 4/3. See where I am going with this?
Yep, this is what I was trying to explain (badly) by using the values of w and h instead of the hardcoded ones for each case.
Rachael wrote:Still - the mod should not care what screen resolution you have. Instead, it should just dynamically account for the screen resolution no matter what it is, and simply apply stretching dynamically based on that.
Agreed, which is why I'm hoping a fix can be put together. However, whilst I've carried out the first part of the fix, which is all the image stretching, there is something that I don't understand in the rest of the code. He uses a function named gethudratiodiff that stores a different value for diff based on the aspect ratio. I can't see how the values have been ascertained, however. 4:3 and 5:4 have diff = 0, 16:9 has diff = 117 and 16:10 has diff = 67. From where this function is called it seems to be something to do with the sizes or positions of the HUD elements such as the health and shield bars as it passes the value through to hdif which is used in the code of these HUD elements, but some subtract it and others add it. So I may not be able to fix this after all.
Rachael wrote:If it really matters to this mod that much you can always do a simple "vid_setscale 1920 1080" to at least get the mod to run.
This may have to be the case.

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

by Rachael » Sun Feb 10, 2019 5:49 pm

To get the aspect ratio it's very simple: For all aspect ratios other than 21:9 (which is actually something else, I don't remember completely) it's a simple w/h division. So 1920x1080 is 1920/1080 which reduced equals 16/9 - matching the 16:9 aspect ratio. 1024x768 is 1024/768 which reduces down to 4/3. See where I am going with this?

A small exception is 1360x768, which is technically a 16:9 aspect ratio but is not a perfect division.

Still - the mod should not care what screen resolution you have. Instead, it should just dynamically account for the screen resolution no matter what it is, and simply apply stretching dynamically based on that.

If it really matters to this mod that much you can always do a simple "vid_setscale 1920 1080" to at least get the mod to run.

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

by Korell » Sun Feb 10, 2019 5:38 pm

For me, as I'm using a 1920x1080 monitor I don't get the issues that wildweasel has described as my resolution is catered for within that ACS code. Looking at the rest of the script, the HUD flashes all call the function "drawStretchedImage" which has checks for the aspect ratio defined in the code extract above, and if it isn't a screen resolution that it caters for then it gives an error message. So it all seems to be due to this check. I don't know the correct way to rework the ACS code (I've extremely little experience in Doom modding, having only done some basic fixes to a couple of mods here and there) but being as it is able to capture the width and height into variables w and h, I could try stripping out all of those isXtoY functions and replacing them with something that just stores the values of w and h, then all other calls to the isXtoY functions would need the calls stripping out and the hardcoded values for each instance replaced with w and h. I believe that this would then scale the images to the full screen regardless of the aspect ratio, but ultrawidescreen resolutions would give very stretched images. Would the scaling factor also work if it was played windowed, though? Do the values of GetScreenWidth() and GetScreenHeight() change if played in a window? This way it could still be played windowed for users of ultrawidescreen monitors or multiple screens.

On another note, I did notice that the standard enemy marines (Grunts) cannot shoot downards. Also, the MSX Hellknights also have one particular attack (named Tripleshot) that goes upwards instead of downwards.It appears to be due to the use of CMF_OFFSETPITCH, which after a quick search appears to be a known and now closed bug with 3.7.2, so hopefully will be fixed in the next GZDoom release: viewtopic.php?f=7&t=63439

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

by Graf Zahl » Sun Feb 10, 2019 7:02 am

Surely this can be fixed in the mod. But WW was asking for an engine side fix - which with all these and probably more such checks is pretty much hopeless.
This thing was basically broken by design, the only reason that nobody noticed is that its maker explicitly checked for all screen sizes that were in use as of its making. Just too bad that such lists rarely remain static. This would even have broken on some more recent displays without the changes to the screen size handling.

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

by Korell » Sun Feb 10, 2019 6:56 am

As an idea, and only really a custom fix to the mod itself, you could strip out all of those screen resolution checks from that ACS and simply return true for the aspect ratio you are using and false for all the others, basically hardcoding the aspect ratio. I suppose you could then take it a step further and store a custom menu item variable for the aspect ratio for the mod and check the value of it. This might fix the positioning issue, though I don't know if this would also fix the messages and screen flashing.

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

by Graf Zahl » Sun Feb 10, 2019 2:53 am

You have to ask Randi for that. This has been in ACS for a looooong time.

Top