Fix game HUD too low on narrow (<16:9) resolutions

[petchema]

All the HUD expect NativePanel to be aligned on the top of the screen, which is not the case for resolutions narrower than 16:10 (the ratio of 320:200). Explicitly align it to the top.

Forums: https://forums.dfworkshop.net/viewtopic.php?t=6769

[petchema]

One small issue found after fixing UI positioning, is that in 4:3 resolution the first debuff icon and the action mode icon overlap.

Going back to classic Daggerfall, the first debuff icon is actually to the right of the first buff icon (in fact it's aligned with the 2nd buff icon).

So matching classic actually fixes that small issue.

What I was at it, improved the way icons adjust to the HUD by specifying whether they're anchored to the top, bottom, left or right of the screen.

[KABoissonneault]

The change seems mostly good. I tested multiple resolutions and different icon configurations.

I do have one general issue: in narrow resolutions without large HUD, you seem to have broken the tooltip for debuffs. In the Spider's case, it should show Spider Touch as a tooltip when you hover the debuff icon.

I tracked it down to the HUDActiveSpell's ScaledMousePosition being (-1, -1) while hovering the debuff icon with your changes, but I'm not sure why. I think HUDActiveSpell's rectangle does not always extend down to the new debuff position.
I get the tooltip properly in 16:9, and when using the large HUD

[petchema]

Good catch, if activeSpells panel size is set to 320 x 200 (copied from NativePanel.Size at the beginning of DaggerfallHUD.Setup()), one can put spell icons below the activeSpells panel and they lose their tooltips.
That can be fixed by setting activeSpells panel size to 320 x 240.
But I don't know if that's the right thing to do. I sort of understand that 320x200 vs 320x240 thing that comes from MCGA 320x200 non-square pixels, but not how it translates into code. For example, should NativePanel have some stretched coordinates, or should it be 320x240? I have no idea

[Interkarma]

Hey all! :) Kab pinged me and asked me to weigh in on this one. I'll do my best to outline the core problem and offer a couple of possible approaches to solving.

Conceptually, ParentPanel fits to entire display viewport and NativePanel represents a virtual 320x200 area the static game UI scales inside of. NativePanel is scaled to fit inside of ParentPanel which may include letterbox or pillarbox areas. Most of the time, NativePanel will contain the static game UI.

Where things get messy is the HUD is mostly separate from the rest of the UI and does its scaling independently inside of ParentPanel rather than NativePanel. The reason I did this was so HUD elements could be positioned outside of the virtual 320x200 area of NativePanel. For example, HUD elements like status bars need to be left-aligned and will sit outside of NativePanel area on widescreen displays.

With that split in mind, you'll note the majority of HUD elements are added to ParentPanel and scale within that rect. There are only three exceptions: activeSpells, popupText, and midScreenTextLabel. Not surprisingly, these are the ones we're having troubles with.

Solution 1 is to change the NativePanel dimension for HUD to something that correctly fits screen aspect, large HUD on/off, retromode aspect, etc. Considering all of the possible combinations it might be impossible to have a one-size-fits-all dimension that doesn't break in some other combination (i.e. just moving the problem elsewhere).

Solution 2 is to ditch NativePanel for HUD and fit everything inside of ParentPanel so that all of the HUD elements are now within the same hierarchy and following the same rules. This might actually prove to be more work in the short term but makes all HUD elements work uniformly in the long term.

Solution 3 is to ignore NativePanel and create new parent panels for spell icons that are top and bottom aligned to ParentPanel for buffs and debuffs respectively. Then you can parent the icon controls to those panels and they should mostly work the same way with less refactoring (in theory).

I would lean towards solutions 2 or 3 here. Reworking these three HUD elements out of NativePanel means all the HUD parts work in the same viewport area. I can't even recall why I didn't do that for everything in the HUD to start with.

I hope that's of some help. I'm happy to try and answer any follow-up questions, but please keep in mind my DFU mental map is getting a bit out of date now as I'm not in the project daily anymore. All the best!

[KABoissonneault]

I'd like to see either of these solutions implemented before moving with this PR. I would like to see the fix though, so I hope it doesn't prove too much trouble. I hope it's really just a matter of adding intermediary panels