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

0 Members and 1 Guest are viewing this topic.

Offline niffiwan

  • 211
  • Eluder Class
Re: [CODE REVIEW] Adaptable HUD, a.k.a. No more HUD stretching, for real this time
Setting aside the fact that your origin value here is way off for the default reticle, your example here will cause the reticle to go off-center if the game's aspect ratio doesn't match that of the specified base resolution. Do the same with the other gauges and everything can become misaligned. It's almost never a good idea to place the origin where the top-left of the gauge would be in the base resolution. Even placing the origin in the center of the gauge can cause misalignment if the modder isn't careful. I designed the internal HUD the way it is for a reason.

Just remember that the origin parameter alone isn't meant to specify where exactly the gauge is; it's meant to be used with the offset parameter to do that. It's probably a good idea to require an offset to be specified if an origin is also specified.

It looks like the modding community could use some guidelines for origin placement, so I'll make a list of those soon.

Thanks for the reply, the example I used was just the table from the USCDM that MattH released recently.  You are correct that it's not very centred in the Y axis, I didn't actually look at the Y value much as I was concentrating on the X value.

Therefore we can forget about the current proposed change to zero the Offsets if Origin is specified, and instead require Offsets if Origin is specified.  However, should Offsets be allowed to be specified by itself without Origin?

That leaves us with Axem's request about having gauges that don't scale when the screen res is different to the base res.  How can this be achieved with the current code?  Do there need to be multiple resolutions specified in the table? i.e. Base/Min/Max 1440x900 + all gauge positions specified, Base/Min/Max 1680x1050 + all gauge positions specified (repeat for all resolutions).  Because the issue I can see is that if the gauges don't scale, then their alignment will be affected, to avoid that you'd have to specify the gauge position for each res  :ick:

Could some trickery be done to find the gauge graphic size and use that as a reference to reposition the non-scaled gauge within the centre of area that the scaled up gauge would have resided in?

I don't really know how other PC games make non-stretching HUDs that work with multiple aspect ratios. If any have a more intuitive approach, I'd like to hear about them.

