Experimental Feature: Improving GUIs by supporting anchoring windowDefs

[covert_caedes]

Doom3/TDM GUIs use a 640x480 coordinate system and assume that the player uses a 4:3 resolution, otherwise they'll look stretched.

Most TDM GUIs assume that they will be stretched to 16:9, i.e. pixels aren't square (which makes writing GUIs pretty painful, I guess) and when using a non-16:9-resolution things look stretched.

TDM added the forcescreenaspect window variable that will prevent a windowDef from being stretched when used with hcenter that can be used to have something undistorted on the center of the screen, but it's still pretty limited (and barely used) - and as far as I can tell child-windowDefs of that will still be stretched.

 

Anyway, CstDoom3 2.0 introduced Anchored GUIs which allow anchoring windowDefs to a corner or center of the screen and prevents them (and everything contained in them) from being stretched.

Those anchored windowDefs are mostly limited to 640x480 virtual pixels (scaled to screensize, as much as possible while keeping the aspect ratio), so regardless of the window's resolution, they will remain unstretched (well, except for those anchor cases that explicitly stretch in one direction, like anchoring just to the top instead of top center or top left or whatever).

This allows for example to anchor the weapon_display windowdef to the lower left corner of the screen, the lightgem to the lower center of the screen and the current item to the lower right corner of the screen. No matter how wide or tall the window is, they will remain there, unstretched.

I think these screenshots illustrate it pretty well:

 

