ZDoom

by **Graf Zahl** » Tue Nov 10, 2020 1:48 pm

The main menu must be replaceable, the block was for the option menus which can get quite broken if a replacements makes important options disappear.

by **eharper256** » Tue Nov 10, 2020 1:27 pm

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

Wasn't that discouraged and/or prevented in a prior GZDoom update?

I remember there being a thing where modifying the main menu or adding to it were banned/prevented. Certainly caused a ruckus at the time if I recall (wasn't Brutal Doom messed up by it?). Was that repealed later?

by **drfrag** » Tue Nov 10, 2020 8:44 am

And that is a problem? Anyway it looks bad, either with Size 320,240 or just wildly changing 200 for 240 in int DisplayHeight(). The menu is adjusted to the top of the screen and not the middle.

by **Graf Zahl** » Tue Nov 10, 2020 7:58 am

320x240 does negate the 1.2 stretching factor, though.

by **drfrag** » Tue Nov 10, 2020 6:17 am

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

It would still look big and more things would fit. 320x240 is not vey special but was the minimum resolution in ZDoom for a long time.
I don't think i could do it, any clues?

by **Rachael** » Tue Nov 10, 2020 6:08 am

eharper256 wrote:
Graf Zahl wrote: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.

Rachael wrote: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.

eharper256 wrote:
wildweasel wrote: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.

by **Graf Zahl** » Tue Nov 10, 2020 5:18 am

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

by **eharper256** » Tue Nov 10, 2020 5:00 am

Graf Zahl wrote: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?

by **Graf Zahl** » Tue Nov 10, 2020 4:55 am

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

by **drfrag** » Tue Nov 10, 2020 4:45 am

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.

by **SanyaWaffles** » Tue Nov 10, 2020 4:28 am

Graf Zahl wrote: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.

Graf Zahl wrote: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.

by **Graf Zahl** » Tue Nov 10, 2020 4:01 am

SanyaWaffles wrote: 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.

SanyaWaffles wrote: 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.

Marisa Kirisame wrote: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.

by **SanyaWaffles** » Tue Nov 10, 2020 3:47 am

Graf Zahl wrote: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.

Marisa Kirisame wrote: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.

by **Marisa the Magician** » Tue Nov 10, 2020 3:41 am

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?

by **Graf Zahl** » Tue Nov 10, 2020 3:23 am

eharper256 wrote: 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.

eharper256 wrote: 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.

eharper256 wrote: 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.

ZDoom

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

Post a reply

Expand view Topic review: [4.5.0] Main/Episode/Difficulty/Class Select all stretched

Re: [4.5.0] Main/Episode/Difficulty/Class Select all stretch

Re: [4.5.0] Main/Episode/Difficulty/Class Select all stretch

Re: [4.5.0] Main/Episode/Difficulty/Class Select all stretch

Re: [4.5.0] Main/Episode/Difficulty/Class Select all stretch

Re: [4.5.0] Main/Episode/Difficulty/Class Select all stretch

Re: [4.5.0] Main/Episode/Difficulty/Class Select all stretch

Re: [4.5.0] Main/Episode/Difficulty/Class Select all stretch

Re: [4.5.0] Main/Episode/Difficulty/Class Select all stretch

Re: [4.5.0] Main/Episode/Difficulty/Class Select all stretch

Re: [4.5.0] Main/Episode/Difficulty/Class Select all stretch

Re: [4.5.0] Main/Episode/Difficulty/Class Select all stretch

Re: [4.5.0] Main/Episode/Difficulty/Class Select all stretch

Re: [4.5.0] Main/Episode/Difficulty/Class Select all stretch

Re: [4.5.0] Main/Episode/Difficulty/Class Select all stretch

Re: [4.5.0] Main/Episode/Difficulty/Class Select all stretch