Author Topic: HUD is too small!  (Read 15373 times)

0 Members and 1 Guest are viewing this topic.

I just played through the entire FS2 campaign over the weekend and my hunger for space sims has only grown as a result.

I'm interested in playing through FS1 with the awesome graphical improvements this community has come up with, but I noticed as soon as I launched the first mission that the HUD is tiny! It's very hard to read the text, or make out what's on the radar. My resolution is 1920x1080. I'm running FS2 Open 3.7.2 (RC5) SSE.

I tried making a mv_root-hdg.tbm file under MediaVPs_2014/data/tables as suggested here, but it didn't do anything. I even tried adding "$Reticle Style: FS2" but to no avail. Maybe it no longer works with this new release?

Has anyone been successful in increasing the size of the HUD in the current release?

 

Offline BirdofPrey

  • 28
  • Help! I see GIMP in my sleep
Same exact problem here.
I managed to get a decent sized HUD in FS:P by putting a hdg.tbm in the FS:P MVP folder, but can't seem to get it to work with the FS2 MVPs

Why in the world is $Scale Gauges set to "no" anyways?
The Great War ended 30 years ago.
Our elders tell stories of a glorious civilization; of people with myths of humanity everlasting, who hurled themselves into the void of space with no fear.

In testing: Radar Icons

 

Offline niffiwan

  • 211
  • Eluder Class
For the new FSPort you need a different table than the one for the mediavps_2014.  Try putting this text into fsport-mediavps_2014\data\tables\mv_root-hdg.tbm.  (I just took the table from the VP and changed $Scale Gauges: no to $Scale Gauges: yes)

Code: [Select]
$Max Directives: 8
$Max Escort Ships: 13
;;FSO 3.7.1;; $Scale Gauges: yes
$Reticle Style: FS1

;;FSO 3.7.1;; !*
#Gauge Config
$Base: (1366, 768)
$Required Aspect: Wide Screen
$Min: (1024, 600)
$Gauges:
+Messages:
Position: (8, 5)
+Fixed Messages:
+Training Messages:
Position: (550, 125)
+Multiplayer Messages:
Position: (8, 240)
+Support:
Position: (630, 534)
+Damage:
Position: (611, 61)
+Wingman Status:
Position: (1274, 144)
+Auto Speed:
Position: (1302, 672)
+Auto Target:
Position: (1302, 648)
+Countermeasures:
Position: (1222, 602)
+Talking Head:
Position: (5, 56)
+Directives:
Position: (5, 278)
+Weapons:
Position: (1222, 511)
+Objective Notify:
Position: (607, 184)
+Squad Message:
Position: (1169, 5)
+Escort View:
Position: (1207, 330)
+ETS Retail:
Position: (1222, 648)
+Target Monitor:
Position: (5, 590)
+Extra Target Data:
Position: (5, 552)
+Target Shields:
Position: (463, 670)
+Radar:
Position: (582, 590)
+Player Shields:
Position: (805, 670)
+Afterburner Energy:
Position: (445, 424)
+Weapon Energy:
Position: (837, 424)
+Text Warnings:
Position: (683, 275)
+Center Reticle:
Position: (664, 376)
+Mini Target Shields:
Position: (668, 470)
+Throttle:
Position: (518, 390)
+Threat Indicator:
Position: (557, 219)
+Voice Status:
Position: (8, 255)
+Ping:
Position: (1238, 5)
+Lag:
Position: (798, 529)
+Supernova:
Position: (341, 170)
+Target Brackets:
+Lead Indicator:
+Lock Indicator:
+Offscreen Indicator:
+Hostile Triangle:
Position: (683, 387)
+Target Triangle:
Position: (683, 387)
+Missile Triangles:
Position: (683, 387)
+Orientation Tee:
Position: (683, 387)
+Mission Time:
Position: (1311, 716)
+Kills:
Position: (1222, 624)
; FS1 specific gauge
+Weapon Linking:
Position: (769, 387)
$End Gauges
#End
;;FSO 3.7.1;; *!

Why in the world is $Scale Gauges set to "no" anyways?

Modders preference? :D
(I actually prefer small but crisp gauges as well)
Creating a fs2_open.log | Red Alert Bug = Hex Edit | MediaVPs 2014: Bigger HUD gauges | 32bit libs for 64bit Ubuntu
----
Debian Packages (testing/unstable): Freespace2 | wxLauncher
----
m|m: I think I'm suffering from Stockholm syndrome. Bmpman is starting to make sense and it's actually written reasonably well...

 

