[4.5.0] Main/Episode/Difficulty/Class Select all stretched

[eharper256]

A problem with the non-options menu screens seems to have appeared in the 4.5.0 version; where the main menu and most related menu's are blown up to massive proportions: i.e. rather than being neatly centred on the screen it almost looks like it is being forced to a really low or zoomed resolution.

As can be seen ^ The Argent Text is disproportionately large. The background is also crushed to 4:3 despite it being a 16:9 image in my Wadsmoosh. On the difficulty screen, the Selection Skull is partly off the screen as well.

Whereas in version 4.4.2:

The Hexen menu is centred and much smaller and crisp. Very, very problematic with the expanded class selection in my mod, where everything turns into a nonsense cluster, as you can see:


Whilst it looked fine like this before:


Appears on all games.
Tried with and without various mods, all the same.
Usually run in Vulkan, but appears in OpenGL as well.
Tried with the new 'Widescreen' toggle both unchecked and checked.
No graphics options appear to be able to change this.
The resolution is 1080p, fairly normal. (though some of the caps are less because I had to run in briefly in windowed to get screencaps as PRINTSCREEN otherwise just caps the launcher most of the time).

Instantly fixed again by reverting to 4.4.2 so must be related to 4.5.0.

[SanyaWaffles]

It's been said in other topics quite a bit, but there were some changes to how menus were scaled. However, I'm starting to wonder how good this was as it seems to have broken the menus for a lot of pre-existing mods and TCs and games, some which might not be easily fixed because mod authors might have left the community or stopped updating mods.

Try adding "size clean" to your menudef entries and see if that fixes some of the scaling issues.

[Rachael]

The change was a double edged sword. If it breaks with the new scaling, there is certainly no guarantee that it worked well at all resolutions to begin with. i.e. it would have been problematic with certain screen sizes, anyhow.

If you design to the new standard, then you can be sure it works well on all resolutions. With the old "clean-scaling" system you never could be sure of that at all.

[Graf Zahl]

That last Hexen menu surely looks like it was only tested on 1980x1080 which features a non-standard scaling factor allowing for a lot more screen space than most other resolutions.
Let's not forget that the current scaling is the *original* one the games featured in their DOS release and the unfaithful adaptation in GZDoom has been a sore spot for me for a long time.

4.5.0 allows scaling to a specific screen size or force the old so it will hopefully be possible to address these design issues on the mod side. But one recommendation still stands: If you do not test your menus on low resolutions, there's zero guarantees they'll display robustly.

[eharper256]

That last Hexen menu surely looks like it was only tested on 1980x1080 which features a non-standard scaling factor allowing for a lot more screen space than most other resolutions.

The change was a double edged sword. If it breaks with the new scaling, there is certainly no guarantee that it worked well at all resolutions to begin with. i.e. it would have been problematic with certain screen sizes, anyhow.

If you design to the new standard, then you can be sure it works well on all resolutions. With the old "clean-scaling" system you never could be sure of that at all.

Well yes, naturally I could only test at my monitor's size. I'm not a full dev team with access to a stack of them, and I don't think most modders will be. It is still pretty much the "standard" size for alot of monitors, so its a good milestone.

Whilst I don't mind at all developing to new standards, and will implement it, this sort of sudden change mostly just causes aggro from my userbase, who'll eventually find broken menus and blame me for it. And I wouldn't have even been aware of why; had I not randomly updated myself to try a map I saw at Doomworld.

It's been said in other topics quite a bit, but there were some changes to how menus were scaled. However, I'm starting to wonder how good this was as it seems to have broken the menus for a lot of pre-existing mods and TCs and games, some which might not be easily fixed because mod authors might have left the community or stopped updating mods.

Absolutely. Fortunately, the fact that people usually don't update until something breaks or the need arises means I probably have time to fix something in the off chance, but its still the equivalent of telling me 'screw A_Playsound, now it doesn't work. Replace it with A_Startsound or everything will be mute. Trolololol'. Well, not as extreme as that of course, but the point stands.

