Inconsistent offset behavior

[michaelneverwins]

I'm using MangoHud v0.6.8 on Linux Mint 20.3, and the offset_x and offset_y parameters seem to work as follows:

• If neither offset_x nor offset_y is set, the HUD is placed 10 pixels from the edge(s) of the screen/window (e.g., with default top-left positioning, the HUD is 10 pixels from the left edge and 10 pixels from the right edge).
• If offset_x and offset_y are each explicitly set to 0, the effect is the same as above.
• If offset_x is set to a negative integer, the HUD is displaced that many pixels to the left relative to its default position of 10 pixels from the left/right edge, so using offset_x=-10 puts the HUD flush to the left edge when using position=top-left.
• If offset_y is set to a negative integer, the HUD is displaced that many pixels upwards relative to its default position of 10 pixels from the top/bottom edge, so offset_y=-10 puts the HUD flush to the top edge when using position=top-left.
• If either offset_x or offset_y is set to a positive integer, the default 10-pixel padding on both axes vanishes, and HUD displacement per offset_x (negative for left and positive for right) and offset_y (negative for up and positive for down) is instead relative to the edge(s) of the screen/window.

That last bullet is the problem, and it leads to some presumably unintended quirks:

• If offset_x and offset_y are initially undefined and the HUD is in the default top-left position, then adding offset_x=10 causes the HUD to move up by 10 pixels, as the 10-pixel padding on both axes vanishes and the horizontal padding is explicitly set to 10 pixels; likewise, instead adding offset_y=10 causes the HUD to move left by 10 pixels.
• With the HUD in the default top-left position, setting offset_x=5 results in the same horizontal positioning as offset_x=-5, and likewise setting offset_y=5 results in the same vertical positioning as offset_y=-5.
• If the HUD is moved to the bottom-right corner with position=bottom-right, there is no way to make it flush with the right and bottom edges. With offset_x=0 and offset_y=0, the HUD is still 10 pixels from the bottom and 10 pixels from the right. Making either offset_x or offset_y positive will then make both axes' default 10-pixel padding vanish, but then the HUD is actually hanging off the edge by the specified number of pixels, e.g. with offset_x=1 and offset_y=0 the HUD will be flush with the bottom edge but will be one pixel past the right edge.

Putting the HUD some number of pixels away from the edge by default is fine, and whether explicitly specified offsets should be relative to that default position or relative to the absolute edge of the screen/window is a matter of opinion. However, negative offsets being relative to the default position and positive offsets being relative to the edge of the screen/window seems like a bug, as does offset_x affecting the vertical offset and offset_y affecting the horizontal offset.

[michaelneverwins]

The hud_no_margin parameter, which didn't seem to work for me with MangoHud v0.6.8, is now working with v0.6.9. This makes it possible to position the HUD flush with both the bottom and right edges of the screen/window.

However, when hud_no_margin is not enabled, I still see the odd (or, at least to me, counter-intuitive) behavior of both axes' default margins disappearing when either offset_x or offset_y is explicitly set greater than zero but not when one or both are explicitly set less than or equal to zero. I haven't looked through much of the source code, but presumably the line

   if (params.offset_x > 0 || params.offset_y > 0 || params.enabled[OVERLAY_PARAM_ENABLED_hud_no_margin])

visible in (or, rather, removed by) one of @azn1999's earlier commits would be to blame. I think replacing params.offset_x > 0 and params.offset_y > 0 with checks for those parameters being explicitly defined at any value, rather than just positive values, would make the behavior of the HUD less confusing. But maybe the current behavior is exactly how someone wants it.