[Yarn]

All right, the patch should be done. I'm also providing some builds so that non-coders can test it.

Patch: https://dl.dropboxusercontent.com/u/89353583/FreeSpace/Patches/HUDScaleLimit.patch
GitHub branch: https://github.com/Yarn366/fs2open.github.com/tree/hud_scale_limit
Windows builds: https://dl.dropboxusercontent.com/u/89353583/FreeSpace/Patches/HUDScaleLimit_build.zip

To try this out, create a file called "mv_root-hdg.tbm" in MediaVPs_2014\data\tables (create the folders if they don't exist) and add the following text to the file:

Code: [Select]

;General Shenanigans

$Max Directives: 8
$Max Escort Ships: 13
$Scale Gauges: no
$Force Scaling Above: (1200, 900)

Feel free to change the resolution in $Force Scaling Above to suit your taste. Do report what value seems to work best for you; this information can help the FSU team decide what value to use in the next MediaVP version, assuming this patch gets committed.

(I play on a 20" monitor at 1600x900 resolution; the gauges look big enough for me unscaled.)

[BirdofPrey]

Scale gauges should be a command line flag to be honest.  Less required table shenanigans.
Also might be better to have scaling take an integer rather than a boolean, so we can actually set the size.

The size to start scaling at seems to be fine from a cursory glance, though.

[Yarn]

Also might be better to have scaling take an integer rather than a boolean, so we can actually set the size.

Can you provide an example of how this would in a HUD table, as well as what exactly it would do?

[BirdofPrey]

Have a number that represents a percentage to scale the HUD up to.  0 is the same as scaling off, 100% (not sure if 100 as an integer or 1.00 as a floating point would be preferable) would double the size of the HUD and you could go over 100%, so you can choose a scaling factor that best fits on the screen.

You could also give us some example values of what scaling factor would be equivalent to scaling on at various reference resolutions, that we can modify from there.  Again, though, I think scaling should be a command-line flag anyways rather than having it chosen for us by the HLP team and having to edit tables to fix it.

THe problem with current scaling is on larger monitors, scaling off makes the HUD so small it may become hard to read, but with scaling on, it's too big, more or less, since you don't need it to take up ALL the screen space.

[Yarn]

Have a number that represents a percentage to scale the HUD up to.  0 is the same as scaling off, 100% (not sure if 100 as an integer or 1.00 as a floating point would be preferable) would double the size of the HUD and you could go over 100%, so you can choose a scaling factor that best fits on the screen.

This isn't much different from just turning off scaling, using larger font and image files for the gauges, and adjusting the positions. And it still doesn't solve the problem of the HUD getting tiny at very high resolutions; rather, it only "delays the inevitable," so to speak. (When thinking of a way to fix this particular problem, just think of the guy running FSO at 11520x6480; would he have much trouble seeing the HUD with your proposal in use?)

THe problem with current scaling is on larger monitors, scaling off makes the HUD so small it may become hard to read, but with scaling on, it's too big, more or less, since you don't need it to take up ALL the screen space.

And my patch should solve this problem provided that the $Force Scaling Above parameter is utilized wherever it's appropriate.

[BirdofPrey]

Have a number that represents a percentage to scale the HUD up to.  0 is the same as scaling off, 100% (not sure if 100 as an integer or 1.00 as a floating point would be preferable) would double the size of the HUD and you could go over 100%, so you can choose a scaling factor that best fits on the screen.

This isn't much different from just turning off scaling, using larger font and image files for the gauges, and adjusting the positions. And it still doesn't solve the problem of the HUD getting tiny at very high resolutions; rather, it only "delays the inevitable," so to speak. (When thinking of a way to fix this particular problem, just think of the guy running FSO at 11520x6480; would he have much trouble seeing the HUD with your proposal in use?)

How does it not solve the problem of the HUD becoming too tiny at very high resolutions?  You have more resolution, you can choose a higher scaling factor.  Also take into consideration screen space.  if you have a >30" monitor you don't really need and maybe don't even want single HUD elements taking up a fourth of the screen space.  I don't think your solution does anything better, if you are forcing HUD scaling on at common resolutions anyways why even have the default scaling off?  The reason this problem cropped up in the first place was having scaling turned off by default for some reason.  Wouldn't it be better to have it on by default and force scaling off below a certain resolution?

A scaling factor lets players scale based on their monitor regardless of the size.  If you are running 10k resolution or something equally absurd you can easily set the scaling factor to 500% and have it readable which DOES fix the problem of it being tiny at high resolutions since you can set it to not be tiny.

I should also note that by that point we'd have to redo the HUD graphics ANYWAYS (should really go to .svg) since trying to scale the current ones to such a high resolution will cause scaling artifacts.

THe problem with current scaling is on larger monitors, scaling off makes the HUD so small it may become hard to read, but with scaling on, it's too big, more or less, since you don't need it to take up ALL the screen space.

And my patch should solve this problem provided that the $Force Scaling Above parameter is utilized wherever it's appropriate.

No you don't understand, a binary option sucks.  Some of us not only have large resolutions, but also large monitors.  Scaling off is too small, scaling on is too big (or rather, bigger than necessary).  Forcing scaling on or off at a certain resolution doesn't solve this problem since it lacks granularity.

and again, forcing scaling on or off shouldn't be a table option anyways.  The Table option should be the default scaling and we should have a command line flag so we can actually choose how we want the HUD scaled.

[Yarn]

Before I continue, I should clear something up: FSO does in fact scale gauges by default; if you play without mods or MediaVPs, that's exactly what happens. However, the FSU guys (who are responsible for the MediaVPs) believed for some reason that scaling should be disabled completely, so that's how the 2014 MediaVPs were configured. Unfortunately, that has the effect of making the HUD too small for various configurations, which is what this thread is all about.

How does it not solve the problem of the HUD becoming too tiny at very high resolutions?  You have more resolution, you can choose a higher scaling factor.  Also take into consideration screen space.  if you have a >30" monitor you don't really need and maybe don't even want single HUD elements taking up a fourth of the screen space.

What's wrong with your proposal? It requires users with high-resolution monitors to edit a table to make the HUD big enough, which is something that we want to avoid. (As I said earlier in this thread, tables are not for user settings.) And yes, I completely understand that a huge monitor makes the HUD huge if scaling is fully enabled, but then again, it makes just about everything (except for the desktop) huge.

I don't think your solution does anything better, if you are forcing HUD scaling on at common resolutions anyways why even have the default scaling off?

My patch is more sophisticated than that: It disables scaling up until a given resolution (the one specified in $Force Scaling Above), and above that it scales the gauges enough so that they appear to be as large as they would be if the screen resolution were the same as that given resolution (again, the one specified in $Force Scaling Above). In the latter case, it does not scale gauges fully; it only does so partially.

Please actually try out my build with a variety of resolutions before further criticizing my proposal.

Wouldn't it be better to have it on by default and force scaling off below a certain resolution?

That's effectively what my patch does.

I should also note that by that point we'd have to redo the HUD graphics ANYWAYS (should really go to .svg) since trying to scale the current ones to such a high resolution will cause scaling artifacts.

Agreed, though that requires SVG support to be implemented.

No you don't understand, a binary option sucks.  Some of us not only have large resolutions, but also large monitors.  Scaling off is too small, scaling on is too big (or rather, bigger than necessary).  Forcing scaling on or off at a certain resolution doesn't solve this problem since it lacks granularity.

Actually, I do understand that a binary option sucks in this case. That's why I'm trying to reach a middleground, and my patch does this by allowing modders (that includes the MediaVP authors) to specify a resolution at which scaling starts to occur, and even then it's not full scaling.

I acknowledge that my implementation might not be the most intuitive possible. Perhaps this would be better:

Code: [Select]

;General Shenanigans

$Max Directives: 8
$Max Escort Ships: 13
$Scale Gauges Above: (1200, 900)
If the screen resolution is greater than the one in $Scale Gauges Above, then gauges are scaled (and again, only partially). If it's lower, then gauges are not scaled. $Scale Gauges would not need to be set, and in fact both $Scale Gauges and $Scale Gauges Above would be able to override each other.

[niffiwan]

I should also note that by that point we'd have to redo the HUD graphics ANYWAYS (should really go to .svg) since trying to scale the current ones to such a high resolution will cause scaling artifacts.

Agreed, though that requires SVG support to be implemented.

I'm interested in this and have done some investigation. It seems that there's no pre-existing, well documented, and small library (i.e. with minimal flow on dependencies) that can take .svg's and convert them to image data in memory.  There's are libs that are either huge, or will convert to a image file on disk, or render the .svg to screen (which is bloody useless for FSO because rendering .svg's is *slow*.  It doesn't matter for a web-browser if it takes 50 ms to render, but I can assure you that a 48 gauges x 50ms is an unacceptable delay to FSO framerates ).  I was hoping that m!m's Chromium browser in FSO would be able to do this without any addition deps, but it seems that the toolkit used doesn't expose the granular functionality required.

Anyway, is looks like I'd need to implement something that'll draw .svg primitives into memory rather than direct to screen or file, and it not being semi-trivial means that it'll probably take a while to implement.

(I say this so that some wizard can come along and prove me utterly wrong in a week or so!! My pride will welcome the humiliation as long as it means we get .svg support )

[BirdofPrey]

Before I continue, I should clear something up: FSO does in fact scale gauges by default; if you play without mods or MediaVPs, that's exactly what happens. However, the FSU guys (who are responsible for the MediaVPs) believed for some reason that scaling should be disabled completely, so that's how the 2014 MediaVPs were configured. Unfortunately, that has the effect of making the HUD too small for various configurations, which is what this thread is all about.

I say it defaults to off, since the table that ships with the MVPs sets it to off, thus it's the default option for playing FSO with the MVPs without editing table files.

What's wrong with your proposal? It requires users with high-resolution monitors to edit a table to make the HUD big enough, which is something that we want to avoid. (As I said earlier in this thread, tables are not for user settings.) And yes, I completely understand that a huge monitor makes the HUD huge if scaling is fully enabled, but then again, it makes just about everything (except for the desktop) huge.

You missed the part where I am also saying HUD scaling should be a command line option (which IS for user settings) rather than a table option

As for making stuff bigger and smaller, it is true to SOME extent that larger screens mean larger image elements, but the GUI has access to the DPI of your monitor and, so can be set to scale accordingly.  I'm told the game engine does not have access to this detail, which is why things are a pain in the ass (if it did have access to that information, it could be set to render HUD elements to an actual ruler size)

I don't think your solution does anything better, if you are forcing HUD scaling on at common resolutions anyways why even have the default scaling off?

My patch is more sophisticated than that: It disables scaling up until a given resolution (the one specified in $Force Scaling Above), and above that it scales the gauges enough so that they appear to be as large as they would be if the screen resolution were the same as that given resolution (again, the one specified in $Force Scaling Above). In the latter case, it does not scale gauges fully; it only does so partially.

Please actually try out my build with a variety of resolutions before further criticizing my proposal.

I know what the HUD looks like at different resolutions on my monitor.  I can't actually change the size of my monitor, though, and that may actually be the more pertinent value anyways.  Your proposal works just fine, I just think we need more granularity than just on or off.

Wouldn't it be better to have it on by default and force scaling off below a certain resolution?

That's effectively what my patch does.

It does the same thing effectively, but the method of achieving it is the opposite (turning something on vs turning something off)

No you don't understand, a binary option sucks.  Some of us not only have large resolutions, but also large monitors.  Scaling off is too small, scaling on is too big (or rather, bigger than necessary).  Forcing scaling on or off at a certain resolution doesn't solve this problem since it lacks granularity.

Actually, I do understand that a binary option sucks in this case. That's why I'm trying to reach a middleground, and my patch does this by allowing modders (that includes the MediaVP authors) to specify a resolution at which scaling starts to occur, and even then it's not full scaling.

My argument is that it is still binary since the options are only on and off, even if which state it's in is dependent on resolution.

I acknowledge that my implementation might not be the most intuitive possible. Perhaps this would be better:

It's plenty intuitive to me at least.  I just think, if someone is going to change the scaling, they should actually change scaling.
The simple solution really is to just remove the flag that turns off gauge scaling in the HUD table since gauges being scaled causes less problems than not scaling gauges. (too large is at least usable even if sub-optimal)

I should also note that by that point we'd have to redo the HUD graphics ANYWAYS (should really go to .svg) since trying to scale the current ones to such a high resolution will cause scaling artifacts.

Agreed, though that requires SVG support to be implemented.

I'm interested in this and have done some investigation. It seems that there's no pre-existing, well documented, and small library (i.e. with minimal flow on dependencies) that can take .svg's and convert them to image data in memory.  There's are libs that are either huge, or will convert to a image file on disk, or render the .svg to screen (which is bloody useless for FSO because rendering .svg's is *slow*.  It doesn't matter for a web-browser if it takes 50 ms to render, but I can assure you that a 48 gauges x 50ms is an unacceptable delay to FSO framerates ).  I was hoping that m!m's Chromium browser in FSO would be able to do this without any addition deps, but it seems that the toolkit used doesn't expose the granular functionality required.

Anyway, is looks like I'd need to implement something that'll draw .svg primitives into memory rather than direct to screen or file, and it not being semi-trivial means that it'll probably take a while to implement.

(I say this so that some wizard can come along and prove me utterly wrong in a week or so!! My pride will welcome the humiliation as long as it means we get .svg support )

Well crap.  Are there any other methods we can use to create vector graphics for UI elements?
I'd actually appreciate the ability to use vector graphics for the radar stuff I've been working on, vector graphics scale and render much more cleanly than raster graphics once you go more than a little bit up or down in scale. (finding the right size to make the icons in to start was annoying enough, but I've spent most of the creation time trying to find a good balance between sharpness and proper anti-aliasing.  Maybe I'm just not doing it right, but vector graphics would be a huge boon here nevertheless.)

[Yarn]

You missed the part where I am also saying HUD scaling should be a command line option (which IS for user settings) rather than a table option

I didn't miss it; I just neglected to respond to it. Anyway, when I originally made the Adaptable HUD (which usually prevents the HUD from distorting), I actually did add a command-line parameter that did exactly what you're talking about. I later removed it because Swifty disliked it. You can read the discussion on that here.

I know what the HUD looks like at different resolutions on my monitor.  I can't actually change the size of my monitor, though, and that may actually be the more pertinent value anyways.  Your proposal works just fine, I just think we need more granularity than just on or off.

I'm pretty sure that my patch already provides that granularity. If the screen resolution is greater than $Force Scaling Above, then the game does not simply pretend that $Scale Gauges is enabled (which is what you seem to think); rather, it scales the gauge just enough so that the gauge appears to be as big as (but not bigger than) it would appear if the screen resolution matched $Force Scaling Above and scaling was off, assuming the monitor's size doesn't change.

Or are you asking for something like "scale 60% (or whatever) of the way between no scaling ($Scale Gauges: no) and full scaling ($Scale Gauges: yes)"?

The simple solution really is to just remove the flag that turns off gauge scaling in the HUD table since gauges being scaled causes less problems than not scaling gauges. (too large is at least usable even if sub-optimal)

I'm almost certain that this isn't going to happen, considering that there are already mods (the 2014 MediaVPs at the very least) that use this feature.

[BirdofPrey]

I didn't miss it; I just neglected to respond to it. Anyway, when I originally made the Adaptable HUD (which usually prevents the HUD from distorting), I actually did add a command-line parameter that did exactly what you're talking about. I later removed it because Swifty disliked it. You can read the discussion on that here.

  I may need to reread the entire thread, but my understanding from what I read was the problem with a commandline flag was with mods that have custom HUDs.  Creators put a bit of work into making bespoke HUDs and a commandline option that mucks with that could be bad, but they also put time into the table, and I tend to see HUD tables for custom HUDs in mods with entries for several different resolutions, so the flag wouldn't be needed anyways.

Unfortunately, scaling is an issue with the MVPs since the HUD is baked into the game engine and the HUD table is only a few lines.  If the HUD table was actually a proper table with entries for a variety of resolutions in various sizes and aspect rations, we might not even need the ability to set our own scaling.

I can agree with the sentiment that less command-line flags would be good, but the in game options haven't been adapted to the changes the team has made to FSO.

The issue here is with the stock FS HUD.  It's outdated, which is why the option to set scaling is needed, and as has been pointed out a few times, user settings which scaling would be don't belong in tables.

Or are you asking for something like "scale 60% (or whatever) of the way between no scaling ($Scale Gauges: no) and full scaling ($Scale Gauges: yes)"?

That's exactly what I am asking for.

The simple solution really is to just remove the flag that turns off gauge scaling in the HUD table since gauges being scaled causes less problems than not scaling gauges. (too large is at least usable even if sub-optimal)

I'm almost certain that this isn't going to happen, considering that there are already mods (the 2014 MediaVPs at the very least) that use this feature.
[/quote]I meant removing the flag from the MVPs table, not removing the actual flag option from the engine.

[Yarn]

...and I tend to see HUD tables for custom HUDs in mods with entries for several different resolutions, so the flag wouldn't be needed anyways.

That's probably because of how the HUD system was before my Adaptable HUD was committed in December 2013--gauges had to be positioned using absolute coordinates to a fixed base resolution, and then the HUD would scale and stretch to fill the screen. To ensure that the HUD looked good at multiple resolutions and aspect ratios, multiple HUD configurations were typically used: usually one for full screen and another for widescreen, but sometimes also several more for multiple resolutions because scaling couldn't just be disabled.

My patch (the Adaptable HUD, not the patch in this thread) should have mostly eliminated the need for that, but because 1) older mods aren't always updated to take advantage of new features, and 2) it's possible that some modders either prefer using the old system or are unaware of the new one, you may continue to see HUD tables like that.

(Also remember that the game supports HUD configurations that are specific to certain ships. Mods that utilize that feature will generally have more than a few HUD configurations.)

If the HUD table was actually a proper table with entries for a variety of resolutions in various sizes and aspect rations, we might not even need the ability to set our own scaling.

And the need for multiple HUDs like that is exactly what I've been trying to eliminate. The Adaptable HUD eliminated the need to have separate full screen and widescreen HUDs for the sake of minimizing stretching, the patch in this thread (which isn't committed or even finished yet) makes it unnecessary for players with multimonitor setups to use special tables, and in this thread we're thinking of ways of allowing a HUD's gauges to shrink somewhat without becoming too tiny to be usable.

Or are you asking for something like "scale 60% (or whatever) of the way between no scaling ($Scale Gauges: no) and full scaling ($Scale Gauges: yes)"?

That's exactly what I am asking for.

OK, but remember that players generally like having crisp-looking (in FSO's case, that means unscaled) HUDs as long as the HUD is still big enough to be readable--that's one of the biggest reasons that the option to disable scaling was implemented in the first place. The scaling method that you want does absolutely nothing to achieve that because it still scales gauges in all cases where "$Scale Gauges: yes" would. My patch does satisfy this (if only partially) by disabling scaling to a point, beyond which some scaling is applied to prevent the HUD from getting too tiny.

I'm almost certain that this isn't going to happen, considering that there are already mods (the 2014 MediaVPs at the very least) that use this feature.

I meant removing the flag from the MVPs table, not removing the actual flag option from the engine.

Oh. Yeah, the FSU team might replace that line if something better gets committed, be it my patch or something else.

[Yarn]

I finished converting my patch to a GitHub branch. The link is in this post. The builds have also been updated.

If no objections or concerns are raised, I will submit a pull request.

EDIT: I've submitted a PR; you can find it here: https://github.com/scp-fs2open/fs2open.github.com/pull/500