I believe this is quite popular (Scaleform UI and it seems to use vector graphics rather than bitmaps to avoid the image scaling issue.

Maybe another solution is to fix the res to 16:9 aspect and letterbox other resolutions? :shrug: (or that "solution" may start a holy war...)

edit: spelling
« Last Edit: December 20, 2013, 01:54:41 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 Mongoose

  • Rikki-Tikki-Tavi
  • Global Moderator
  • 212
  • This brain for rent.
    • Minecraft
    • Steam
    • Something
Re: [CODE REVIEW] Adaptable HUD, a.k.a. No more HUD stretching, for real this time
yeahno we're not doing that :p

 

Offline Kiloku

  • 27
  • Buzzbuzz!
    • Minecraft
Re: [CODE REVIEW] Adaptable HUD, a.k.a. No more HUD stretching, for real this time
Vector graphics based UIs would be great. Would that even be feasible? Maybe with the upcoming change to SDL?
Potato!

 

Offline z64555

  • 210
  • Self-proclaimed controls expert
    • Minecraft
    • Steam
Re: [CODE REVIEW] Adaptable HUD, a.k.a. No more HUD stretching, for real this time
Vector graphics based UIs would be great. Would that even be feasible? Maybe with the upcoming change to SDL?

No, SDL is mainly controls related. There's some graphics related changes, yes, but we're still using OpenGL for the graphics calls. OpenGL doesn't have any vector graphics support by itself.
Secure the Source, Contain the Code, Protect the Project
chief1983

------------
funtapaz: Hunchon University biologists prove mankind is evolving to new, higher form of life, known as Homopithecus Juche.
z64555: s/J/Do
BotenAlfred: <funtapaz> Hunchon University biologists prove mankind is evolving to new, higher form of life, known as Homopithecus Douche.

 

Offline niffiwan

  • 211
  • Eluder Class
Re: [CODE REVIEW] Adaptable HUD, a.k.a. No more HUD stretching, for real this time
I'm doing some testing to confirm to myself how this all currently works, maybe screenies would help modders understand what's going on as well.  But I got slightly distracted along the way, so here's a patch that doesn't scale the FPS counter or the Memory usage display:

https://github.com/niffiwan/fs2open.github.com/commit/c74a7c3edd5df69c40f57dece0cd95b2017af530

Any comments? I figured that since these are not really part of the game/hud, they don't ever need to scale, and I know from recent experience that they look horrid on very wide resolutions.

edit: spelling!  And another thought, since they're now fixed width maybe a constant ~160 pixels in from gr_screen.max_w would work better than ~80%
« Last Edit: December 22, 2013, 03:53:02 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 Yarn

  • 210
Re: [CODE REVIEW] Adaptable HUD, a.k.a. No more HUD stretching, for real this time
However, should Offsets be allowed to be specified by itself without Origin?
Yes, and in this case, the default origin should be used.

That leaves us with Axem's request about having gauges that don't scale when the screen res is different to the base res.  How can this be achieved with the current code?  Do there need to be multiple resolutions specified in the table? i.e. Base/Min/Max 1440x900 + all gauge positions specified, Base/Min/Max 1680x1050 + all gauge positions specified (repeat for all resolutions).  Because the issue I can see is that if the gauges don't scale, then their alignment will be affected, to avoid that you'd have to specify the gauge position for each res  :ick:
I originally had a command-line switch to disable HUD scaling for gauges that don't use the Position parameter (like the new built-in HUD), but I removed it because Swifty didn't like the idea. Implementing this again, whether as a command-line switch or as a hud_gauges.tbl parameter, is as simple as changing the condition of the first if statement in adjust_base_res(). And there are no alignment issues to worry about if the HUD is designed correctly.

Could some trickery be done to find the gauge graphic size and use that as a reference to reposition the non-scaled gauge within the centre of area that the scaled up gauge would have resided in?
This will only cause alignment issues and is completely unnecessary.

Maybe another solution is to fix the res to 16:9 aspect and letterbox other resolutions? :shrug: (or that "solution" may start a holy war...)
NO.
« Last Edit: December 21, 2013, 07:52:26 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

 
Re: [CODE REVIEW] Adaptable HUD, a.k.a. No more HUD stretching, for real this time
Hey guys, I'm sorry to ask a dumb question but I've searched this thread and can't seem to find the answer.

Where do I need to put the custom_hud.tbl file to utilize my custom hud?  Is there an FAQ about stuff like this?

CobaltRed

***RETURNS TO LURKER HOLE***

 

Offline Rodo

  • Custom tittle
  • 212
  • stargazer
    • Minecraft
    • Steam
Re: [CODE REVIEW] Adaptable HUD, a.k.a. No more HUD stretching, for real this time
IIRC it's: "yourmod/data/tables"
el hombre vicio...

 

Offline z64555

  • 210
  • Self-proclaimed controls expert
    • Minecraft
    • Steam
Re: [CODE REVIEW] Adaptable HUD, a.k.a. No more HUD stretching, for real this time
...we can forget about the current proposed change to zero the Offsets if Origin is specified, and instead require Offsets if Origin is specified.  However, should Offsets be allowed to be specified by itself without Origin?

I wouldn't recommend allowing only Offsets to be defined, because not all gauge types have a default Origin, only the original gauges and a handful of their replacements do.

Quote
That leaves us with Axem's request about having gauges that don't scale when the screen res is different to the base res.  How can this be achieved with the current code?  Do there need to be multiple resolutions specified in the table? i.e. Base/Min/Max 1440x900 + all gauge positions specified, Base/Min/Max 1680x1050 + all gauge positions specified (repeat for all resolutions).  Because the issue I can see is that if the gauges don't scale, then their alignment will be affected, to avoid that you'd have to specify the gauge position for each res  :ick:

Could some trickery be done to find the gauge graphic size and use that as a reference to reposition the non-scaled gauge within the centre of area that the scaled up gauge would have resided in?

I would recommend the Offsets be referenced to the graphic's resolution in pixels, and likewise have the graphic's scaling factor applied to it. That way, as the graphic grows/shrinks, it'll still have the offset relative to the graphics position. Going back to the Aiming crosshairs example, The origin may be defined at (0.5, 0.5) and the offset could be defined as the center of the crosshairs, wherever that may be. As the graphic is scaled up or down, the offset will still point at the center of the crosshairs, thereby ensuring the alignment.

We could perhaps restrict scaling in a particular direction, such as scaling down for lower resolutions, but not scaling up for higher resolutions... just shifting its position along with the Origin. Having the offsets referenced to the graphic's resolution would help here too.

We may also benefit from "Gauge Clusters" for those gauges that need to be side-by-side and scale appropriately. The Cluster could then have its origin, offset, and size defined.

Alternatively, we could define a padding border around the gauges to prevent overlap at smaller resolutions. This'll work for some simple clusters, but probably not very well for complex clusters.

Quote
Maybe another solution is to fix the res to 16:9 aspect and letterbox other resolutions? :shrug: (or that "solution" may start a holy war...)

Very would likely cause an angry mob with torches and pitchforks... Maybe not only for the 4:3 folk, but also the 16:10 and others.
Secure the Source, Contain the Code, Protect the Project
chief1983

------------
funtapaz: Hunchon University biologists prove mankind is evolving to new, higher form of life, known as Homopithecus Juche.
z64555: s/J/Do
BotenAlfred: <funtapaz> Hunchon University biologists prove mankind is evolving to new, higher form of life, known as Homopithecus Douche.

 

Offline Yarn

  • 210
Re: [CODE REVIEW] Adaptable HUD, a.k.a. No more HUD stretching, for real this time
I wouldn't recommend allowing only Offsets to be defined, because not all gauge types have a default Origin, only the original gauges and a handful of their replacements do.
Actually, all gauges that can take position information have a default origin. Still, it's probably a good idea to require Origin and Offset to be specified together.

I would recommend the Offsets be referenced to the graphic's resolution in pixels, and likewise have the graphic's scaling factor applied to it. That way, as the graphic grows/shrinks, it'll still have the offset relative to the graphics position. Going back to the Aiming crosshairs example, The origin may be defined at (0.5, 0.5) and the offset could be defined as the center of the crosshairs, wherever that may be. As the graphic is scaled up or down, the offset will still point at the center of the crosshairs, thereby ensuring the alignment.
If Offset is defined in this manner, then it should be called something else. Also remember, once again, that the origin can lie well outside the graphic's boundaries (the internal HUD does just this for many gauges).

We could perhaps restrict scaling in a particular direction, such as scaling down for lower resolutions, but not scaling up for higher resolutions... just shifting its position along with the Origin. Having the offsets referenced to the graphic's resolution would help here too.
Implementing this behavior in the current system requires only a minor tweak of an if statement. However, this would result in tiny gauges for extreme resolutions (think 4K), regardless of how Offset works.

We may also benefit from "Gauge Clusters" for those gauges that need to be side-by-side and scale appropriately. The Cluster could then have its origin, offset, and size defined.
This might be a good idea, although there's no reason to define a size.

Alternatively, we could define a padding border around the gauges to prevent overlap at smaller resolutions. This'll work for some simple clusters, but probably not very well for complex clusters.
This is completely unnecessary because the game never shrinks the base resolution's dimensions, it only expands them. Should the game's aspect ratio be narrower than that of the base resolution, then the height is increased while the width is left alone.
"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 Yarn

  • 210
Re: [CODE REVIEW] Adaptable HUD, a.k.a. No more HUD stretching, for real this time
I have an idea. We could use z64555's idea of gauge clusters, but have it take only two parameters: "Name" and "Position". "Name" is self-explanitory, while "Position" has the same format and effect as Origin currently does. There would be nine default clusters: Top Left (0.0, 0.0), Top Center (0.5, 0.0), Top Right (1.0, 0.0), Center Left (0.0, 0.5), Center (0.5, 0.5), Center Right (1.0, 0.5), Bottom Left (0.0, 1.0), Bottom Center (0.5, 1.0), and Bottom Right (1.0, 1.0). More can be created in hud_gauges.tbl.

A non-stretching gauge would take two parameters for positioning: "Cluster" and "Position". "Cluster" refers to a gauge cluster by its name and uses its Position parameter in the same way that Origin is used now. "Position" is takes two integers and specifies in pixels where the top-left of a gauge is positioned in relation to the cluster's position.

Note that, with this system, if a gauge uses Position but not Cluster, then the old positioning system will be used. Therefore, if a gauge should never stretch, then it must use both parameters or none of them. (It's probably a good idea to use a different word for Position in this case, but I haven't thought of one yet.)

Here's what the default HUD might look like with this system:
Code: [Select]
#Gauge Clusters
$Name: Top Left
$Position: (0.0, 0.0)

$Name: Top Center
$Position: (0.5, 0.0)

$Name: Top Right
$Position: (1.0, 0.0)

$Name: Center Left
$Position: (0.0, 0.5)

$Name: Center
$Position: (0.5, 0.5)

$Name: Center Right
$Position: (1.0, 0.5)

$Name: Bottom Left
$Position: (0.0, 1.0)

$Name: Bottom Center
$Position: (0.5, 1.0)

$Name: Bottom Right
$Position: (1.0, 1.0)
#End

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

  • Cutscene Master
  • 212
  • Chopped liver
    • Steam
    • Twitter
Re: [CODE REVIEW] Adaptable HUD, a.k.a. No more HUD stretching, for real this time
That just seems.... Overly complicated.

You said you have a simple switch to disable gauge stretching... Why can't we just have that?
Cutscene Upgrade Project - Mainhall Remakes - Between the Ashes
Youtube Channel - P3D Model Box
Between the Ashes is looking for committed testers, PM me for details.
Freespace Upgrade Project See what's happening.

 

Offline Yarn

  • 210
Re: [CODE REVIEW] Adaptable HUD, a.k.a. No more HUD stretching, for real this time
You said you have a simple switch to disable gauge stretching... Why can't we just have that?
If you're referring to distortion, then that's not quite what I said; I said that I could disable scaling, and it would work only with HUDs that don't stretch anyway.

To be clear, if a HUD uses the old positioning system, there is absolutely no way to keep it from stretching without utterly messing up the layout. If there were, then I would have implemented that feature in the first place. That is why I designed the new system the way it is. And people are finding it confusing, so we're thinking of ways to make it more intuitive. Unfortunately, there's just no way to make it as simple as the old two-coordinate system.
"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 niffiwan

  • 211
  • Eluder Class
Re: [CODE REVIEW] Adaptable HUD, a.k.a. No more HUD stretching, for real this time
The patch to add in a per-gauge option to disable scaling is simple:

Code: [Select]
diff --git a/code/hud/hudparse.cpp b/code/hud/hudparse.cpp
index 2b9839c..aff6bd2 100644
--- a/code/hud/hudparse.cpp
+++ b/code/hud/hudparse.cpp
@@ -1061,10 +1061,11 @@ void check_color(int *colorp)
        }
 }
 
