Main Menu not adapting to display resolution

[Grey-Wolf]

Hello. I recently finished tweaking my mod's main menu layout. At 1080p and with a scale factor of 1.0, it shows perfectly as intended.
Problem is, people using different display resolutions, see its layout completely disrupted. I'm not even talking about stretched letters or something like that. It's as if the menu elements are positioned with different coordinates and are scaled along the resolution values.

Here are some examples:
1920x1080 (correct view)


1290x720


1600x1200 (4:3)


1366×768


So I was wondering if there was some sort of "sethudsize" equivalent for the MENUDEF, or any other thing that could let me handle the main menu the way sbarinfo or ACS does it, to somehow auto-adapt it to whatever video mode the user has set tup.

Any ideas?

[Grey-Wolf]

Anyone? I'm really having trouble with this one.

[Graf Zahl]

The menu's positioning is dynamic, adapting to both screen size and resolution.
I recently added a new feature that should make it easier, though. In more recent devbuilds you can specify a virtual canvas size to place your menu in - you still have to be aspect ratio aware, though. GZDoom by default only treats the center 4:3 part as safe.

[Grey-Wolf]

Sorry to bother, but can you give me some guidelines on how is this feature used?

[Graf Zahl]

You can add a "size x, y" instruction to a menu so that it scales to a given size and won't try to dynamically adapt to the current screen size.

[Grey-Wolf]

Alright I'm experimenting with the new feature since 4.5 came out, and I'm liking the addition so far, but the aspect ratio is indeed a problem. Is there a way to force another alternate layout if the user is playing with 4:3 resolutions? Something like IfOption(4:3), so to speak (I know it's not a thing, I just mean something that could let me achieve a similar result).

Edit: also, is there a way to get rid of that limitation that converts all the Difficulty select menu to the Index font? Especially now that we can set a fixed scale... it's kind of annoying

[Graf Zahl]

Currently not, there's surely room for improvements.
But for your special menu you may probably want to use ZScript to use custom items that are more tailored to its special needs. MENUDEF is really not that suited to creating highly layout sensitive menus.

[Grey-Wolf]

Hm... I see.
One last question: will LZDOOM be updated soon to support this new "size" command? Or else a good amount of people won't be able to play many mods anymore...

[drfrag]

Like i said without GL 2. There are already other menu things missing in 3.87x, first becouse they were added after the release and then they are difficult/risky to backport. If i keep adding stuff there's a high chance that i also introduce bugs and the last release from the old branch has to be solid. Also there are already other things added in the last few days that can't be ported. For instance AddListMenu, AddOptionMenu before/after and Abstract funtions are missing. But even if i added those soon there will be more stuff and the old branch can't be maintained anymore. But i'll release a 4.5 beta in a few days i think.

[Graf Zahl]

Hm... I see.
One last question: will LZDOOM be updated soon to support this new "size" command? Or else a good amount of people won't be able to play many mods anymore...

That "good amount" is overestimated most of the time. GL 2 hardware only still exists in aging and increasingly obsolete laptops which simply lack the power to run a hardware rendering engine anyway.

The same is mostly true for first generation GL3 hardware. The last survey from August 2019 had GL 3 hardware at less than 4% of the entire sample - there were 1150 out of 25000 reports for GL 3.3, but 150 of these were from running GZDoom in a VM and another 100 from outdated drivers on more modern hardware.
And that was from before Windows 7 reached the end of life. If we now extrapolate from the Steam numbers where Windows 7 nosedived from 25 to 5% over the last 10 months I am fairly certain that real GL 3 hardware these days only makes up about 2-2.5%. What may be a problem for several years is first and second generation entry-level DX12 hardware - these are generally very weak cards, but should be architecturally better suited to modern shader use than older GL3 hardware.

[Dan_The_Noob]

is there any way to "get resolution x/y" ? regardless of aspect ratio

[Player701]

You can use Screen.GetWidth() and Screen.GetHeight() in ZScript to get the current screen resolution.

[Dan_The_Noob]

You can use Screen.GetWidth() and Screen.GetHeight() in ZScript to get the current screen resolution.

do width/height with this to find if it's 16:9 or 4:3 maybe (or other ratios?) though i don't know how much you can zscript a title screen...

[SanyaWaffles]

...don't know how much you can zscript a title screen...

It's possible to ZScript a title screen using TITLEMAP and an event handler. No ACS involved. I've done it before for my current projects, and the code is roughly the same for both of them... in fact aside some string lookups being different, I think it's exactly the same routines. Here's DD2's titlemap sequence. I had some help from Ordinary Magician And Grilled Cheese Enthisiast Marisa Kirisame on the scaling for the text. I figured out on my own how to scale the title graphic itself. It's not a universal solution by any means, I think it works specifically with this particular setup. (If you're wondering what the title screen emulates... whoever guesses correctly gets a cookie)

The next part is getting the timing down, because you can't script a title sequence and must rely on ui based event handlers. So calculating it based on seconds... I dunno if milliseconds is possible aside 1/35 (I dunno if you can access fractions of a tic within an event handler in a UI. I've never tried). It might be a bit limiting.

As you can see, Lots of maths involved. Once you figure it out it's easy to make the code work for both text and graphics. I recently found out you could actually scale textures drawn via an event handler or a menu... I figured it was possible, but I didn't know how until Ace told me certain DTA_* features existed. I know GZDoom does it for it's built in menus, but I could never figure out how to do it on my own without just using the built in menus.

Menus are probably the hardest part of working with this engine, for me at least, and I've been looking at how other people do it and asking others how to do it... and it's still hard. The main problem is drawing text around graphics, say for a Read This! replacement... I'm sure it's possible if I used something like ZForms to write my own menus. However, I dunno if I need something like that for something that is basically just a glorified READ THIS screen (which I've been having trouble making).

For me, menus and coding non-standard title/intermission stuff is probably the hardest and my least favorite part of working with the engine and one reason I rely on libraries, but I'm starting to realize I can't rely on a one size fits all solution, especially as my projects scale in size. The amount of headaches I've gotten from trying to figure it out... but at least it's there (it used to be we didn't have ANY of this), and I'm sure as more folks tinker with the menus more will come to be.

As a side note, I have a background in web design... UI was my least favorite part because no one could agree on me. Content above sleekness is my motto, but everyone seems to be focused nowadays on making UI minimalist and tight... at the expense of accessibility and content.