Offline The E

  • He's Ebeneezer Goode
  • Moderator
  • 213
  • Nothing personal, just tech support.
    • Steam
    • Twitter
Why in the world is $Scale Gauges set to "no" anyways?

Modders preference? :D
(I actually prefer small but crisp gauges as well)

Same here, but playing on 4k recently (via the AMD super resolution thing or however they've taken to call it) showed that that approach has severe issues. I think we need to rethink this a bit, there has to be a simple way for users to override this setting or alternatively have the engine detect high resolutions and start scaling automatically.
If I'm just aching this can't go on
I came from chasing dreams to feel alone
There must be changes, miss to feel strong
I really need lifе to touch me
--Evergrey, Where August Mourns

 

Offline niffiwan

  • 211
  • Eluder Class
There's a bunch of options that I can think of fairly quickly.

1) mods (or just the mediavps_2014 & fsport-mediavps) could offer an optional VP that switches the setting. i.e. users can install the optional VP using the installer to enable scaling
2) mods could specify a (large) HUD resolution in their tables that enables scaling from that point upwards
3) have the code switch automatically, the only question (and probable point of contention!) is the resolution where the change should occur
4) add a command line option to override the mods scaling setting (but that didn't seem to be much liked last time this was discussed)

(some day we really need a new options menu inside FSO to handle this sort of setting...)

edit: one more idea!
5) SVG support for HUD gauges! (haha!)
« Last Edit: February 23, 2015, 04:19:37 am by niffiwan »
Creating a fs2_open.log | Red Alert Bug = Hex Edit | MediaVPs 2014: Bigger HUD gauges | 32bit libs for 64bit Ubuntu
----
Debian Packages (testing/unstable): Freespace2 | wxLauncher
----
m|m: I think I'm suffering from Stockholm syndrome. Bmpman is starting to make sense and it's actually written reasonably well...

 

Offline BirdofPrey

  • 28
  • Help! I see GIMP in my sleep
I think scale hud gauges needs to be a flag like the stretch menus flag.
It's annoying to me because I have a hdg.tbl in the fsport MVP folder and it works fine for mods that use those, but the same table in the 2014 MVPs does nothing for FS2 era mods or the base campaign.  It doesn't seem to override the table in the MV_root.vp and I don't really want to take THAT apart and repack to remove the table.

Anyways, right now the HUD gauges table the MVPs have only has a few lines to increase the number of items you an put on your escort list and turn off hud gauge scaling.  Realistically it should actually have gauge positions and individual gauge scaling on a set of resolutions.  Right now it also doesn't play well with eyefinity since it puts most of the gauges on the far corners of the screen.


.svg HUD gauges would be neat, but are we scaling it enough for it to be a problem?  I don't have a huge 4k monitor, so I don't know how it looks on that, but the old gauges from way back when still look fine scaled to fit my 25" screen on 1920x1080.

On a side note, I have considered doing my own HUD revisions (much like I did for the radar icons).  Again, though, can't test on larger resolutions or ultrawidescreen.  Best I have is 3x1 eyefinity (speaking of which, the hug gauges table needs some new options, right now it has fullscreen for 4:3 resolutions and widescreen for  16:9 and I'm assuming also 8:5, but there's no flag for ultrawidescreen (21:9) or multi-monitor (usually 3x1 landscape or 5x1 portrait).
« Last Edit: February 23, 2015, 10:39:18 am by BirdofPrey »
The Great War ended 30 years ago.
Our elders tell stories of a glorious civilization; of people with myths of humanity everlasting, who hurled themselves into the void of space with no fear.

In testing: Radar Icons

 

Offline The E

  • He's Ebeneezer Goode
  • Moderator
  • 213
  • Nothing personal, just tech support.
    • Steam
    • Twitter
.svg HUD gauges would be neat, but are we scaling it enough for it to be a problem?  I don't have a huge 4k monitor, so I don't know how it looks on that, but the old gauges from way back when still look fine scaled to fit my 25" screen on 1920x1080.