-void adjust_base_res(int *base_res)
+void adjust_base_res(int *base_res, bool scaling = true)
 {
        // Avoid HUD blurring caused solely by rounding errors
-       if ((gr_screen.max_w >= base_res[0] && gr_screen.max_h == base_res[1]) ||
+       if ( !scaling ||
+                       (gr_screen.max_w >= base_res[0] && gr_screen.max_h == base_res[1]) ||
                        (gr_screen.max_w == base_res[0] && gr_screen.max_h >= base_res[1])) {
                base_res[0] = gr_screen.max_w;
                base_res[1] = gr_screen.max_h;
@@ -1093,6 +1094,7 @@ T* gauge_load_common(int base_w, int base_h, int hud_font, SCP_vector<int>* ship
        int font_num = FONT1;
        int colors[3] = {255, 255, 255};
        bool lock_color = false;
+       bool scale_gauge = true;
 
        // render to texture parameters
        char display_name[MAX_FILENAME_LEN] = "";
@@ -1116,7 +1118,11 @@ T* gauge_load_common(int base_w, int base_h, int hud_font, SCP_vector<int>* ship
                        if(optional_string("Position:")) {
                                stuff_int_list(coords, 2);
                        } else {
-                               adjust_base_res(base_res);
+                               if(optional_string("Scale Gauge:")) {
+                                       stuff_boolean(&scale_gauge);;
+                               }
+
+                               adjust_base_res(base_res, scale_gauge);
 
                                // If no positioning information is specified, use the default position
                                bool use_default_pos = true;
@@ -1131,6 +1137,7 @@ T* gauge_load_common(int base_w, int base_h, int hud_font, SCP_vector<int>* ship
                                        use_default_pos = false;
                                }
 
+
                                if ( !(default_position && use_default_pos) ) {
                                        coords[0] = (int)(base_res[0] * origin[0]) + offset[0];
                                        coords[1] = (int)(base_res[1] * origin[1]) + offset[1];

But this isn't finished yet, I want to have a "global" hud gauge tbl option to disable scaling as well but that'll require a whole heap of other trivial changes to make work. And I want to test it with (& screenshot for feedback) every oddball resolution I can come up with and have enough screen real estate to look at.  Hopefully I'll get both done in the next few weeks, after the Christmas craziness settles down.

And of course, I can't see any reason why we can't have the Yarn/z64555 clustering idea as well as the other two options available (i.e. original position, origin+offset+optional-scaling, clusters)
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 z64555

  • 210
  • Self-proclaimed controls expert
    • Minecraft
    • Steam
Re: [CODE REVIEW] Adaptable HUD, a.k.a. No more HUD stretching, for real this time
I have an idea. We could use z64555's idea of gauge clusters, but have it take only two parameters: "Name" and "Position". "Name" is self-explanitory, while "Position" has the same format and effect as Origin currently does. There would be nine default clusters: Top Left (0.0, 0.0), Top Center (0.5, 0.0), Top Right (1.0, 0.0), Center Left (0.0, 0.5), Center (0.5, 0.5), Center Right (1.0, 0.5), Bottom Left (0.0, 1.0), Bottom Center (0.5, 1.0), and Bottom Right (1.0, 1.0). More can be created in hud_gauges.tbl.

Sounds good to me.  :nod:

What would be the downside to referencing the Cluster Position as a screen percentage, like with Origin and the others? Upon initialization, the HUD code could calculate the actual position in pixels by back-referencing the Base Resolution and translate it appropriately. This might make it easier for the modder to understand, as well as (possibly) allow the modder to choose a different base resolution.
Secure the Source, Contain the Code, Protect the Project
chief1983

------------
funtapaz: Hunchon University biologists prove mankind is evolving to new, higher form of life, known as Homopithecus Juche.
z64555: s/J/Do
BotenAlfred: <funtapaz> Hunchon University biologists prove mankind is evolving to new, higher form of life, known as Homopithecus Douche.

 

Offline Yarn

  • 210
Re: [CODE REVIEW] Adaptable HUD, a.k.a. No more HUD stretching, for real this time
But this isn't finished yet, I want to have a "global" hud gauge tbl option to disable scaling as well but that'll require a whole heap of other trivial changes to make work. And I want to test it with (& screenshot for feedback) every oddball resolution I can come up with and have enough screen real estate to look at.  Hopefully I'll get both done in the next few weeks, after the Christmas craziness settles down.
Is the global setting intended for HUD designers or users? Because if it's for users, then it really should be a command-line switch. Yes, I know that the command-line is already crowded, but still--user options don't belong in a table.

What would be the downside to referencing the Cluster Position as a screen percentage, like with Origin and the others? Upon initialization, the HUD code could calculate the actual position in pixels by back-referencing the Base Resolution and translate it appropriately. This might make it easier for the modder to understand, as well as (possibly) allow the modder to choose a different base resolution.
I don't understand what you mean here. Can you elaborate?
"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 niffiwan

  • 211
  • Eluder Class
Re: [CODE REVIEW] Adaptable HUD, a.k.a. No more HUD stretching, for real this time
But this isn't finished yet, I want to have a "global" hud gauge tbl option to disable scaling as well but that'll require a whole heap of other trivial changes to make work. And I want to test it with (& screenshot for feedback) every oddball resolution I can come up with and have enough screen real estate to look at.  Hopefully I'll get both done in the next few weeks, after the Christmas craziness settles down.
Is the global setting intended for HUD designers or users? Because if it's for users, then it really should be a command-line switch. Yes, I know that the command-line is already crowded, but still--user options don't belong in a table.

For HUD designers, I agree that putting a user-configurable option in the tables is a really bad idea.
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 niffiwan

  • 211
  • Eluder Class
Re: [CODE REVIEW] Adaptable HUD, a.k.a. No more HUD stretching, for real this time
FYI - here's some pics; the idea is to show how the various gauge positioning schemes work:

For reference:
  • Here is the hud_gauges.tbl
  • The base resolution in all screens is 1440x900
  • Top left uses Origin: & Offset:
  • Lower left uses Origin:
  • Top right uses Position:
  • Lower right uses Origin: & Offset: & "No Scaling"
  • Default radar only has "No Scaling:
  • Note that overlapping grids and spacing between grids of a cluster indicate alignment issues
  • The complete mod used for testing

I think in an ideal world we'd have SVG support for gauges rather than no-scaling gauges, but that's probably not going to be implemented any time soon. In the meantime, if using Origin+Offset then the designer needs to make a tradeoff between "pixel perfect" gauges that may be too small to read on large resolutions, vs slightly blurry gauges which scale & retain their original aspect ratio.  Of course, there's nothing (except the extra effort required) stopping a designer using resolution filters with no-scaling, and multiple sets of images to ensure that gauges remain readable at large resolutions.

1440x900 (base 16:10)


1024x768 (4:3 down-scaled & changed aspect)
OLD VERSION

1280x1024 (5:4 up & down-scaled & changed aspect)
OLD VERSION

1600x900 (16:9 up-scaled & changed aspect)


1680x1050 (16:10 up-scaled)


1680x480 (pseudo triple head, see Yarns comment about how Min/Max res table config currently works)
OLD VERSION

3200x960 (another pseudo triple head)
« Last Edit: December 30, 2013, 04:37:35 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 Yarn

  • 210
Re: [CODE REVIEW] Adaptable HUD, a.k.a. No more HUD stretching, for real this time
You should add that overlapping grids and spacing between grids of a cluster indicate alignment issues. (This is why it's a very bad idea to use Origin alone for positioning.)

It's a good idea to force scaling if any dimension of the HUD's base resolution is greater than those of the screen resolution. To accomplish this, here's what the condition of that if statement should look like:
Code: [Select]
if ((!scaling && gr_screen.max_w >= base_res[0] && gr_screen.max_h >= base_res[1]) ||
(gr_screen.max_w >= base_res[0] && gr_screen.max_h == base_res[1]) ||
(gr_screen.max_w == base_res[0] && gr_screen.max_h >= base_res[1])) {

note that the Min res must be met in both directions for this table config to be excluded
Actually, it works like this: The screen width must equal or exceed the HUD width. If and only if the two widths are equal, the screen height must also equal or exceed the HUD height. Max works in a similar fashion. There doesn't seem to be a reason why it should behave this way, and it's different from the way the built-in HUD works, so I made a patch to fix it; it's the third one in this post. (I suggest looking at the other two as well.)
"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 niffiwan

  • 211
  • Eluder Class
Re: [CODE REVIEW] Adaptable HUD, a.k.a. No more HUD stretching, for real this time
You should add that overlapping grids and spacing between grids of a cluster indicate alignment issues. (This is why it's a very bad idea to use Origin alone for positioning.)

Done

It's a good idea to force scaling if any dimension of the HUD's base resolution is greater than those of the screen resolution. To accomplish this, here's what the condition of that if statement should look like:
Code: [Select]
if ((!scaling && gr_screen.max_w >= base_res[0] && gr_screen.max_h >= base_res[1]) ||
(gr_screen.max_w >= base_res[0] && gr_screen.max_h == base_res[1]) ||
(gr_screen.max_w == base_res[0] && gr_screen.max_h >= base_res[1])) {
Thanks - and added to the patch.

note that the Min res must be met in both directions for this table config to be excluded
Actually, it works like this: The screen width must equal or exceed the HUD width. If and only if the two widths are equal, the screen height must also equal or exceed the HUD height. Max works in a similar fashion. There doesn't seem to be a reason why it should behave this way, and it's different from the way the built-in HUD works, so I made a patch to fix it; it's the third one in this post. (I suggest looking at the other two as well.)

Thanks, I'd forgotten about those patches. I'll have a closer look once I've finished testing this one.  Speaking of which, I've added global and per-#Gauge Config: scaling options, I just need to run some tests & take more screenshots to ensure it's all working correctly.
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...