For dhewm3 1.5.5 I ported them to dhewm3 and greatly improved them, for example they can now also be used for regular (interactive) menus, while in CstDoom3 they only worked with noninteractive fullscreen GUIs like the HUD (mouse positions weren't calculated correctly).

 

This feature is documented in detail at https://github.com/dhewm/dhewm3/blob/master/docs/GUIs.md#aspect-ratio-independent-guis-covering-the-whole-screen-with-cstdoom3s-anchors

Now I ported that to The Dark Mod, with just two little changes:

• There is no scaling of menus to 4:3 with letterboxing, so the window variable scaleto43 is not needed or even supported
• Most of TDM's GUIs assume that they'll be stretched to 16:9, even though using the 640x480 4:3 coordinate system. To accommodate this, I added the cstAssumes16_9 window variable.

cstAssumes16_9 1 will cause the anchored windowDef, that would normally have a 4:3 aspect ratio, to be stretched by factor 1.333 (in width), just like it would when stretching to a 16:9 resolution. So when porting existing GUIs to this system, you don't have to recalculate the coordinates - if they were meant to be stretched, add a "cstAssumes16_9 1" line to the windowDef (and "cstAnchor CST_ANCHOR_BOTTOM_LEFT" line or similar, of course) and it should work in most cases.

By the way, this is completely backwards-compatible, so if your .gui doesn't use cstAnchor, it will continue to work just like before.

At https://github.com/DanielGibson/thedarkmod-mirror/pull/1 you can find a testbuild for Windows with this enabled, some ported GUIs, more information and the code changes.

Currently this is an experimental patch, I don't know when or if it will be merged to the official TDM source.

 

Please check it out and play around with this feature and let me know how you like it and if you run into problems!

I've ported most of the HUD, but there's still a lot of GUIs that would benefit from being ported, like the inventory menu, the main menu and more.
TBH those seem pretty complex so I'd appreciate help from someone who's familiar with their code

[New Horizon]

Very nice!

[covert_caedes]

There's a new build at https://github.com/DanielGibson/thedarkmod-mirror/pull/1

and also updated GUIs - I think all relevant GUIs are done now?

 

Needs testing of course, please let me know if anything looks weird or otherwise misbehaves

Examples of a menu in different screen aspect ratios (that number was just for debugging and shows the current aspect ratio, e.g. 16:9 is 16/9 = 1.777..)

[covert_caedes]

screenshots of the main part of the main menu, here I took extra care to move the left and right parts closer to each other for narrower aspect ratios.

In the mission list above the menu is just squeezed when narrower than 16:9, because it was too hard to get both parts to fit into 4:3 in their original width, but here it was possible because cutting off parts of the background figure doesn't hurt

Update: just realized the screenshots I posted here were outdated, replaced them with new ones

 

Edited June 17 by covert_caedes
screenshots were not of final version

[datiswous]

Cool! Now the mission lists could be made a bit wider depending on aspect ratio? Often mission names are cut off.

I guess you could have a different layout based on aspect ratio? For example having install_splash.tga as picture left of the mission description instead of under it with 0.2 opacity.

Could this be made part of a test build, which could be installed via the installer, or will this be added to the new dev version?

[datiswous]

Ok I tried the testbuild. I was kind of expecting a bigger change. I saw almost no difference with a windowed 16:9 screen. Maybe I'm just missing the point.

Although other aspect ratio's do look better

Edited June 18 by datiswous

[covert_caedes]

14 hours ago, datiswous said:

Cool! Now the mission lists could be made a bit wider depending on aspect ratio? Often mission names are cut off.

Yes, theoretically that should be possible, by having different windowdefs for different aspectratios and using something like visible "gui::cstAspectRatio" < 1.6 in one and visible "gui::cstAspectRatio" >= 1.6 in the other.

Maybe it could even be done by setting the rect's width based on one of the new variables?
Feel free to experiment

 

14 hours ago, datiswous said:

Could this be made part of a test build, which could be installed via the installer, or will this be added to the new dev version?

No idea how those are created and distributed, but so far my changes are not in the SVN repo but just my private git repo (for the code) or those zip files (for the .guis).

I'll commit them to the SVN repo once someone from the team gives their ok (should probably be a coder who can decide whether they want all my changes to the engine or not).

 

13 hours ago, datiswous said:

Ok I tried the testbuild. I was kind of expecting a bigger change. I saw almost no difference with a windowed 16:9 screen. Maybe I'm just missing the point.

Yes you do

So far the menus were optimized for 16:9 and looked stretched at other aspect ratios, especially if they're very different (16:10 still looked ok, 4:3 or 21:9 not so much).
The main goal here was to make sure they look good at any aspect ratio instead of visibly stretching or squeezing text and icons. The only thing that's still stretched is that "noisy" part of the background in the main menu - I don't think it matters, it doesn't have a real shape anyway. But background images like those figures or the skull on the death screen now preserve their aspect ratio - so them looking the same at 16:9 is expected
There may be some exceptions for things that looked like they were meant for 4:3 and looked stretched at 16:9 (like the shop menu and credits, I think?) - those should now look like in 4:3 at any aspect ratio incl. 16:9.

(Caveat for "not stretching/squeezing": Some things are still squeezed for aspect ratios between 4:3 and 16:9, because menus with two "pages" on them like the missions list I posted above often just don't fit into narrower resolutions - but that's at least not worse than before. And for wider aspect ratios those menus now look like at 16:9 instead of being stretched.)

[nbohr1more]

Hmm, I'll need to compile as a sanity check but when I tried the existing build on WINE I was unable to change the icon scale on the HUD Opacity sub-menu. I would just jump to the largest size.

[covert_caedes]

That issue sounds familiar, it's possible that I only fixed it after uploading the current GUIs.

I just uploaded the latest state on Github.

[nbohr1more]

Sorry, I just tried the latest GUI ( 04 ) and it still occurs.

I also compiled a Linux binary and the same issue persists.

I'll try to see what's happening if you don't fix it first...

[covert_caedes]

What resolution are you using when that happens?

[nbohr1more]

1080p Render Scale 1 ( no upscaling )

[covert_caedes]

Weird, it works fine here at 1080p, native linux, both windowed and fullscreen, even with renderscale < 1

 

Did you remember to rename tdm_guis04.zip to tdm_guis04.pk4?

[nbohr1more]

OK, as a sanity check I extracted the GUI's pk4 into the GUIS asset folder and ran your Linux build and that works.

I'll rebuild from source to verify further but I think that might just mean exploded folders take precedence over pk4's.

[nbohr1more]

5 minutes ago, nbohr1more said:

OK, as a sanity check I extracted the GUI's pk4 into the GUIS asset folder and ran your Linux build and that works.

I'll rebuild from source to verify further but I think that might just mean exploded folders take precedence over pk4's.

Edit: Source build works well too!

LGTM / Please merge to SVN source trunk.

[covert_caedes]

Thanks, I've committed the code changes to the darkmod_src SVN and updated executables and the modified GUIs to the darkmod SVN