Let's not forget that the current scaling is the *original* one the games featured in their DOS release and the unfaithful adaptation in GZDoom has been a sore spot for me for a long time.

No offence, Graf, but GZ is not really the port you pick if you're after faithfulness. You pick it for maximum modern-ness and swish and ZScript mod-support. Please don't lose sight of that in suddenly trying to make it a new Boom or Chocolate port!

Last edited by wildweasel on Tue Nov 10, 2020 7:12 am, edited 1 time in total.
Reason: Removed extraneous [size] tags - we can hear/read you just fine.

Maybe I'm just blind in my old age; I thought making the text more visible was being helpful. Not like I was capslocking everything man; and this forum's text is pretty small on 1080p.

Try adding "size clean" to your menudef entries and see if that fixes some of the scaling issues.

Thanks for the tip. MENUDEF is not a part of the wiki I would frequent often. I'll see about adding it to 0.91 when I release it. But if adding such an option also forces all the users to update, I might have to hold off.

[Graf Zahl]

Well yes, naturally I could only test at my monitor's size. I'm not a full dev team with access to a stack of them, and I don't think most modders will be. It is still pretty much the "standard" size for alot of monitors, so its a good milestone.

Sorry, but that approach is flat out wrong. It is not the default res for laptops and the video mode is only a few clicks away where you can set any virtual screen size imaginable.
If you design a menu you cannot just pick one common size, design for it and call it a day.

Whilst I don't mind at all developing to new standards, and will implement it, this sort of sudden change mostly just causes aggro from my userbase, who'll eventually find broken menus and blame me for it. And I wouldn't have even been aware of why; had I not randomly updated myself to try a map I saw at Doomworld.

Sorry, for the inconvenience, but so far nearly all menus that are affected show some clear signs of poor testing on low resolutions. That was the biggest weakness of the old menu code - giving some false security of available space. That's why you now can specify the desired target size of your menu so that on all screen sizes the layout will be the same. Or you can just enforce the old logic. But in the end the long term problems of unreliable scaling were too severe. I've seen my share of menus that were designed to badly assumed specifications over the years.

No offence, Graf, but GZ is not really the port you pick if you're after faithfulness. You pick it for maximum modern-ness and swish and ZScript mod-support. Please don't lose sight of that in suddenly trying to make it a new Boom or Chocolate port!

So far every single time to let a design mistake stand "because of modern" etc. it resulted in long term problems that far eclipsed the few mods that were severely affected initially. And now they are so deeply entrenched in the produced mods that we have to live with them forever. One thing I've learned is that if there's options to do the right thing, people won't use them.
I actually did check a lot of menus before making this change, but yours is the first one that got actually broken. The worst I have seen so far were some cut off oversized M_DOOM logos.

[Marisa the Magician]

One problem I personally have with the new menu scaling is the inability to force 1:1 pixel ratio, so my only option is to use size clean as I can't have 640x400 without vertical stretch. Am I some kind of weirdo for designing things for 16:10?

[SanyaWaffles]

But one recommendation still stands: If you do not test your menus on low resolutions, there's zero guarantees they'll display robustly.

