Author Topic: [CODE REVIEW] Adaptable HUD, a.k.a. No more HUD stretching, for real this time  (Read 42280 times)

0 Members and 1 Guest are viewing this topic.

Offline Yarn

  • 210
[CODE REVIEW] Adaptable HUD, a.k.a. No more HUD stretching, for real this time
This patch has been committed, so just get the latest nightly build if you want try this feature yourself.

I managed to make HUD code that adapts the HUD to any resolution and aspect ratio correctly, without stretching. And it didn't require an overhaul.

Essentially, this code properly positions and scales HUD elements to suit the player's screen resolution and aspect ratio, whatever they happen to be, without the need for a custom HUD table. (And don't worry; existing custom HUDs should still work properly, but they won't fully benefit from my changes. It's possible to make a custom HUD that does, though.)

Here is the patch and some Windows builds. Be sure to try out various resolutions and aspect ratios, including unusual ones. (And make sure you aren't loading a custom HUD layout, or else none of these changes will take effect!)

All files here are currently based on revision 10174 (November 27, 2013).
Patch (The contents of the patch don't fit in one post, unfortunately.)
Windows build
Windows Blue Planet build

Now for the documentation.

The primary change is the addition of Origin: and Offset: to most gauges in hud_gauges.tbl. As an example, here is what the entry for the default afterburner gauge looks like with these new parameters:
Code: [Select]
+Afterburner Energy:
Origin: (0.5, 0.5)
Offset: (-238, 40)

The Origin: parameter, which takes two floating-point values between 0 and 1, specifies the resolution-independent point of the screen that the gauge should be positioned in relation to. For example, (0.0, 0.0) is the top-left, (0.5, 0.5) (used in the example above) is the center, and (1.0, 1.0) is the bottom-right. Any values from 0 to 1 may be used here, so an origin of, say, (0.316, 0.61) is valid.

The Offset: parameter takes two integers and specifies in pixels where the top-left pixel of the gauge should be positioned in relation to the specified origin. The example above uses (-238, 40) as its offset, which indicates that the gauge should be positioned 238 pixels to the right of and 40 pixels below the specified origin (which is (0.5, 0.5) in this case). Note that this parameter uses the adjusted base resolution (discussed below), not the screen resolution, to determine positioning.

For compatibility reasons (and HUD designers who do not wish to use the new system), the Position: parameter is still present and works the same as before. Any gauge using this parameter will not benefit from my patch and will thus potentially stretch.

Another change is the way the HUD's base resolution works for gauges that don't use the Position: parameter. For such gauges, if the HUD resolution's aspect ratio is not the same as the screen resolution's aspect ratio, one of the HUD resolution's dimensions (width or height) will be enlarged so that both ratios match. So, for example, if the HUD resolution is 1024x768 (4:3) and the screen resolution is 1440x900 (16:10), the HUD resolution will be expanded to 1228x768 (approximately 16:10). This is done before determining where to actually place the gauge.

This patch completely adapts the internal HUD to this system, so a hud_gauges.tbl or *-hdg.tbm is no longer needed to prevent the retail HUD from stretching.

I hope this description is clear enough. If you have any questions or comments about this patch, post them here.

And now, here are tabled versions of the built-in HUD. These are for reference and modding purposes only and should not be included with the MediaVPs.

FreeSpace 2:
Code: [Select]
#Gauge Config
$Base: (1024, 768)
$Min: (1024, 600)
$Gauges:
+Messages:
Origin: (0.0, 0.0)
Offset: (8, 5)
+Training Messages:
Origin: (0.5, 0.5)
Offset: (-133, -259)
+Support:
Origin: (0.5, 0.5)
Offset: (-53, 150)
+Damage:
Origin: (0.5, 0.0)
Offset: (-72, 61)
+Wingman Status:
Origin: (1.0, 0.0)
Offset: (-92, 144)
+Auto Speed:
Origin: (1.0, 1.0)
Offset: (-64, -96)
+Auto Target:
Origin: (1.0, 1.0)
Offset: (-64, -120)
+Countermeasures:
Origin: (1.0, 1.0)
Offset: (-144, -166)
+Talking Head:
Origin: (0.0, 0.0)
Offset: (5, 56)
+Directives:
Origin: (0.0, 0.5)
Offset: (5, -106)
+Weapons:
Origin: (1.0, 1.0)
Offset: (-144, -257)
+Objective Notify:
Origin: (0.5, 0.5)
Offset: (-76, -200)
+Squad Message:
Origin: (1.0, 0.0)
Offset: (-197, 5)
+Lag:
Origin: (0.5, 0.5)
Offset: (115, 145)
+Mini Target Shields:
Origin: (0.5, 0.5)
Offset: (-15, 86)
+Player Shields:
Origin: (0.5, 1.0)
Offset: (112, -98)
+Target Shields:
Origin: (0.5, 1.0)
Offset: (-220, -98)
+Escort View:
Origin: (1.0, 0.5)
Offset: (-159, -54)
+Mission Time:
Origin: (1.0, 1.0)
Offset: (-55, -52)
+Target Monitor:
Origin: (0.0, 1.0)
Offset: (5, -178)
+Extra Target Data:
Origin: (0.0, 1.0)
Offset: (5, -216)
+Radar:
Origin: (0.5, 1.0)
Offset: (-101, -178)
+Afterburner Energy:
Origin: (0.5, 0.5)
Offset: (-238, 40)
+Weapon Energy:
Origin: (0.5, 0.5)
Offset: (154, 40)
+Text Warnings:
Origin: (0.5, 0.5)
Offset: (0, -109)
+Center Reticle:
Origin: (0.5, 0.5)
Offset: (-19, -14)
+Throttle:
Origin: (0.5, 0.5)
Offset: (-166, -115)
+Threat Indicator:
Origin: (0.5, 0.5)
Offset: (62, -115)
+Lead Indicator:
+Lock Indicator:
+Multiplayer Messages:
Origin: (0.0, 0.5)
Offset: (8, -144)
+Voice Status:
Origin: (0.0, 0.5)
Offset: (8, -129)
+Ping:
Origin: (1.0, 0.0)
Offset: (-128, 5)
+Supernova:
Origin: (0.5, 0.5)
Offset: (-342, -214)
+Offscreen Indicator:
+Target Brackets:
+Orientation Tee:
Origin: (0.5, 0.5)
Offset: (0, 3)
+Hostile Triangle:
Origin: (0.5, 0.5)
Offset: (0, 3)
+Target Triangle:
Origin: (0.5, 0.5)
Offset: (0, 3)
+Missile Triangles:
Origin: (0.5, 0.5)
Offset: (0, 3)
+Kills:
Origin: (1.0, 1.0)
Offset: (-144, -144)
+Fixed Messages:
+ETS Retail:
Origin: (1.0, 1.0)
Offset: (-144, -120)
$End Gauges
#End

FreeSpace Port:
Code: [Select]
$Reticle Style: FS1

#Gauge Config
$Base: (1024, 768)
$Min: (1024, 600)
$Gauges:
+Messages:
Origin: (0.0, 0.0)
Offset: (8, 5)
+Training Messages:
Origin: (0.5, 0.5)
Offset: (-133, -259)
+Support:
Origin: (0.5, 0.5)
Offset: (-53, 150)
+Damage:
Origin: (0.5, 0.0)
Offset: (-72, 61)
+Wingman Status:
Origin: (1.0, 0.0)
Offset: (-92, 144)
+Auto Speed:
Origin: (1.0, 1.0)
Offset: (-64, -96)
+Auto Target:
Origin: (1.0, 1.0)
Offset: (-64, -120)
+Countermeasures:
Origin: (1.0, 1.0)
Offset: (-144, -166)
+Talking Head:
Origin: (0.0, 0.0)
Offset: (5, 56)
+Directives:
Origin: (0.0, 0.5)
Offset: (5, -106)
+Weapons:
Origin: (1.0, 1.0)
Offset: (-144, -257)
+Objective Notify:
Origin: (0.5, 0.5)
Offset: (-76, -200)
+Squad Message:
Origin: (1.0, 0.0)
Offset: (-197, 5)
+Lag:
Origin: (0.5, 0.5)
Offset: (115, 145)
+Mini Target Shields:
Origin: (0.5, 0.5)
Offset: (-15, 86)
+Player Shields:
Origin: (0.5, 1.0)
Offset: (112, -98)
+Target Shields:
Origin: (0.5, 1.0)
Offset: (-220, -98)
+Escort View:
Origin: (1.0, 0.5)
Offset: (-159, -54)
+Mission Time:
Origin: (1.0, 1.0)
Offset: (-55, -52)
+Target Monitor:
Origin: (0.0, 1.0)
Offset: (5, -178)
+Extra Target Data:
Origin: (0.0, 1.0)
Offset: (5, -216)
+Radar:
Origin: (0.5, 1.0)
Offset: (-101, -178)
+Afterburner Energy:
Origin: (0.5, 0.5)
Offset: (-238, 40)
+Weapon Energy:
Origin: (0.5, 0.5)
Offset: (154, 40)
+Text Warnings:
Origin: (0.5, 0.5)
Offset: (0, -109)
+Center Reticle:
Origin: (0.5, 0.5)
Offset: (-19, -8)
+Throttle:
Origin: (0.5, 0.5)
Offset: (-165, 6)
+Threat Indicator:
Origin: (0.5, 0.5)
Offset: (-126, -165)
+Lead Indicator:
+Lock Indicator:
+Weapon Linking:
Origin: (0.5, 0.5)
Offset: (86, 3)
+Multiplayer Messages:
Origin: (0.0, 0.5)
Offset: (8, -144)
+Voice Status:
Origin: (0.0, 0.5)
Offset: (8, -129)
+Ping:
Origin: (1.0, 0.0)
Offset: (-128, 5)
+Supernova:
Origin: (0.5, 0.5)
Offset: (-342, -214)
+Offscreen Indicator:
+Target Brackets:
+Orientation Tee:
Origin: (0.5, 0.5)
Offset: (0, 3)
+Hostile Triangle:
Origin: (0.5, 0.5)
Offset: (0, 3)
+Target Triangle:
Origin: (0.5, 0.5)
Offset: (0, 3)
+Missile Triangles:
Origin: (0.5, 0.5)
Offset: (0, 3)
+Kills:
Origin: (1.0, 1.0)
Offset: (-144, -144)
+Fixed Messages:
+ETS Retail:
Origin: (1.0, 1.0)
Offset: (-144, -120)
$End Gauges
#End


(Yes, I understand that we're in a feature freeze right now. I just wanted to make this patch available now.)
« Last Edit: January 04, 2014, 10:18:28 pm by Yarn »
"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 General Battuta

  • Poe's Law In Action
  • 214
  • i wonder when my postcount will exceed my iq
Re: Adaptable HUD, a.k.a. No more HUD stretching, for real this time (with patch!)
phwoar!

 

Offline zookeeper

  • *knock knock* Who's there? Poe. Poe who?
  • 210
Re: Adaptable HUD, a.k.a. No more HUD stretching, for real this time (with patch!)
Sounds excellent. :eek2:

 

Offline KyadCK

  • 29
  • Getting better with every game
    • Minecraft
    • Steam
Re: Adaptable HUD, a.k.a. No more HUD stretching, for real this time (with patch!)
3440x1920 with patch:


3440x1920 without patch:


5760x1920 with patch:


5760x1920 without patch:


Unusual enough for you?

I don't suppose there could be an option for extremely wide resolutions to have the HUD centered? It's not hard to fix it manualy, I already have a hud for it and everything, just wondering if it can be done.
Freespace Wallpapers     BluePlanet Multi     Minecraft Deimos Build Log
Need help setting up Multi? Then join us on the Multi-Setup IRC channel!
Computers only fear those who know how to use them

 

Offline Yarn

  • 210
Re: Adaptable HUD, a.k.a. No more HUD stretching, for real this time (with patch!)
Just to let you guys know, the FPS counter and subsystem targeting brackets are still stretched in widescreen resolutions. These issues do not appear to have anything to do with the HUD parser, which is the only thing that my patch changes (aside from the addition of that command-line switch). I'll try to tackle them later, though.

I don't suppose there could be an option for extremely wide resolutions to have the HUD centered? It's not hard to fix it manualy, I already have a hud for it and everything, just wondering if it can be done.
That should be possible. Perhaps if the aspect ratio is 3:1 or wider, we could assume the player is using a triplehead setup and place all the HUD elements in the middle third of the frame, effectively making the HUD use the center screen only. What do you think?
"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 General Battuta

  • Poe's Law In Action
  • 214
  • i wonder when my postcount will exceed my iq
Re: Adaptable HUD, a.k.a. No more HUD stretching, for real this time (with patch!)
Kyad, how ****ed up is the BP2R2 custom hud on those resolutions, using Yarn's patch?

 

Offline KyadCK

  • 29
  • Getting better with every game
    • Minecraft
    • Steam
Re: Adaptable HUD, a.k.a. No more HUD stretching, for real this time (with patch!)
Just to let you guys know, the FPS counter and subsystem targeting brackets are still stretched in widescreen resolutions. These issues do not appear to have anything to do with the HUD parser, which is the only thing that my patch changes (aside from the addition of that command-line switch). I'll try to tackle them later, though.

I don't suppose there could be an option for extremely wide resolutions to have the HUD centered? It's not hard to fix it manualy, I already have a hud for it and everything, just wondering if it can be done.
That should be possible. Perhaps if the aspect ratio is 3:1 or wider, we could assume the player is using a triplehead setup and place all the HUD elements in the middle third of the frame, effectively making the HUD use the center screen only. What do you think?

I think that'll work. Maybe a bit smaller than the center 3rd though, as people gaming with 3 screen will compensate for the bezel like I did, and some of it will be lost into nothingness.

Then again, it's impossible to predict just how far they have compensated, as I learned from my own hud, so it may be more effort than it's worth. Even with Eyefinity on, there is still an option in the launcher to use uncompensated resolution, so it won't completely screw people over to not support it.

Kyad, how ****ed up is the BP2R2 custom hud on those resolutions, using Yarn's patch?

Well, Yarn said custom huds don't get to use his code unless they're adapted, so it'll look the same as they do without it (which is not bad actually for 3440x1920, perfectly playable), but 5760x1080 it'll strech out, that's why I made my ultra-widescreen HUD, which I guess is outdated now. If Yarn want's to tell me how to adapt the hud I'll try it though.

But ya, the HUD doesn't look bad:


All it needs for 5760x1080 on the "old" HUD code is to be centered, and that's easy. It'd take me like 3 hours, tops.

BP doesn't want to work with his EXE, and I'm not set up to compile, nor do i have access to BP's version of the source (or is it just antipodes?), so that wouldn't work anyway. If you want to make a build for me so I can actually use his code with BP so the custom gauges will be used it'd be appreciated, but until the HUD is adapted, it'll look the same. (Or so I understand it)
« Last Edit: April 13, 2013, 07:10:33 pm by KyadCK »
Freespace Wallpapers     BluePlanet Multi     Minecraft Deimos Build Log
Need help setting up Multi? Then join us on the Multi-Setup IRC channel!
Computers only fear those who know how to use them

 

Offline Yarn

  • 210
Re: Adaptable HUD, a.k.a. No more HUD stretching, for real this time (with patch!)
I uploaded a Blue Planet build for you.

I would certainly like to explain the changes and how to make an adaptable HUD. Keep in mind that I have difficulty explaining this sort of thing, so it will probably be days, maybe longer, before I release any documentation. However, I will make a HUD table that is equivalent to the hard-coded HUD, and then maybe you or someone else can figure it out from that until I do document the adaptable HUD.
"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 KyadCK

  • 29
  • Getting better with every game
    • Minecraft
    • Steam
Re: Adaptable HUD, a.k.a. No more HUD stretching, for real this time (with patch!)
I uploaded a Blue Planet build for you.

I would certainly like to explain the changes and how to make an adaptable HUD. Keep in mind that I have difficulty explaining this sort of thing, so it will probably be days, maybe longer, before I release any documentation. However, I will make a HUD table that is equivalent to the hard-coded HUD, and then maybe you or someone else can figure it out from that until I do document the adaptable HUD.

BP build you uploaded doesn't work, line failure in question:
Code: [Select]
bp-shp.tbm(line 222): Error: Required token = [#End], [$Subsystem:], [$Name], or [$Template], found [$Glowpoint overrides: ( "red_glow_10:1,2" )].

ERROR: bp-shp.tbm(line 222):
Error: Required token = [#End], [$Subsystem:], [$Name], or [$Template], found [$Glowpoint overrides: ( "red_glow_10:1,2" )].
http://pastebin.com/PfanP9mu

The build supplied by BP works. I'm guessing it has something to do with the deferred lighting code, and the additional TBM options to allow for glow points to glow. It fails that same line for your normal HUD build, and for all other builds I've used.

A HUD made for your HUD code should be enough to adapt the rest.
Freespace Wallpapers     BluePlanet Multi     Minecraft Deimos Build Log
Need help setting up Multi? Then join us on the Multi-Setup IRC channel!
Computers only fear those who know how to use them

 

Offline Yarn

  • 210
Re: Adaptable HUD, a.k.a. No more HUD stretching, for real this time (with patch!)
BP build you uploaded doesn't work
I accidentally linked to the regular build. Try downloading it again.

"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 KyadCK

  • 29
  • Getting better with every game
    • Minecraft
    • Steam
Re: Adaptable HUD, a.k.a. No more HUD stretching, for real this time (with patch!)
BP build you uploaded doesn't work
I accidentally linked to the regular build. Try downloading it again.

Ah, much better.

Patch:


No patch:
Freespace Wallpapers     BluePlanet Multi     Minecraft Deimos Build Log
Need help setting up Multi? Then join us on the Multi-Setup IRC channel!
Computers only fear those who know how to use them

 

Offline Kolgena

  • 211
Re: Adaptable HUD, a.k.a. No more HUD stretching, for real this time (with patch!)
One last gauge to check is the Camera reticle element when you player Tower Defense.

This looks freaking fantastic. Good work. Also, for triple-screen, be sure to factor in beveling somehow when moving all the side elements to the middle monitor.

 

Offline Yarn

  • 210
Re: Adaptable HUD, a.k.a. No more HUD stretching, for real this time (with patch!)
I updated the patch and the builds. Be sure to use them if you want to make or use custom adaptable HUDs because I changed the HUD table format slightly. (Current custom HUDs should still be compatible.)

Now then, here are tabled versions of the built-in HUD. These are for reference and modding purposes only and should not be included with the MediaVPs.

(EDIT: The tables are now in the original post.)

The three-monitor adjustment is going to be trickier than I originally thought. If the HUD elements are simply moved to the center third, I'll run the risk of causing elements to overlap. I'll need some time to figure out how to do this properly. As for bezel compensation, I think I will initially add a command-line parameter to let the user adjust this manually.
« Last Edit: May 10, 2013, 12:08:08 am by Yarn »
"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 KyadCK

  • 29
  • Getting better with every game
    • Minecraft
    • Steam
Re: Adaptable HUD, a.k.a. No more HUD stretching, for real this time (with patch!)
Would it be possible to remove the HUD's dependance on the chosen resolution?

Like a -HUDres flag, to act like the -res flag. Defaults to the res chosen in the launcher, but if smaller, put it in the chosen resolution, and center it against the full res?

Most people wouldn't need the assistance of the flag, only those with multi-monitor configs. It would still be much less effort over all (to the end user) to add, say, "-HUDres 1920x1080" to the launcher flags then to have to get a special hud. It would also allow people who use 2560x1600 screens with a 1600x900 in portrait on either side to do it better themselves than anyone could by guessing, and even give normal users the option to center the HUD a bit.

I have no idea how much effort it would take, but it's an idea.

I think I understand the HUD as well.


Am I right?
Freespace Wallpapers     BluePlanet Multi     Minecraft Deimos Build Log
Need help setting up Multi? Then join us on the Multi-Setup IRC channel!
Computers only fear those who know how to use them

 

Offline Yarn

  • 210
Re: Adaptable HUD, a.k.a. No more HUD stretching, for real this time (with patch!)
I think I understand the HUD as well.
(nice diagram describing the new HUD system)

Am I right?
Yes, exactly! And you're not limited to those specific origins either; any values from 0.0 to 1.0, to any number of decimal places, can be used. (Technically, you can use values outside that range, but then you would move the origin off the screen, so there's no point in doing that.)

When positioning the gauges, remember not to use the Position field together with the Origin and Offset fields. If you do, the gauge will probably be loaded the "old" way and not benefit from the code change. Also, the Origin field has no effect unless it's used together with the Offset field.

Would it be possible to remove the HUD's dependance on the chosen resolution?

Like a -HUDres flag, to act like the -res flag. Defaults to the res chosen in the launcher, but if smaller, put it in the chosen resolution, and center it against the full res?

Most people wouldn't need the assistance of the flag, only those with multi-monitor configs. It would still be much less effort over all (to the end user) to add, say, "-HUDres 1920x1080" to the launcher flags then to have to get a special hud. It would also allow people who use 2560x1600 screens with a 1600x900 in portrait on either side to do it better themselves than anyone could by guessing, and even give normal users the option to center the HUD a bit.

I have no idea how much effort it would take, but it's an idea.
I see what you're getting at. However, I think it's a better idea to specify a maximum width instead. For example, if the player's center screen has a 16:9 aspect ratio, they could use "-max_hud_width 1.77" (16 / 9 = about 1.77) to prevent the HUD from being wider than 16:9.

I'll see what I can do about that.
"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 Nuke

  • Ka-Boom!
  • 212
  • Mutants Worship Me
Re: Adaptable HUD, a.k.a. No more HUD stretching, for real this time (with patch!)
i figure scale gauges proportionally with the vertical resolution, increase horizontal spacing between gauges as a function of aspect ratio. no matter what maintain gauge aspect ratio.
I can no longer sit back and allow communist infiltration, communist indoctrination, communist subversion, and the international communist conspiracy to sap and impurify all of our precious bodily fluids.

Nuke's Scripting SVN

 

Offline coffeesoft

  • 28
  • Bip Bip
Re: Adaptable HUD, a.k.a. No more HUD stretching, for real this time (with patch!)
Great !! let´s try it   :yes:

 

Offline Swifty

  • 210
  • I reject your fantasy & substitute my own
Re: Adaptable HUD, a.k.a. No more HUD stretching, for real this time (with patch!)
So this is actually a pretty cool feature and does some things I was planning for the HUD table.

However, I think HUD designers should have the sole power to determine if a HUD uses absolute or relative coordinates. The reason why I say this is that HUD designers need to be able to control every aspect of the HUD's appearance which is why I introduced base resolutions and resolution filters in the first place. We should maximize the number of tools modders have at their disposal when designing a HUD. Adding more tools for modders to control HUD appearance is always a good thing. Giving HUD designers the ability to determine relative coordinates but only letting them be used based off of the users' discretion doesn't sound very incentivizing use.

I guess this limits the ability for retail FSO to take advantage of this feature but I'm sure we can discuss some solutions.

In order to address some of these issues people have with super wide screens we should have a option in hud_gauges.tbl that determines scaling behavior that includes but isn't limited to something like "Fill to Best Fit" or something like that.
« Last Edit: April 22, 2013, 03:30:12 am by Swifty »

 

Offline Yarn

  • 210
Re: Adaptable HUD, a.k.a. No more HUD stretching, for real this time (with patch!)
So this is actually a pretty cool feature and does some things I was planning for the HUD table.

However, I think HUD designers should have the sole power to determine if a HUD uses absolute or relative coordinates. The reason why I say this is that HUD designers need to be able to control every aspect of the HUD's appearance which is why I introduced base resolutions and resolution filters in the first place. We should maximize the number of tools modders have at their disposal when designing a HUD. Adding more tools for modders to control HUD appearance is always a good thing. Giving HUD designers the ability to determine relative coordinates but only letting them be used based off of the users' discretion doesn't sound very incentivizing use.

I guess this limits the ability for retail FSO to take advantage of this feature but I'm sure we can discuss some solutions.
My patch already provides HUD designers with the option of whether to use absolute or relative coordinates. Gauges positioned with Position: use the current system (which potentially distorts elements), while those positioned with Origin:/Offset: use the "new" system (which never distorts). HUDs can even mix and match these types of gauges.

In order to address some of these issues people have with super wide screens we should have a option in hud_gauges.tbl that determines scaling behavior that includes but isn't limited to something like "Fill to Best Fit" or something like that.
I already proposed a solution to this that doesn't require messing with tables:
However, I think it's a better idea to specify a maximum width instead. For example, if the player's center screen has a 16:9 aspect ratio, they could use "-max_hud_width 1.77" (16 / 9 = about 1.77) to prevent the HUD from being wider than 16:9.
"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 KyadCK

  • 29
  • Getting better with every game
    • Minecraft
    • Steam
Re: Adaptable HUD, a.k.a. No more HUD stretching, for real this time (with patch!)
So this is actually a pretty cool feature and does some things I was planning for the HUD table.

However, I think HUD designers should have the sole power to determine if a HUD uses absolute or relative coordinates. The reason why I say this is that HUD designers need to be able to control every aspect of the HUD's appearance which is why I introduced base resolutions and resolution filters in the first place. We should maximize the number of tools modders have at their disposal when designing a HUD. Adding more tools for modders to control HUD appearance is always a good thing. Giving HUD designers the ability to determine relative coordinates but only letting them be used based off of the users' discretion doesn't sound very incentivizing use.

I guess this limits the ability for retail FSO to take advantage of this feature but I'm sure we can discuss some solutions.
My patch already provides HUD designers with the option of whether to use absolute or relative coordinates. Gauges positioned with Position: use the current system (which potentially distorts elements), while those positioned with Origin:/Offset: use the "new" system (which never distorts). HUDs can even mix and match these types of gauges.

In order to address some of these issues people have with super wide screens we should have a option in hud_gauges.tbl that determines scaling behavior that includes but isn't limited to something like "Fill to Best Fit" or something like that.
I already proposed a solution to this that doesn't require messing with tables:
However, I think it's a better idea to specify a maximum width instead. For example, if the player's center screen has a 16:9 aspect ratio, they could use "-max_hud_width 1.77" (16 / 9 = about 1.77) to prevent the HUD from being wider than 16:9.

Regarding that last, I still think that, to the player, it should be in numerical form, not decimal.

I could be wrong, but it doesn't seem like it would be hard to have the HUD code actually do 1920 / 1080 to get 1.77, or 16 / 9 for the same. Less work and more seemless for the player, if you catch my drift. The FOV flag is a serious pain to work with for the same reason, and I would honestly try to avoid that if at all possible.
Freespace Wallpapers     BluePlanet Multi     Minecraft Deimos Build Log
Need help setting up Multi? Then join us on the Multi-Setup IRC channel!
Computers only fear those who know how to use them