Zyin's HUD

Zyin's HUD

210k Downloads

Attach elements to screen-edges, instead of using absolute pixel coordinates

ELLIOTTCABLE opened this issue · 2 comments

commented

When I re-size my window, or enter full-screen mode, the size of my Minecraft interface changes. If I try to place your durability monitors, for instance, in the bottom-left; they're suddenly in the middle of the screen when I enter full-screen.

I'd prefer to be able to say “[A] pixels from [top/bottom]; [B] pixels from [left/right]” for each interface element you add, and have those dynamically adjust when the Minecraft window is re-sized.

commented

As I see it, there are 2 possible options for solving this issue:

  1. Instead of Offset X and Offset Y, do Offset X (% of screen width) and Offset Y (% of screen height).
  2. Use anchors like "Top left", "Bottom right", etc and then allow negative values for Offset X and Offset Y.

The problem with #1 is that the components will appear to move a little bit due to the scaling of the screen when the components are placed near the right or bottom portion of the screen.

The problem with #2 is that I would have to rewrite all the rendering logic for all of my movable components in order for them to be left/right/top/bottom justified - not something I'd want to do.

In a perfect world I'd like to go with #2 but there's just too much work involved to implement it. Honestly though I find it odd that you would play at two different resolutions, why don't you just play it maximized/fullscreen? Is there a reason for that?

commented

I have giant screens (I often play at my workstation, which is set up for development; lots of screen-space is crucial). Minecraft feels nearly unplayable at that size; I only do it once in a while when I want to focus.

Similarly, I'm on a laptop; so when I unplug the laptop from the workstation, the resolution also changes (I usually do play in fullscreen on my laptop, except when I've got it windowed to reference redstone circuits or block layouts).

Personally, I'm fine with #1, if it's easy to implement. Maybe leave the issue open, incase you ever have the time or motivation for #2?