That's a fair cop. I did make some assumptions and once these changes hit, I personally saw to it that my current projects's menus were fixed due to some bad design choices I had made with the custom menus - such as overly long text strings, oversized graphics, and so on. It was a lesson learned to test on smaller resolutions, as painful as it may be for me personally (I use an ultrawide monitor but I don't like running games full-screen unless I'm testing for that, and I have a very specific windowed resolution I set to that is between 720p and 1080p but has the same ratio that I use in windowed mode, if that makes sense. I wish I could save it as a custom resolution pre-set, it's a really odd number.)

The only "problem" is actually with font scaling. I use higher-res fonts with a scale of 4.0, and lower resolutions they tend to look a bit... well, not that great. Aside textures, everything in my projects tends to be high res... so to have low-res fonts kind of looks a bit out of place... but at lower resolutions the scaling doesn't look that great. I think 640x480 is a bit poop to look at with the hi-res fonts.

I guess that's one reason I like working with the dev-builds so much... I like to know what changes are upcoming and how to work with them. I guess that's why I saw this coming and worked on it in preparation for a 4.5.0 release, but alot of people didn't because they don't like using dev-builds (despite being encouraged to at least test them side-by-side).

I guess the main thing is menus are probably the most... obtuse thing to work with in GZDoom, and given the lack of documentation aside going knee deep into the source code is a pain. And I've been using ZScript since it came out. If it hadn't been for discussions involving menus I've been following and noting the source code changes via the changelog, I would have not noticed this was coming.

Alot of stuff I can figure out on my own, but menus are one thing I struggle with. So changing how they work adds to the frustration.

Granted, ZForms seems to make it easier, but it's a pain to set up, especially if you have multiple libraries that depend on it, and it might be overkill for making something simple... say just a text-based read this replacement.

One problem I personally have with the new menu scaling is the inability to force 1:1 pixel ratio, so my only option is to use size clean as I can't have 640x400 without vertical stretch. Am I some kind of weirdo for designing things for 16:10?

I think you can manually set a resolution to scale to using size x, y command in MENUDEF if you want to set to a custom resolution.

[Graf Zahl]

The only "problem" is actually with font scaling. I use higher-res fonts with a scale of 4.0, and lower resolutions they tend to look a bit... well, not that great. Aside textures, everything in my projects tends to be high res... so to have low-res fonts kind of looks a bit out of place... but at lower resolutions the scaling doesn't look that great. I think 640x480 is a bit poop to look at with the hi-res fonts.

Yes, but that's an entirely different problem. If you design for high resolutions and there's no lo-res fallback it won't look good but that's ultimately a design choice, not a technical issue.
Fortunately we're past the point where 640x480 is needed to handle low end hardware but there's people around that do not want to go higher.

I guess the main thing is menus are probably the most... obtuse thing to work with in GZDoom, and given the lack of documentation aside going knee deep into the source code is a pain. And I've been using ZScript since it came out. If it hadn't been for discussions involving menus I've been following and noting the source code changes via the changelog, I would have not noticed this was coming.
Alot of stuff I can figure out on my own, but menus are one thing I struggle with. So changing how they work adds to the frustration.

The change with the scaling was actually intended to fix some of the more obtuse parts, namely the problem that it was impossible to tell what size a menu would end up.
When implementing the Raze menus I quickly realized how much less painful this is if you can just set a fixed canvas size on which to design the menu - and I always wanted the original scaling back.

The way they work hasn't actually changed, what has changed is how the discrepancy between the virtual canvas and the screen is handled.

One problem I personally have with the new menu scaling is the inability to force 1:1 pixel ratio, so my only option is to use size clean as I can't have 640x400 without vertical stretch. Am I some kind of weirdo for designing things for 16:10?

In that case you should design for 640x480, not 640x400. Handling aspect ratio is a tricky thing. Since you can resize a window to any size you like, designing for widescreen will cause problems when running in a narrow window. But 4:3 is always guaranteed to be fully visible. I very frequently run GZDoom in a 4:3 window on a 16:9 screen and sometimes in a 21:9 window as well. Menus needs to display properly there as well.

[SanyaWaffles]

Yes, but that's an entirely different problem. If you design for high resolutions and there's no lo-res fallback it won't look good but that's ultimately a design choice, not a technical issue.
Fortunately we're past the point where 640x480 is needed to handle low end hardware but there's people around that do not want to go higher.

I suppose that's one of the disadvantages of using hi-res fonts in an engine like this where people are used to pixelated everything. If people insist at running it on low-res, maybe that's beyond the scope of projects like mine which is designed with alot of hi-res vector art in mind. I only use pixelated textures because it offers a good contrast to the enemies, props and so forth.

The change with the scaling was actually intended to fix some of the more obtuse parts, namely the problem that it was impossible to tell what size a menu would end up.
When implementing the Raze menus I quickly realized how much less painful this is if you can just set a fixed canvas size on which to design the menu - and I always wanted the original scaling back.

I can see what you mean, because it seems like it was the wild west with how scaling worked before.

I guess my main thing is coding menus from scratch that don't depend on ListMenu or the like and don't even have their definitions in MENUDEF, so it doesn't help much. That said, I've been discussing how menus work with some people. It's just a matter of designing it to be future-proof.

I dunno if I've mentioned it before in other threads, but UI design is something I'm versed in... but I absolutely hate it for reasons that are beyond the scope of this topic (I could go on and on for hours about modern UI design being trash and how my philosophies clash with say... Twitter or Tumblr's design philosophies. I hate social media and modern Windows... But I digress).

I can design a UI in Animate fine... but coding it is a pain. Making it work well is another thing.

[drfrag]

I think it's not surprising that menus for a respectable number of mods of don't fit, 320x200 was a very low resolution and it stopped working in ZDoom ages ago. 320x240 on the other side still worked with pixel doubling @640x480 on more modern cards. More entires would fit there and i wonder if it's possible to scale to a virtual 320x240 resolution by default instead. Anyway i don't know how to do it, that source looks complex to me.

[Graf Zahl]

That could be done, of course, but the point of the default scaling was to get back the original look of the menus.

[eharper256]

Sorry, but that approach is flat out wrong. It is not the default res for laptops and the video mode is only a few clicks away where you can set any virtual screen size imaginable.
If you design a menu you cannot just pick one common size, design for it and call it a day.

Alas... few can know the horrors of working for the British Civil Service IT, where some of the programs have fixed size 640x480 windows, sometimes clicking 'Help' crashes the program, there are leftover broken features from Windows 95 days that no longer work but cannot be removed because newer code is dependent on them, and you can only view certain forms and guidance through Internet Explorer 8. And the helpdesk's response is 'deal with it', and it'll never get fixed because it costs money. I'm honestly amazed I can work at home during Corona at all sometimes, the VPN's probably built out of duct tape.

--------------------
Anyways, so...

Code: Select all

DefaultListMenu
{
Size "Clean"
}

Adding this to MENUDEF works fine for all the class/difficulty/episode menus, but how do I set the main menu back to its smaller scaling?

[Graf Zahl]

You'll have to make a copy of it if you use the original one unchanged.

[Rachael]

That last Hexen menu surely looks like it was only tested on 1980x1080 which features a non-standard scaling factor allowing for a lot more screen space than most other resolutions.

The change was a double edged sword. If it breaks with the new scaling, there is certainly no guarantee that it worked well at all resolutions to begin with. i.e. it would have been problematic with certain screen sizes, anyhow.

If you design to the new standard, then you can be sure it works well on all resolutions. With the old "clean-scaling" system you never could be sure of that at all.

Well yes, naturally I could only test at my monitor's size. I'm not a full dev team with access to a stack of them, and I don't think most modders will be. It is still pretty much the "standard" size for alot of monitors, so its a good milestone.

Whilst I don't mind at all developing to new standards, and will implement it, this sort of sudden change mostly just causes aggro from my userbase, who'll eventually find broken menus and blame me for it. And I wouldn't have even been aware of why; had I not randomly updated myself to try a map I saw at Doomworld.

"vid_setscale" negates the need for all this extra (and honestly quite junky) hardware.

Last edited by wildweasel on Tue Nov 10, 2020 7:12 am, edited 1 time in total.
Reason: Removed extraneous [size] tags - we can hear/read you just fine.

Maybe I'm just blind in my old age; I thought making the text more visible was being helpful. Not like I was capslocking everything man; and this forum's text is pretty small on 1080p.

You're absolutely right. The forum looks like shit at 1920x1080.

However, there is a solution for that, too: Hit Ctrl - or Ctrl + on your web browser will zoom in the text and images to a more pleasing size. Most browsers will save this setting per-site. If for some reason you need to reset it, Ctrl 0.