Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: SharpHawk on February 23, 2015, 02:05:03 am
-
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 (http://www.hard-light.net/forums/index.php?topic=87656.msg1750829#msg1750829), 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?
-
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?
-
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)
$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)
-
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.
-
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!)
-
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).
-
.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.
-
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.
-
.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
-
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)
-
Bummer
-
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:
$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.
-
$Scale Gauges: no
$Force Scaling Above: (1200, 900)
[...]
If this sounds good, I can look into coding it.
I like it. :yes:
-
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)
-
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.
-
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.
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.
;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.
-
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.
;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.
-
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
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.
;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.
-
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 (https://www.apple.com/macbook-pro/features-retina/), 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.
-
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.
-
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 (https://dl.dropboxusercontent.com/u/89353583/FreeSpace/Patches/HUDScaleLimit.patch)
GitHub branch: https://github.com/Yarn366/fs2open.github.com/tree/hud_scale_limit (https://github.com/Yarn366/fs2open.github.com/tree/hud_scale_limit)
Windows builds: https://dl.dropboxusercontent.com/u/89353583/FreeSpace/Patches/HUDScaleLimit_build.zip (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:
;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.)
-
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.
-
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?
-
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.
-
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.
-
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.
-
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 (http://www.hard-light.net/forums/index.php?topic=89233.msg1780514#msg1780514) 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:
;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.
-
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 :p). 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 :D)
-
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 (http://www.hard-light.net/forums/index.php?topic=89233.msg1780514#msg1780514) 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 :p). 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 :D)
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.)
-
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 (http://www.hard-light.net/forums/index.php?topic=84340.0) (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 (http://www.hard-light.net/forums/index.php?topic=84340.msg1686217#msg1686217).
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.
-
I didn't miss it; I just neglected to respond to it. Anyway, when I originally made the Adaptable HUD (http://www.hard-light.net/forums/index.php?topic=84340.0) (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 (http://www.hard-light.net/forums/index.php?topic=84340.msg1686217#msg1686217).
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.
-
...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 (http://www.hard-light.net/forums/index.php?topic=89262.0) (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.
-
I finished converting my patch to a GitHub branch. The link is in this post (http://www.hard-light.net/forums/index.php?topic=89233.msg1780514#msg1780514). 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 (https://github.com/scp-fs2open/fs2open.github.com/pull/500)