Yes, they do, but that's more to do with the simple issue that we've been dealing with 96 DPI displays for ages by now. FS2's HUD, which was made for 1024x768, looks well on 1080 because all we need to do is rearrange them on the screen and they'll still be legible. But when you're changing the DPI value into ridiculous ranges, things get unreadable; I've recently had to deal with all of those problems at work, as we made our product work well on devices as insane as the Lenovo Yoga (Which crams a 3200x1800 screen into a 13" body), and correct scaling is a part of that.
4k displays, or "Retina" displays, aren't going to go away. We should do our best to prep for them.
If I'm just aching this can't go on
I came from chasing dreams to feel alone
There must be changes, miss to feel strong
I really need lifе to touch me
--Evergrey, Where August Mourns

 
For the new FSPort you need a different table than the one for the mediavps_2014.  Try putting this text into fsport-mediavps_2014\data\tables\mv_root-hdg.tbm.  (I just took the table from the VP and changed $Scale Gauges: no to $Scale Gauges: yes)

Excellent, thank you.

 

Offline BirdofPrey

  • 28
  • Help! I see GIMP in my sleep
.svg HUD gauges would be neat, but are we scaling it enough for it to be a problem?  I don't have a huge 4k monitor, so I don't know how it looks on that, but the old gauges from way back when still look fine scaled to fit my 25" screen on 1920x1080.

Yes, they do, but that's more to do with the simple issue that we've been dealing with 96 DPI displays for ages by now. FS2's HUD, which was made for 1024x768, looks well on 1080 because all we need to do is rearrange them on the screen and they'll still be legible. But when you're changing the DPI value into ridiculous ranges, things get unreadable; I've recently had to deal with all of those problems at work, as we made our product work well on devices as insane as the Lenovo Yoga (Which crams a 3200x1800 screen into a 13" body), and correct scaling is a part of that.
4k displays, or "Retina" displays, aren't going to go away. We should do our best to prep for them.
Maybe I should try playing FSO on my Surface, that's a high DPI screen.

Luckily when scaling is on it tries to fit the HUD into the same approximate percentage of the screen (as far as I can tell) which helps get around some of the DPI issues, though I will admit I can see it being a problem for certain screen sizes, on a 30" screen with scaling on, everything is going to be huge, though at the same time with it off everything is too small.  Again, that's why we need to actually have a gauge configs for a selection of resolutions. (Is actual screen size, or at least DPI which can be extrapolated with the resolution to find it, a value that is exposed to OpenGL programs?)

Now that I think about it, though.  .svg elements would certainly help a problem I have been having.  I've been working to make specific radar icons for each specific ship, and have run into a problem that on certain resolutions, some of the icons have a nasty shimmer.  Getting a compromise that causes a single image to look great on a wide range of resolutions is rather frustrating.  Since I saved all my paths, it would be nice to be able to convert to an .svg that scales to your hud size, draws a 1-2px border and fills the interior.

Since I saved my paths, it would be fairly trivial to make said .svg files
The Great War ended 30 years ago.
Our elders tell stories of a glorious civilization; of people with myths of humanity everlasting, who hurled themselves into the void of space with no fear.

In testing: Radar Icons

 

Offline The E

  • He's Ebeneezer Goode
  • Moderator
  • 213
  • Nothing personal, just tech support.
    • Steam
    • Twitter
No, OpenGL has no access to the DPI characteristics of a display (Although, never say never: There's always the chance that the next GL standard will expose this information)
If I'm just aching this can't go on
I came from chasing dreams to feel alone
There must be changes, miss to feel strong
I really need lifе to touch me
--Evergrey, Where August Mourns

 

Offline BirdofPrey

  • 28
  • Help! I see GIMP in my sleep
Bummer
The Great War ended 30 years ago.
Our elders tell stories of a glorious civilization; of people with myths of humanity everlasting, who hurled themselves into the void of space with no fear.

In testing: Radar Icons

 

Offline Yarn

  • 210
I've got an idea: Allow the modder to specify a resolution above which scaling is "forced", although gauges wouldn't necessarily be scaled as much as they would be if scaling weren't explicitly disabled. Here's what the relevant portion of the table might look like:

Code: [Select]
$Scale Gauges: no
$Force Scaling Above: (1200, 900)

The "$Force Scaling Above" parameter in this example is set to 1200x900, indicating that if both dimensions of the screen resolution are greater than that, then the gauges would be enlarged enough to match what size they would be at a screen resolution of 1200x900.

This parameter would be usable anywhere that "$Scale Gauges" is usable, and overriding would work in the same manner. Also, using "$Force Scaling Above" without "$Scale Gauges" would be allowed, although it would only take effect on gauges that have scaling disabled.

If this sounds good, I can look into coding it.
"Your fighter is running out of oil.  Please check under the hood and add more if necessary"
--strings.tbl, entry 177

"Freespace is very tired.  It is shutting down to get some rest."
--strings.tbl, entry 178

 

Offline AdmiralRalwood

  • 211
  • The Cthulhu programmer himself!
    • Skype
    • Steam
    • Twitter
Code: [Select]
$Scale Gauges: no
$Force Scaling Above: (1200, 900)
[...]
If this sounds good, I can look into coding it.
I like it. :yes:
Ph'nglui mglw'nafh Codethulhu GitHub wgah'nagl fhtagn.

schrödinbug (noun) - a bug that manifests itself in running software after a programmer notices that the code should never have worked in the first place.

When you gaze long into BMPMAN, BMPMAN also gazes into you.

"I am one of the best FREDders on Earth" -General Battuta

<Aesaar> literary criticism is vladimir putin

<MageKing17> "There's probably a reason the code is the way it is" is a very dangerous line of thought. :P
<MageKing17> Because the "reason" often turns out to be "nobody noticed it was wrong".
(the very next day)
<MageKing17> this ****ing code did it to me again
<MageKing17> "That doesn't really make sense to me, but I'll assume it was being done for a reason."
<MageKing17> **** ME
<MageKing17> THE REASON IS PEOPLE ARE STUPID
<MageKing17> ESPECIALLY ME

<MageKing17> God damn, I do not understand how this is breaking.
<MageKing17> Everything points to "this should work fine", and yet it's clearly not working.
<MjnMixael> 2 hours later... "God damn, how did this ever work at all?!"
(...)
<MageKing17> so
<MageKing17> more than two hours
<MageKing17> but once again we have reached the inevitable conclusion
<MageKing17> How did this code ever work in the first place!?

<@The_E> Welcome to OpenGL, where standards compliance is optional, and error reporting inconsistent

<MageKing17> It was all working perfectly until I actually tried it on an actual mission.

<IronWorks> I am useful for FSO stuff again. This is a red-letter day!
* z64555 erases "Thursday" and rewrites it in red ink

<MageKing17> TIL the entire homing code is held up by shoestrings and duct tape, basically.

 

Offline BirdofPrey

  • 28
  • Help! I see GIMP in my sleep
Seems a bit basic since it doesn't let you select a resolution to scale to other than the point at which scaling is turned on (could be useful), also would that support multiple scaling targets (force scaling above one medium resolution to that resolution and another higher resolution to that resolution)

Personally, I still think while that gives a good fallback option for when nothings coded in, a proper table for HUD layouts is something that we need.
Also it might be good to include a flag to set the dimensions of an item to manually scale the gauges as right now we just have a boolean value to turn scaling on or off and when it's on it basically scales to take up about as much space as it would on the default FS2 resolution, but on larger screens you might not need them that big (essentially with only scale or no scale you have the choice between too big or too small)
The Great War ended 30 years ago.
Our elders tell stories of a glorious civilization; of people with myths of humanity everlasting, who hurled themselves into the void of space with no fear.

In testing: Radar Icons

 

Offline AdmiralRalwood

  • 211
  • The Cthulhu programmer himself!
    • Skype
    • Steam
    • Twitter
Seems a bit basic since it doesn't let you select a resolution to scale to other than the point at which scaling is turned on (could be useful)
It would look rather odd if the HUD drastically changed size from the resolution only changing size by a few pixels, but you could probably do this by giving it a maximum resolution and adding a second entry that scaled.

...Which, come to think of it, would work without any code changes.

also would that support multiple scaling targets (force scaling above one medium resolution to that resolution and another higher resolution to that resolution)
Not quite sure what that means.

when it's on it basically scales to take up about as much space as it would on the default FS2 resolution
Only if the HUD is tabled for the default FS2 resolution.
Ph'nglui mglw'nafh Codethulhu GitHub wgah'nagl fhtagn.

schrödinbug (noun) - a bug that manifests itself in running software after a programmer notices that the code should never have worked in the first place.

When you gaze long into BMPMAN, BMPMAN also gazes into you.

"I am one of the best FREDders on Earth" -General Battuta

<Aesaar> literary criticism is vladimir putin

<MageKing17> "There's probably a reason the code is the way it is" is a very dangerous line of thought. :P
<MageKing17> Because the "reason" often turns out to be "nobody noticed it was wrong".
(the very next day)
<MageKing17> this ****ing code did it to me again
<MageKing17> "That doesn't really make sense to me, but I'll assume it was being done for a reason."
<MageKing17> **** ME
<MageKing17> THE REASON IS PEOPLE ARE STUPID
<MageKing17> ESPECIALLY ME

<MageKing17> God damn, I do not understand how this is breaking.
<MageKing17> Everything points to "this should work fine", and yet it's clearly not working.
<MjnMixael> 2 hours later... "God damn, how did this ever work at all?!"
(...)
<MageKing17> so
<MageKing17> more than two hours
<MageKing17> but once again we have reached the inevitable conclusion
<MageKing17> How did this code ever work in the first place!?

<@The_E> Welcome to OpenGL, where standards compliance is optional, and error reporting inconsistent

<MageKing17> It was all working perfectly until I actually tried it on an actual mission.

<IronWorks> I am useful for FSO stuff again. This is a red-letter day!
* z64555 erases "Thursday" and rewrites it in red ink

<MageKing17> TIL the entire homing code is held up by shoestrings and duct tape, basically.

 

Offline BirdofPrey

  • 28
  • Help! I see GIMP in my sleep
also would that support multiple scaling targets (force scaling above one medium resolution to that resolution and another higher resolution to that resolution)
Not quite sure what that means.
He's saying have a flag that forces scaling above a certain resolution to THAT resolution.  I am saying make so you can have that flag multiple times.  So below the resolution of the first flag scaling is off.  Above the resolution of the first flag scale to that resolution, but above the second flag scale to the resolution listed there instead.

Quote
when it's on it basically scales to take up about as much space as it would on the default FS2 resolution
Only if the HUD is tabled for the default FS2 resolution.
As far as I can tell, right now it IS, since the only hug gauges table I can find is mv_root-hdg.tbm the entirety of which is this.

Code: [Select]
;General Shenanigans

$Max Directives: 8
$Max Escort Ships: 13
$Scale Gauges: no

new flags are great and all, but we don't seem to be using the flags we have already for controlling position and scale.
The Great War ended 30 years ago.
Our elders tell stories of a glorious civilization; of people with myths of humanity everlasting, who hurled themselves into the void of space with no fear.

In testing: Radar Icons

 

Offline Yarn

  • 210
He's saying have a flag that forces scaling above a certain resolution to THAT resolution.  I am saying make so you can have that flag multiple times.  So below the resolution of the first flag scaling is off.  Above the resolution of the first flag scale to that resolution, but above the second flag scale to the resolution listed there instead.
Here's the effect that your proposal would have, assuming that gauge scaling is disabled:
  • Between the HUD's base resolution and the first "$Force Scaling Above" resolution, a gauge's apparent size is reduced as the screen resolution increases.
  • Between the first and second "$Force Scaling Above" resolutions, a gauge's apparent size is the same as it would be if the screen resolution were the same as the first "$Force Scaling Above" resolution (that is, as small as it can get in the first case).
  • Above second "$Force Scaling Above" resolution, a gauge's apparent size is the same as it would be if the screen resolution were the same as the second "$Force Scaling Above" resolution (that is, smaller than it would be in the second case; apparent sizes in between would be impossible at any resolution).
Is this what you're thinking of? If so, can you describe a situation in which this would be useful?

Remember, the issue at hand is that HUD gauges are getting too small at high resolutions when scaling is disabled. My proposal helps to solve this by allowing modders to force scaling beyond a given resolution, limiting how small a gauge is allowed to appear. Your proposal does the same thing while allowing a gauge to suddenly shrink beyond a second given resolution, which pretty much defeats the purpose of this effort.

As far as I can tell, right now it IS, since the only hug gauges table I can find is mv_root-hdg.tbm the entirety of which is this.

Code: [Select]
;General Shenanigans

$Max Directives: 8
$Max Escort Ships: 13
$Scale Gauges: no

new flags are great and all, but we don't seem to be using the flags we have already for controlling position and scale.
The current stuff cannot be used to solve this problem; the position parameters only move gauges around, and the scaling parameters alone can only completely enable or disable scaling for a gauge, a HUD configuration, or all HUD configurations.
"Your fighter is running out of oil.  Please check under the hood and add more if necessary"
--strings.tbl, entry 177

"Freespace is very tired.  It is shutting down to get some rest."
--strings.tbl, entry 178

 

Offline BirdofPrey

  • 28
  • Help! I see GIMP in my sleep
He's saying have a flag that forces scaling above a certain resolution to THAT resolution.  I am saying make so you can have that flag multiple times.  So below the resolution of the first flag scaling is off.  Above the resolution of the first flag scale to that resolution, but above the second flag scale to the resolution listed there instead.
Here's the effect that your proposal would have, assuming that gauge scaling is disabled:
  • Between the HUD's base resolution and the first "$Force Scaling Above" resolution, a gauge's apparent size is reduced as the screen resolution increases.
  • Between the first and second "$Force Scaling Above" resolutions, a gauge's apparent size is the same as it would be if the screen resolution were the same as the first "$Force Scaling Above" resolution (that is, as small as it can get in the first case).
  • Above second "$Force Scaling Above" resolution, a gauge's apparent size is the same as it would be if the screen resolution were the same as the second "$Force Scaling Above" resolution (that is, smaller than it would be in the second case; apparent sizes in between would be impossible at any resolution).
Is this what you're thinking of? If so, can you describe a situation in which this would be useful?

Remember, the issue at hand is that HUD gauges are getting too small at high resolutions when scaling is disabled. My proposal helps to solve this by allowing modders to force scaling beyond a given resolution, limiting how small a gauge is allowed to appear. Your proposal does the same thing while allowing a gauge to suddenly shrink beyond a second given resolution, which pretty much defeats the purpose of this effort.
I think it does serve a purpose.  On a high resolution monitor, the gauges will be tiny, but if it's also a large monitor, with scaling on, the gauges end up being huge.  qA way to have something in between would be useful


Quote
As far as I can tell, right now it IS, since the only hug gauges table I can find is mv_root-hdg.tbm the entirety of which is this.

Code: [Select]
;General Shenanigans

$Max Directives: 8
$Max Escort Ships: 13
$Scale Gauges: no

new flags are great and all, but we don't seem to be using the flags we have already for controlling position and scale.
The current stuff cannot be used to solve this problem; the position parameters only move gauges around, and the scaling parameters alone can only completely enable or disable scaling for a gauge, a HUD configuration, or all HUD configurations.
I believe I already mentioned that problem, yes, and asked for a flag to actually set the scaling level of each gauge.

Still the lack of a table does have observable problems on wider monitors and multimonitor configurations, so the point about we need a proper gauges table stands.
The Great War ended 30 years ago.
Our elders tell stories of a glorious civilization; of people with myths of humanity everlasting, who hurled themselves into the void of space with no fear.

In testing: Radar Icons

 

Offline Yarn

  • 210
I think it does serve a purpose.  On a high resolution monitor, the gauges will be tiny, but if it's also a large monitor, with scaling on, the gauges end up being huge.  qA way to have something in between would be useful
Except you can't expect a monitor to be large just because it has a high resolution. Take Apple's Retina displays, for instance: One of them has a resolution of 2560x1600, yet it's only 13 inches large, not the 30 or 32 inches that it would be if it had the standard 96 DPI. If your proposal were utilized, then the HUD would be much too small on that display at that resolution.

(And please don't say something like "well, anyone playing on that display can just edit the table or use a different table." Tables are not for user settings.)

Still the lack of a table does have observable problems on wider monitors and multimonitor configurations, so the point about we need a proper gauges table stands.
I actually plan to look into addressing this in a way that won't require a HUD table.
"Your fighter is running out of oil.  Please check under the hood and add more if necessary"
--strings.tbl, entry 177

"Freespace is very tired.  It is shutting down to get some rest."
--strings.tbl, entry 178

 

Offline BirdofPrey

  • 28
  • Help! I see GIMP in my sleep
That's why I asked about if DPI was accessible to the game.  Your solution of scaling over a certain resolution has the same problems with high DPI monitors.

That's another reason HUD scaling should be a command line option that takes a value rather than a boolean in the table, but scaling built in to the table at least provides a good starting point that should work on most monitors since there still aren't very many retina displays used for desktops yet.  Also scaling each gauge individually let's you keep stuff like the radar large while minimizing other stuff.
The Great War ended 30 years ago.
Our elders tell stories of a glorious civilization; of people with myths of humanity everlasting, who hurled themselves into the void of space with no fear.

In testing: Radar Icons