Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Yarn on April 12, 2013, 11:07:21 pm
-
This patch has been committed, so just get the latest nightly build (http://www.hard-light.net/forums/index.php?board=173.0) if you want try this feature yourself.
I managed to make HUD code that adapts the HUD to any resolution and aspect ratio correctly, without stretching. And it didn't require an overhaul.
Essentially, this code properly positions and scales HUD elements to suit the player's screen resolution and aspect ratio, whatever they happen to be, without the need for a custom HUD table. (And don't worry; existing custom HUDs should still work properly, but they won't fully benefit from my changes. It's possible to make a custom HUD that does, though.)
Here is the patch and some Windows builds. Be sure to try out various resolutions and aspect ratios, including unusual ones. (And make sure you aren't loading a custom HUD layout, or else none of these changes will take effect!)
All files here are currently based on revision 10174 (November 27, 2013).
Patch (https://dl.dropboxusercontent.com/u/89353583/FreeSpace/Adaptable_HUD.patch) (The contents of the patch don't fit in one post, unfortunately.)
Windows build
Windows Blue Planet build
Now for the documentation.
The primary change is the addition of Origin: and Offset: to most gauges in hud_gauges.tbl. As an example, here is what the entry for the default afterburner gauge looks like with these new parameters:
+Afterburner Energy:
Origin: (0.5, 0.5)
Offset: (-238, 40)
The Origin: parameter, which takes two floating-point values between 0 and 1, specifies the resolution-independent point of the screen that the gauge should be positioned in relation to. For example, (0.0, 0.0) is the top-left, (0.5, 0.5) (used in the example above) is the center, and (1.0, 1.0) is the bottom-right. Any values from 0 to 1 may be used here, so an origin of, say, (0.316, 0.61) is valid.
The Offset: parameter takes two integers and specifies in pixels where the top-left pixel of the gauge should be positioned in relation to the specified origin. The example above uses (-238, 40) as its offset, which indicates that the gauge should be positioned 238 pixels to the right of and 40 pixels below the specified origin (which is (0.5, 0.5) in this case). Note that this parameter uses the adjusted base resolution (discussed below), not the screen resolution, to determine positioning.
For compatibility reasons (and HUD designers who do not wish to use the new system), the Position: parameter is still present and works the same as before. Any gauge using this parameter will not benefit from my patch and will thus potentially stretch.
Another change is the way the HUD's base resolution works for gauges that don't use the Position: parameter. For such gauges, if the HUD resolution's aspect ratio is not the same as the screen resolution's aspect ratio, one of the HUD resolution's dimensions (width or height) will be enlarged so that both ratios match. So, for example, if the HUD resolution is 1024x768 (4:3) and the screen resolution is 1440x900 (16:10), the HUD resolution will be expanded to 1228x768 (approximately 16:10). This is done before determining where to actually place the gauge.
This patch completely adapts the internal HUD to this system, so a hud_gauges.tbl or *-hdg.tbm is no longer needed to prevent the retail HUD from stretching.
I hope this description is clear enough. If you have any questions or comments about this patch, post them here.
And now, here are tabled versions of the built-in HUD. These are for reference and modding purposes only and should not be included with the MediaVPs.
FreeSpace 2:
#Gauge Config
$Base: (1024, 768)
$Min: (1024, 600)
$Gauges:
+Messages:
Origin: (0.0, 0.0)
Offset: (8, 5)
+Training Messages:
Origin: (0.5, 0.5)
Offset: (-133, -259)
+Support:
Origin: (0.5, 0.5)
Offset: (-53, 150)
+Damage:
Origin: (0.5, 0.0)
Offset: (-72, 61)
+Wingman Status:
Origin: (1.0, 0.0)
Offset: (-92, 144)
+Auto Speed:
Origin: (1.0, 1.0)
Offset: (-64, -96)
+Auto Target:
Origin: (1.0, 1.0)
Offset: (-64, -120)
+Countermeasures:
Origin: (1.0, 1.0)
Offset: (-144, -166)
+Talking Head:
Origin: (0.0, 0.0)
Offset: (5, 56)
+Directives:
Origin: (0.0, 0.5)
Offset: (5, -106)
+Weapons:
Origin: (1.0, 1.0)
Offset: (-144, -257)
+Objective Notify:
Origin: (0.5, 0.5)
Offset: (-76, -200)
+Squad Message:
Origin: (1.0, 0.0)
Offset: (-197, 5)
+Lag:
Origin: (0.5, 0.5)
Offset: (115, 145)
+Mini Target Shields:
Origin: (0.5, 0.5)
Offset: (-15, 86)
+Player Shields:
Origin: (0.5, 1.0)
Offset: (112, -98)
+Target Shields:
Origin: (0.5, 1.0)
Offset: (-220, -98)
+Escort View:
Origin: (1.0, 0.5)
Offset: (-159, -54)
+Mission Time:
Origin: (1.0, 1.0)
Offset: (-55, -52)
+Target Monitor:
Origin: (0.0, 1.0)
Offset: (5, -178)
+Extra Target Data:
Origin: (0.0, 1.0)
Offset: (5, -216)
+Radar:
Origin: (0.5, 1.0)
Offset: (-101, -178)
+Afterburner Energy:
Origin: (0.5, 0.5)
Offset: (-238, 40)
+Weapon Energy:
Origin: (0.5, 0.5)
Offset: (154, 40)
+Text Warnings:
Origin: (0.5, 0.5)
Offset: (0, -109)
+Center Reticle:
Origin: (0.5, 0.5)
Offset: (-19, -14)
+Throttle:
Origin: (0.5, 0.5)
Offset: (-166, -115)
+Threat Indicator:
Origin: (0.5, 0.5)
Offset: (62, -115)
+Lead Indicator:
+Lock Indicator:
+Multiplayer Messages:
Origin: (0.0, 0.5)
Offset: (8, -144)
+Voice Status:
Origin: (0.0, 0.5)
Offset: (8, -129)
+Ping:
Origin: (1.0, 0.0)
Offset: (-128, 5)
+Supernova:
Origin: (0.5, 0.5)
Offset: (-342, -214)
+Offscreen Indicator:
+Target Brackets:
+Orientation Tee:
Origin: (0.5, 0.5)
Offset: (0, 3)
+Hostile Triangle:
Origin: (0.5, 0.5)
Offset: (0, 3)
+Target Triangle:
Origin: (0.5, 0.5)
Offset: (0, 3)
+Missile Triangles:
Origin: (0.5, 0.5)
Offset: (0, 3)
+Kills:
Origin: (1.0, 1.0)
Offset: (-144, -144)
+Fixed Messages:
+ETS Retail:
Origin: (1.0, 1.0)
Offset: (-144, -120)
$End Gauges
#End
FreeSpace Port:
$Reticle Style: FS1
#Gauge Config
$Base: (1024, 768)
$Min: (1024, 600)
$Gauges:
+Messages:
Origin: (0.0, 0.0)
Offset: (8, 5)
+Training Messages:
Origin: (0.5, 0.5)
Offset: (-133, -259)
+Support:
Origin: (0.5, 0.5)
Offset: (-53, 150)
+Damage:
Origin: (0.5, 0.0)
Offset: (-72, 61)
+Wingman Status:
Origin: (1.0, 0.0)
Offset: (-92, 144)
+Auto Speed:
Origin: (1.0, 1.0)
Offset: (-64, -96)
+Auto Target:
Origin: (1.0, 1.0)
Offset: (-64, -120)
+Countermeasures:
Origin: (1.0, 1.0)
Offset: (-144, -166)
+Talking Head:
Origin: (0.0, 0.0)
Offset: (5, 56)
+Directives:
Origin: (0.0, 0.5)
Offset: (5, -106)
+Weapons:
Origin: (1.0, 1.0)
Offset: (-144, -257)
+Objective Notify:
Origin: (0.5, 0.5)
Offset: (-76, -200)
+Squad Message:
Origin: (1.0, 0.0)
Offset: (-197, 5)
+Lag:
Origin: (0.5, 0.5)
Offset: (115, 145)
+Mini Target Shields:
Origin: (0.5, 0.5)
Offset: (-15, 86)
+Player Shields:
Origin: (0.5, 1.0)
Offset: (112, -98)
+Target Shields:
Origin: (0.5, 1.0)
Offset: (-220, -98)
+Escort View:
Origin: (1.0, 0.5)
Offset: (-159, -54)
+Mission Time:
Origin: (1.0, 1.0)
Offset: (-55, -52)
+Target Monitor:
Origin: (0.0, 1.0)
Offset: (5, -178)
+Extra Target Data:
Origin: (0.0, 1.0)
Offset: (5, -216)
+Radar:
Origin: (0.5, 1.0)
Offset: (-101, -178)
+Afterburner Energy:
Origin: (0.5, 0.5)
Offset: (-238, 40)
+Weapon Energy:
Origin: (0.5, 0.5)
Offset: (154, 40)
+Text Warnings:
Origin: (0.5, 0.5)
Offset: (0, -109)
+Center Reticle:
Origin: (0.5, 0.5)
Offset: (-19, -8)
+Throttle:
Origin: (0.5, 0.5)
Offset: (-165, 6)
+Threat Indicator:
Origin: (0.5, 0.5)
Offset: (-126, -165)
+Lead Indicator:
+Lock Indicator:
+Weapon Linking:
Origin: (0.5, 0.5)
Offset: (86, 3)
+Multiplayer Messages:
Origin: (0.0, 0.5)
Offset: (8, -144)
+Voice Status:
Origin: (0.0, 0.5)
Offset: (8, -129)
+Ping:
Origin: (1.0, 0.0)
Offset: (-128, 5)
+Supernova:
Origin: (0.5, 0.5)
Offset: (-342, -214)
+Offscreen Indicator:
+Target Brackets:
+Orientation Tee:
Origin: (0.5, 0.5)
Offset: (0, 3)
+Hostile Triangle:
Origin: (0.5, 0.5)
Offset: (0, 3)
+Target Triangle:
Origin: (0.5, 0.5)
Offset: (0, 3)
+Missile Triangles:
Origin: (0.5, 0.5)
Offset: (0, 3)
+Kills:
Origin: (1.0, 1.0)
Offset: (-144, -144)
+Fixed Messages:
+ETS Retail:
Origin: (1.0, 1.0)
Offset: (-144, -120)
$End Gauges
#End
(Yes, I understand that we're in a feature freeze right now. I just wanted to make this patch available now.)
-
phwoar!
-
Sounds excellent. :eek2:
-
3440x1920 with patch:
(http://imageshack.us/a/img707/1518/fs2open3619sse2hud20130.png)
3440x1920 without patch:
(http://imageshack.us/a/img855/669/fs2open3617sse2bp201304.png)
5760x1920 with patch:
(http://img812.imageshack.us/img812/1518/fs2open3619sse2hud20130.png)
5760x1920 without patch:
(http://img826.imageshack.us/img826/669/fs2open3617sse2bp201304.png)
Unusual enough for you?
I don't suppose there could be an option for extremely wide resolutions to have the HUD centered? It's not hard to fix it manualy, I already have a hud for it and everything, just wondering if it can be done.
-
Just to let you guys know, the FPS counter and subsystem targeting brackets are still stretched in widescreen resolutions. These issues do not appear to have anything to do with the HUD parser, which is the only thing that my patch changes (aside from the addition of that command-line switch). I'll try to tackle them later, though.
I don't suppose there could be an option for extremely wide resolutions to have the HUD centered? It's not hard to fix it manualy, I already have a hud for it and everything, just wondering if it can be done.
That should be possible. Perhaps if the aspect ratio is 3:1 or wider, we could assume the player is using a triplehead setup and place all the HUD elements in the middle third of the frame, effectively making the HUD use the center screen only. What do you think?
-
Kyad, how ****ed up is the BP2R2 custom hud on those resolutions, using Yarn's patch?
-
Just to let you guys know, the FPS counter and subsystem targeting brackets are still stretched in widescreen resolutions. These issues do not appear to have anything to do with the HUD parser, which is the only thing that my patch changes (aside from the addition of that command-line switch). I'll try to tackle them later, though.
I don't suppose there could be an option for extremely wide resolutions to have the HUD centered? It's not hard to fix it manualy, I already have a hud for it and everything, just wondering if it can be done.
That should be possible. Perhaps if the aspect ratio is 3:1 or wider, we could assume the player is using a triplehead setup and place all the HUD elements in the middle third of the frame, effectively making the HUD use the center screen only. What do you think?
I think that'll work. Maybe a bit smaller than the center 3rd though, as people gaming with 3 screen will compensate for the bezel like I did, and some of it will be lost into nothingness.
Then again, it's impossible to predict just how far they have compensated, as I learned from my own hud, so it may be more effort than it's worth. Even with Eyefinity on, there is still an option in the launcher to use uncompensated resolution, so it won't completely screw people over to not support it.
Kyad, how ****ed up is the BP2R2 custom hud on those resolutions, using Yarn's patch?
Well, Yarn said custom huds don't get to use his code unless they're adapted, so it'll look the same as they do without it (which is not bad actually for 3440x1920, perfectly playable), but 5760x1080 it'll strech out, that's why I made my ultra-widescreen HUD, which I guess is outdated now. If Yarn want's to tell me how to adapt the hud I'll try it though.
But ya, the HUD doesn't look bad:
(http://img507.imageshack.us/img507/669/fs2open3617sse2bp201304.png)
All it needs for 5760x1080 on the "old" HUD code is to be centered, and that's easy. It'd take me like 3 hours, tops.
BP doesn't want to work with his EXE, and I'm not set up to compile, nor do i have access to BP's version of the source (or is it just antipodes?), so that wouldn't work anyway. If you want to make a build for me so I can actually use his code with BP so the custom gauges will be used it'd be appreciated, but until the HUD is adapted, it'll look the same. (Or so I understand it)
-
I uploaded a Blue Planet build for you.
I would certainly like to explain the changes and how to make an adaptable HUD. Keep in mind that I have difficulty explaining this sort of thing, so it will probably be days, maybe longer, before I release any documentation. However, I will make a HUD table that is equivalent to the hard-coded HUD, and then maybe you or someone else can figure it out from that until I do document the adaptable HUD.
-
I uploaded a Blue Planet build for you.
I would certainly like to explain the changes and how to make an adaptable HUD. Keep in mind that I have difficulty explaining this sort of thing, so it will probably be days, maybe longer, before I release any documentation. However, I will make a HUD table that is equivalent to the hard-coded HUD, and then maybe you or someone else can figure it out from that until I do document the adaptable HUD.
BP build you uploaded doesn't work, line failure in question:
bp-shp.tbm(line 222): Error: Required token = [#End], [$Subsystem:], [$Name], or [$Template], found [$Glowpoint overrides: ( "red_glow_10:1,2" )].
ERROR: bp-shp.tbm(line 222):
Error: Required token = [#End], [$Subsystem:], [$Name], or [$Template], found [$Glowpoint overrides: ( "red_glow_10:1,2" )].http://pastebin.com/PfanP9mu
The build supplied by BP works. I'm guessing it has something to do with the deferred lighting code, and the additional TBM options to allow for glow points to glow. It fails that same line for your normal HUD build, and for all other builds I've used.
A HUD made for your HUD code should be enough to adapt the rest.
-
BP build you uploaded doesn't work
I accidentally linked to the regular build. Try downloading it again.
-
BP build you uploaded doesn't work
I accidentally linked to the regular build. Try downloading it again.
Ah, much better.
Patch:
(http://img14.imageshack.us/img14/8197/fs2open3619sse2bpyarn20.jpg)
No patch:
(http://img853.imageshack.us/img853/3825/fs2open3617sse2bp201304.jpg)
-
One last gauge to check is the Camera reticle element when you player Tower Defense.
This looks freaking fantastic. Good work. Also, for triple-screen, be sure to factor in beveling somehow when moving all the side elements to the middle monitor.
-
I updated the patch and the builds. Be sure to use them if you want to make or use custom adaptable HUDs because I changed the HUD table format slightly. (Current custom HUDs should still be compatible.)
Now then, here are tabled versions of the built-in HUD. These are for reference and modding purposes only and should not be included with the MediaVPs.
(EDIT: The tables are now in the original post.)
The three-monitor adjustment is going to be trickier than I originally thought. If the HUD elements are simply moved to the center third, I'll run the risk of causing elements to overlap. I'll need some time to figure out how to do this properly. As for bezel compensation, I think I will initially add a command-line parameter to let the user adjust this manually.
-
Would it be possible to remove the HUD's dependance on the chosen resolution?
Like a -HUDres flag, to act like the -res flag. Defaults to the res chosen in the launcher, but if smaller, put it in the chosen resolution, and center it against the full res?
Most people wouldn't need the assistance of the flag, only those with multi-monitor configs. It would still be much less effort over all (to the end user) to add, say, "-HUDres 1920x1080" to the launcher flags then to have to get a special hud. It would also allow people who use 2560x1600 screens with a 1600x900 in portrait on either side to do it better themselves than anyone could by guessing, and even give normal users the option to center the HUD a bit.
I have no idea how much effort it would take, but it's an idea.
I think I understand the HUD as well.
(http://img543.imageshack.us/img543/1599/42905316.png)
Am I right?
-
I think I understand the HUD as well.
(nice diagram describing the new HUD system)
Am I right?
Yes, exactly! And you're not limited to those specific origins either; any values from 0.0 to 1.0, to any number of decimal places, can be used. (Technically, you can use values outside that range, but then you would move the origin off the screen, so there's no point in doing that.)
When positioning the gauges, remember not to use the Position field together with the Origin and Offset fields. If you do, the gauge will probably be loaded the "old" way and not benefit from the code change. Also, the Origin field has no effect unless it's used together with the Offset field.
Would it be possible to remove the HUD's dependance on the chosen resolution?
Like a -HUDres flag, to act like the -res flag. Defaults to the res chosen in the launcher, but if smaller, put it in the chosen resolution, and center it against the full res?
Most people wouldn't need the assistance of the flag, only those with multi-monitor configs. It would still be much less effort over all (to the end user) to add, say, "-HUDres 1920x1080" to the launcher flags then to have to get a special hud. It would also allow people who use 2560x1600 screens with a 1600x900 in portrait on either side to do it better themselves than anyone could by guessing, and even give normal users the option to center the HUD a bit.
I have no idea how much effort it would take, but it's an idea.
I see what you're getting at. However, I think it's a better idea to specify a maximum width instead. For example, if the player's center screen has a 16:9 aspect ratio, they could use "-max_hud_width 1.77" (16 / 9 = about 1.77) to prevent the HUD from being wider than 16:9.
I'll see what I can do about that.
-
i figure scale gauges proportionally with the vertical resolution, increase horizontal spacing between gauges as a function of aspect ratio. no matter what maintain gauge aspect ratio.
-
Great !! let´s try it :yes:
-
So this is actually a pretty cool feature and does some things I was planning for the HUD table.
However, I think HUD designers should have the sole power to determine if a HUD uses absolute or relative coordinates. The reason why I say this is that HUD designers need to be able to control every aspect of the HUD's appearance which is why I introduced base resolutions and resolution filters in the first place. We should maximize the number of tools modders have at their disposal when designing a HUD. Adding more tools for modders to control HUD appearance is always a good thing. Giving HUD designers the ability to determine relative coordinates but only letting them be used based off of the users' discretion doesn't sound very incentivizing use.
I guess this limits the ability for retail FSO to take advantage of this feature but I'm sure we can discuss some solutions.
In order to address some of these issues people have with super wide screens we should have a option in hud_gauges.tbl that determines scaling behavior that includes but isn't limited to something like "Fill to Best Fit" or something like that.
-
So this is actually a pretty cool feature and does some things I was planning for the HUD table.
However, I think HUD designers should have the sole power to determine if a HUD uses absolute or relative coordinates. The reason why I say this is that HUD designers need to be able to control every aspect of the HUD's appearance which is why I introduced base resolutions and resolution filters in the first place. We should maximize the number of tools modders have at their disposal when designing a HUD. Adding more tools for modders to control HUD appearance is always a good thing. Giving HUD designers the ability to determine relative coordinates but only letting them be used based off of the users' discretion doesn't sound very incentivizing use.
I guess this limits the ability for retail FSO to take advantage of this feature but I'm sure we can discuss some solutions.
My patch already provides HUD designers with the option of whether to use absolute or relative coordinates. Gauges positioned with Position: use the current system (which potentially distorts elements), while those positioned with Origin:/Offset: use the "new" system (which never distorts). HUDs can even mix and match these types of gauges.
In order to address some of these issues people have with super wide screens we should have a option in hud_gauges.tbl that determines scaling behavior that includes but isn't limited to something like "Fill to Best Fit" or something like that.
I already proposed a solution to this that doesn't require messing with tables:
However, I think it's a better idea to specify a maximum width instead. For example, if the player's center screen has a 16:9 aspect ratio, they could use "-max_hud_width 1.77" (16 / 9 = about 1.77) to prevent the HUD from being wider than 16:9.
-
So this is actually a pretty cool feature and does some things I was planning for the HUD table.
However, I think HUD designers should have the sole power to determine if a HUD uses absolute or relative coordinates. The reason why I say this is that HUD designers need to be able to control every aspect of the HUD's appearance which is why I introduced base resolutions and resolution filters in the first place. We should maximize the number of tools modders have at their disposal when designing a HUD. Adding more tools for modders to control HUD appearance is always a good thing. Giving HUD designers the ability to determine relative coordinates but only letting them be used based off of the users' discretion doesn't sound very incentivizing use.
I guess this limits the ability for retail FSO to take advantage of this feature but I'm sure we can discuss some solutions.
My patch already provides HUD designers with the option of whether to use absolute or relative coordinates. Gauges positioned with Position: use the current system (which potentially distorts elements), while those positioned with Origin:/Offset: use the "new" system (which never distorts). HUDs can even mix and match these types of gauges.
In order to address some of these issues people have with super wide screens we should have a option in hud_gauges.tbl that determines scaling behavior that includes but isn't limited to something like "Fill to Best Fit" or something like that.
I already proposed a solution to this that doesn't require messing with tables:
However, I think it's a better idea to specify a maximum width instead. For example, if the player's center screen has a 16:9 aspect ratio, they could use "-max_hud_width 1.77" (16 / 9 = about 1.77) to prevent the HUD from being wider than 16:9.
Regarding that last, I still think that, to the player, it should be in numerical form, not decimal.
I could be wrong, but it doesn't seem like it would be hard to have the HUD code actually do 1920 / 1080 to get 1.77, or 16 / 9 for the same. Less work and more seemless for the player, if you catch my drift. The FOV flag is a serious pain to work with for the same reason, and I would honestly try to avoid that if at all possible.
-
Regarding that last, I still think that, to the player, it should be in numerical form, not decimal.
I could be wrong, but it doesn't seem like it would be hard to have the HUD code actually do 1920 / 1080 to get 1.77, or 16 / 9 for the same. Less work and more seemless for the player, if you catch my drift. The FOV flag is a serious pain to work with for the same reason, and I would honestly try to avoid that if at all possible.
All right, then. Once I figure out how to implement this feature, I should be able to make that parameter work that way.
-
My patch already provides HUD designers with the option of whether to use absolute or relative coordinates. Gauges positioned with Position: use the current system (which potentially distorts elements), while those positioned with Origin:/Offset: use the "new" system (which never distorts). HUDs can even mix and match these types of gauges.
The big issue here is letting this configuration be dependant on the player's command line parameters. I'd rather not pollute the command line with more options.
And besides, this configuration is dependant on if the HUD designer has already modified the table to have relative coordinates already in the table. Otherwise the player is still stuck with the scaled absolute coordinate HUD anyway. Might as well make the player always use it when it's available.
For retail gauges, I wouldn't mind changing the default retail HUD to have gauges with relative coordinates.
I already proposed a solution to this that doesn't require messing with tables:
As I said, I'm not a fan of more command line parameters which is why I'd rather have it stowed away in a table. Speaking as someone who designed the Colonial HUD in Diaspora, HUD designers would gladly have tools like "Fill to Best Fit" or "Fill to Height".
This option doesn't seem as dependant on the HUD table so it might be okay to have a compromise and have it both configurable via table and commandline.
-
The central crux of my issue with this patch and your proposed solution to My patch already provides HUD designers with the option of whether to use absolute or relative coordinates. Gauges positioned with Position: use the current system (which potentially distorts elements), while those positioned with Origin:/Offset: use the "new" system (which never distorts). HUDs can even mix and match these types of gauges.
The big issue here is letting this configuration be dependant on the player's command line parameters. I'd rather not pollute the command line with more options.
And besides, this configuration is dependant on if the HUD designer has already modified the table to have relative coordinates already in the table. Otherwise the player is still stuck with the scaled absolute coordinate HUD anyway. Might as well make the player always use it when it's available.
For retail gauges, I wouldn't mind changing the default retail HUD to have gauges with relative coordinates.
Are you referring to the -nohudscaling flag? Just to be clear, that flag does not enable the system that solves the problem of HUD stretching--that system is always enabled for the retail HUD and custom HUDs designed for it. Rather, -nohudscaling basically tells the engine not to upscale HUD elements if the HUD's base resolution is smaller than the screen resolution, although it has no effect on elements using absolute coordinates. In other words, the flag affects only the size of elements, not their proportion.
I'm fine doing away with this flag, especially considering that it doesn't always work. It was a secondary feature anyway.
I already proposed a solution to this that doesn't require messing with tables:
As I said, I'm not a fan of more command line parameters which is why I'd rather have it stowed away in a table. Speaking as someone who designed the Colonial HUD in Diaspora, HUD designers would gladly have tools like "Fill to Best Fit" or "Fill to Height".
This option doesn't seem as dependant on the HUD table so it might be okay to have a compromise and have it both configurable via table and commandline.
Again, to be clear, the feature discussed here (which isn't the main feature of this patch, just so you know) is meant to place all HUD elements on the center screen of a triple-monitor setup; it has nothing to do with stretching. As far as I can tell, it is impossible to do this automatically, so the user would have to specify the aspect ratio of the center monitor.
In my opinion, TBLs and TBMs (as far as FreeSpace is concerned) are among the worst places to store user settings, even worse than the command line (which, I agree, isn't a good place either). It's similar to making a car seat adjustable only from underneath the car.
Perhaps we can hold off on adding this (the triple-monitor thing, not the relative positioning) until it gets more demand or the user settings can be moved to a better place.
-
There has been work done on an in-game expanded user settings interface. It might not be as far off as one would fear.
-
Who is working on that and where can I keep track of the progress? :O
-
I updated the patch and the builds again to remove the -nohudscaling flag and make a few other minor improvements.
-
i envision drawing an imaginary box on your screen that is of lesser aspect ratio, but is the same height, and then centered. and then mapping hud gauges within that box rather than in pure screen coordinates. you can still use absolute mapping but these are in box coordinates 0 being the leftmost side and vertical_res*box_aspect being the right most side, and if you want you can use resolution agnostic 0-1 mapping coords as well (also box relative). the space outside of that box is considered out of bounds and no hud gauges will be drawn there. then just have a setting to indicate what the maximum hud aspect ratio should be. it can be anywhere between 1 and the actual aspect ratio of the monitor. if you have 3 16:9 monitors connected together for a total of 48:9, and you set the max aspect ratio to 16:9, and the hud will only fill the center monitor. it also lets you do other things like keep a 4:3 hud on a 16:9.
not sure what to do about that offscreen target indicator. i imagine it floating somewhere between the edge of the screen and the hud box, which probibly looks ugly as hell. in my old cockpit script i used a little arrow indicator which circled the reticule (i believe i stole the idea from freelancer), it didnt give you any info about how far to turn but it at least gave you a hint to which direction you needed to push your joystick. you could probily do the same thing with a split arrow, and it would look pretty good.
-
i envision drawing an imaginary box on your screen that is of lesser aspect ratio, but is the same height, and then centered. and then mapping hud gauges within that box rather than in pure screen coordinates. you can still use absolute mapping but these are in box coordinates 0 being the leftmost side and vertical_res*box_aspect being the right most side, and if you want you can use resolution agnostic 0-1 mapping coords as well (also box relative). the space outside of that box is considered out of bounds and no hud gauges will be drawn there. then just have a setting to indicate what the maximum hud aspect ratio should be. it can be anywhere between 1 and the actual aspect ratio of the monitor. if you have 3 16:9 monitors connected together for a total of 48:9, and you set the max aspect ratio to 16:9, and the hud will only fill the center monitor. it also lets you do other things like keep a 4:3 hud on a 16:9.
That's pretty much the idea. Actually, almost every HUD element, including the off-screen indicator, would be confined to the specified maximum width. The only exceptions would be things that follow the targeted ship, like targeting brackets and the lead indicator. How a gauge behaves in this regard could be specified in hud_gauges.tbl.
-
Forgive my noobness, I'm still very green with Freespace 2 having only gotten the game a week ago. I'm having a crash with this build, and I can't seem to fix it.
Running Freespace 2 GOG, this build of Freespace 2 Open (sitting beside 3.6.18's files, didn't hurt so why not), and MediaVPS 3.6.12. All very normal stuff. Well, I was using this build for several days without a hitch, sitting in the directory beside 3.6.18 and working great. The FS2O launcher I'm using, FS2 Open Launcher 5.5g, was still tied into FreeSpace 2 Open 3.6.18. I was curious about connecting it with the Yarn build; I assumed I could just undo it if there was any problems, so why not? So I ran the launcher, selected "fs2_open_3_6_19_SSE2_Yarn.exe" at the top, hit apply, and ran the Yarn build. It crashed immediately after selecting my pilot profile, never reaching the main menu. I immediately undid the selection in the FS2O launcher and ran the build normally but, it still crashes. I even copy pasted the build back in, with the original files from the zip just to make sure nothing was corrupted. No dice. 3.6.18 is unaffected, and works normally. I miss the nice hud though... So uh, what's going on? Is this a bug, or did I do something really stupid? Or both lol.
-
Forgive my noobness, I'm still very green with Freespace 2 having only gotten the game a week ago. I'm having a crash with this build, and I can't seem to fix it.
Running Freespace 2 GOG, this build of Freespace 2 Open (sitting beside 3.6.18's files, didn't hurt so why not), and MediaVPS 3.6.12. All very normal stuff. Well, I was using this build for several days without a hitch, sitting in the directory beside 3.6.18 and working great. The FS2O launcher I'm using, FS2 Open Launcher 5.5g, was still tied into FreeSpace 2 Open 3.6.18. I was curious about connecting it with the Yarn build; I assumed I could just undo it if there was any problems, so why not? So I ran the launcher, selected "fs2_open_3_6_19_SSE2_Yarn.exe" at the top, hit apply, and ran the Yarn build. It crashed immediately after selecting my pilot profile, never reaching the main menu. I immediately undid the selection in the FS2O launcher and ran the build normally but, it still crashes. I even copy pasted the build back in, with the original files from the zip just to make sure nothing was corrupted. No dice. 3.6.18 is unaffected, and works normally. I miss the nice hud though... So uh, what's going on? Is this a bug, or did I do something really stupid? Or both lol.
I can think of a number of things you might have done wrong. But first, using the debug version of my build (found in the same zip file), follow these instructions (http://www.hard-light.net/forums/index.php?topic=56279.msg1180359#msg1180359) (read that post thoroughly, please) to generate and post your fs2_open.log. If you get an error message (which is not the debug log), post that too.
-
Fairly certain it's a pilot file problem, since the main difference between 3.6.18 and the 3.6.19 stuff in testing is a huge pilot file code update. You were mostly right about being able to undo if any problems, and your precautions were all good, except it was your pilot file that got modified. Ideally 3.7 will have all this fixed, but who knows... there's so many permutations... it's entirely possible the bug you ran into has been fixed since April, but it may be too late for your particular pilot file.
I suggest making a new pilot file for use with Yarn's build and future stuff like 3.7 -- pretty sure that's all you'll need to do to fix this crash. If you're ever able to get it to happen again, report it on Mantis -- it's something that we'd like to fix before 3.7 final. And yeah, if it turns out it ISN'T a pilot file problem, Yarn's debug log instructions are important and good.
-
Right on all counts guys. Making a new pilot worked like a charm. I remember reading about incompatibilities between FS2 and FS2O pilot profiles before so... I should have thought of that. Oh well, I guess I didn't cause I bounced back and forth for a while without problem. I'll just have to start again. No big deal, I wanted to play it through again anyway :D. Thanks for the help guys. I'll upload the log anyway, just in case.
Also, awesome patch Yarn. I spent almost an hour fiddling with HUD coordinates before I found it. SO much better.
[attachment deleted by ninja]
-
It's good that you were able to get it working.
However, you are missing the update for MV_Effects. Get it here (http://www.hard-light.net/forums/index.php?topic=70736.0).
-
Oops >_<. Downloaded it but forgot to install it. Thanks for the heads up, I didn't notice.
-
Yarn
Ty from Spain for your job
Hud in Triple scrren now works great
but i'm using fs2_open_3_6_19_SSE2_Yarn.exe
and SILENT THREAD REBORN 1.3 don't respect hud config
it seems that mod overrides your patch
Any idea to make it work properly
(please excuse mi bad english)
-
In the fsport-mediavps\data\tables folder (create it if it doesn't exist), create a new file called mv_root-hdg.tbm. Add these lines to the file:
$Reticle Style: FS1
$Max Escort Ships: 9
-
worked great
you're a pro
ty indeed
i'm going to bed now, it's 3:00 here; time for some sleeping
ty again
-
Hi Yarn,
doubt again:
models i see in lower left target screen are not the same in main game
so if I have silent-threat-reborn-nice-models in game, what i see in taget window (screen) is the usual model not the nice one
its normal to have difent images of same ship?
hope you undestand mi doubt
-
By default the model used in the target view is LOD1. i.e. a lower detailed model than what you see up close in the main view (LOD0). This is done for performance reasons since the target window is quite small and you probably can't tell the difference between LOD0 & 1 at that size. Obviously you've got better vision than most of us :)
-
ty for quick answering
theres a easy way to place lod1 at target window?
-
LOD 1 is displayed in the target window by default. I'm not aware of any general-use case where that has been changed.
There is, however, a ships.tbl option to specify a different LOD in the target window for a particular ship.
-
Uh, guys, it's me again. It happened yet again, in the exact same spot. Only this time, I was using Yarn's build exclusively through the entire campaign. The exact mission is right at the end, the the second of the two part series where you can't pick your ship. That's the same spot it was at the last time, and it's doing it again. Just like last time, making a new save works. But I only used fs2_open_3_6_19_SSE2_Yarn.exe. I haven't even touched the launcher in weeks. Oye. I was really hoping to finish this time...
As for how the error was created, I don't really know. I did the first mission, and then upon entering the second mission, I realized I was woefully equipped for it and bailed. I saved there and came back to it a couple days later, and boom, can't play it. Crap. At least, pretty sure that's where it was saved, to be honest it's been a couple of days and I didn't pay that much attention. It could be the first of the two. Anyway, I sent the error log last time, so is there anything else I can do?
-
I know the campaign is long, but could you try playing through it again with the most recent nightly build (http://www.hard-light.net/forums/index.php?board=173.0), without my patch? I very strongly doubt that my patch is really causing the crash.
-
IIRC there's been a few more red-alert bugfixes in trunk since Yarn created his exec. If you post your pilot files (freespace2/data/players: .plr & .csg) I'll see if there's an easy fix I can make to get them working again.
-
IIRC there's been a few more red-alert bugfixes in trunk since Yarn created his exec. If you post your pilot files (freespace2/data/players: .plr & .csg) I'll see if there's an easy fix I can make to get them working again.
I have been updating my builds occasionally, actually. Right now, as shown in the original post, the builds are based on revision 9689, which is essentially 3.7.0 RC2. I will add a date there so it's more obvious how up to date the builds are.
-
ah sorry, should have checked the OP...
-
If you post your pilot files (freespace2/data/players: .plr & .csg) I'll see if there's an easy fix I can make to get them working again.
I'd appreciate that. I haven't even seen the end of the game yet. >_< I wasn't sure which file, since there are some in the directory and in the "single" folder, so I just 7zed the whole directory. It's attached.
I know the campaign is long, but could you try playing through it again with the most recent nightly build, without my patch? I very strongly doubt that my patch is really causing the crash.
That.... would take a while. I've already played it through twice in a row. Oh well, I really enjoy it, so I'll give it a try. It's possible the bug was already fixed though. God I hope so. Well, I'm sorry for cluttering your thread. Should I take this discussion somewhere else?
[attachment deleted by ninja]
-
I've given your pilot a test with the latest trunk code and it worked fine, the last mission loaded & you've got 3x Alpha, 1x Beta & 1x Gamma wingmen remaining. If you re-download & use Yarn's exec from the OP (it now includes a patch for the problem you encountered) I think you should be able to complete the campaign without needing to restart.
-
Yep, that fixed it indeed. And I was finally able to see the end. Holy crap.
Anyway Yarn, sorry to bother you about this stuff. Delete the posts if you'd like. Thanks for the help, and the patience in mucking up your thread.
-
I read through all three pages, but I didn't find a concrete answer: Can I use only the tbl file you provided and not the patch and get the same effect of an adaptable hud?
-
I read through all three pages, but I didn't find a concrete answer: Can I use only the tbl file you provided and not the patch and get the same effect of an adaptable hud?
No. Those tables require a feature that only my patch provides. Furthermore, they're not meant to enable anything; they're only for reference (i.e., for modders to use as a base for their own HUDs).
-
I read through all three pages, but I didn't find a concrete answer: Can I use only the tbl file you provided and not the patch and get the same effect of an adaptable hud?
No. Those tables require a feature that only my patch provides. Furthermore, they're not meant to enable anything; they're only for reference (i.e., for modders to use as a base for their own HUDs).
Gotcha, and I am constructing a custom hud, so I thought maybe I could only use the tbl file, but it is still definitely helpful. And just to double check I put the actual patch file in the table file correct?
-
Gotcha, and I am constructing a custom hud, so I thought maybe I could only use the tbl file, but it is still definitely helpful. And just to double check I put the actual patch file in the table file correct?
No. The patch won't work if it's placed in a TBL/TBM file. Rather, it's supposed to be applied to the game's source code, which must then be compiled. Instructions on how to do this in Windows are here (http://www.hard-light.net/forums/index.php?topic=82688.msg1479356#msg1479356). If you use another operating system, then unfortunately I can't help you compile.
And if you are running Windows, then there's really no need to mess with the patch or compile. The original post has Windows builds that, as of now, are basically 3.7.0 RC2 with the patch applied.
-
No. The patch won't work if it's placed in a TBL/TBM file. Rather, it's supposed to be applied to the game's source code, which must then be compiled. Instructions on how to do this in Windows are here (http://www.hard-light.net/forums/index.php?topic=82688.msg1479356#msg1479356). If you use another operating system, then unfortunately I can't help you compile.
And if you are running Windows, then there's really no need to mess with the patch or compile. The original post has Windows builds that, as of now, are basically 3.7.0 RC2 with the patch applied.
Got it I do have windows luckily. I think I will still try and learn how to do the compiling since it seems like a useful thing to know. Thanks again for all the help. Sorry if these seemed like simple questions.
-
Another question about the pilot files: The HUD build seems to create a multipayer pilot as well after creating a single player pilot. Why?
Also, my old "inferno" pilots are empty on the HUD build.
It would be nice if someone could enlighten me a bit about this whole pilot thing. Although I have already read plenty of stuff, I don't quite seem to understand. Currently all I know is I prefer how 3.6.18 handles pilots.
-
A quick rundown:
3.6.18:
Pilotfiles are in data/players/single/inferno (for inferno builds, but lets not widen the rabbit-hole)
Main file is .plr2
There's one campaign file per campaign you played, .cs2
Multiplayer pilots are completely separate to single player pilots
3.6.19 & higher:
Pilotfiles are in data/players
Main file is .plr
There's one campaign file per campaign you played, .csg
New format is more robust/fault tolerant than the old format (and should handle redalerts better, they were notoriously unreliable in 3.6.18 & prior)
New format is much easier to extend / add new things to than the old format (e.g. new key controls)
Single player pilots are now used for multiplayer as well
The old format files are converted to new format files if new files with the same name don't already exist (i.e. usually only happens once unless you delete your .plr & .csg files)
We're still fixing some bugs with the new pilot code (mostly minor stuff I think)
edit: fix some errors
-
Thanks allot niffiwan, that really helped!
-
I updated the builds again to incorporate recent fixes to the pilot conversion code.
-
Is it possible to apply the patch to the game without making a new build? I don't know how .patch files work...
If not, is this available in a post-3.7.0 build, such as one of the Nightlies?
-
Is it possible to apply the patch to the game without making a new build? I don't know how .patch files work...
No. Patch files must be applied to source code. If you are running Windows and wish to learn how to use patch files and compile, instructions are found here (http://www.hard-light.net/forums/index.php?topic=82688.msg1479356#msg1479356).
Note that I do have links to Windows builds in the original post. If you think it's time for them to be updated, let me know.
If not, is this available in a post-3.7.0 build, such as one of the Nightlies?
Not right now, and it won't be unless the SCP team decides to commit it. If it does get committed, either I or an SCP member will eventually say so.
-
This is relevant to my interests, and I am posting here to remind myself to apply this patch when I get my screens up and running how I intend, assuming it's not already in trunk by then.
-
Just wondering, have any SCP members considered this patch yet?
-
Not sure but I modified the OP title to indicate this is submitted for Code Review and not just a discussion about implementation ideas.
-
Finally, a bit of code review for this (only 7+ months since the original post :nervous:)
Overall, it looks good. My only comment is, the exact code below is duplicated for all except two of the gauges; load_gauge_custom & load_gauge_fixed_messages (and I'm not sure why this part of load_gauge_custom is different anyway). It would probably be easier to maintain in future if this could be put into a function? Maybe something like this:
void hud_gauge_parse_position( int * coords, float *origin, int *offset, int *base_res, const int base_w, const int base_h, bool handle_default_position = false);
(returns coords)
if(check_base_res(base_w, base_h)) {
base_res[0] = base_w;
base_res[1] = base_h;
if(optional_string("Position:")) {
stuff_int_list(coords, 2);
} else {
adjust_base_res(base_res);
if(optional_string("Origin:")) {
stuff_float_list(origin, 2);
}
if(optional_string("Offset:")) {
stuff_int_list(offset, 2);
}
coords[0] = (int)(base_res[0] * origin[0]) + offset[0];
coords[1] = (int)(base_res[1] * origin[1]) + offset[1];
}
} else {
adjust_base_res(base_res);
coords[0] = (int)(base_res[0] * origin[0]) + offset[0];
coords[1] = (int)(base_res[1] * origin[1]) + offset[1];
}
What are your thought on that idea?
-
I did that some time ago for my TrueType patch but it can be easily changed so it works with the current trunk: https://github.com/asarium/fs2open.github.com/blob/trueType/code/hud/hudparse.cpp#L1058 (https://github.com/asarium/fs2open.github.com/blob/trueType/code/hud/hudparse.cpp#L1058)
The new function bundles most of the functionality of hud gauge parsing and not only coordinate handling.
-
That looks good m!m, I'll have a more detailed look over the weekend :)
-
So I made my first builds for BP based on Yarn's patch file and BP patch file. The trunk version is 10143 (11-21-13 afternoon). This download does not contain AVX versions as I don't have an AVX processor and didn't want to risk issues. I haven't tested these so feedback would be appreciated. Link: http://www14.zippyshare.com/v/37886302/file.html
-
BTW is there any negative consequences in using BP build for all the other mods? Any compatibility errors?
If there is, I would kindly ask for a new Yarn build (BP NOT included) :) I looked at the Master Sticky thread, and I wasn't really liking the idea of installing new stuff just to apply a patch for new nightly builds once or twice. Or is the Yarn's HUD patch gonna be included in the new official version of SCP?
-
Ok, so this is Revision 10147 of the normal builds dated today or tomorrow early morning while it's still dark outside :) It looks like my compiler lets me do AVX builds after all, but I can't test them. In fact, I haven't tested any of these. So leave some feedback so that I know I'm doing it correctly. This has Yarn's patch in it. Here's the link: http://www56.zippyshare.com/v/44169379/file.html (http://www56.zippyshare.com/v/44169379/file.html)
-
Can the HUD elements be relocated by editing Yarns patch file?
I'm trying to play this on my three monitor array. The .exe files with Yarns patch work pretty well, but the elements on the far edges of the monitors are just too far away.
-
I updated the builds again.
Can the HUD elements be relocated by editing Yarns patch file?
I'm trying to play this on my three monitor array. The .exe files with Yarns patch work pretty well, but the elements on the far edges of the monitors are just too far away.
I do want to allow easy adjustment for your kind of setup, but that's probably not going to happen until the command line is no longer used for options.
For now, try the attached file. Place it in mediavps_3612\data\tables (create it if it doesn't exist). Then, make sure that mediavps_3612 is selected as the active mod. Then, play the FS2 campaign and see how the HUD looks.
[attachment deleted by an evil time traveler]
-
Hey Yarn, do you have to manually reposition all elements in the tbm file to make it fit his resolution, or do you have a set formula for adjustment? Cause if you do then perhaps by making some sort of simple GUI that can generate a .tbm file for each user's needs or have a configurator that allows direct editing of the tbm file would be awesome. Perhaps have an autodetect resolution function in there as well.
Then again, I don't want to burden you with extra work...just thought I'd mention some sort of idea to help you out ;)
-
I updated the builds again.
Thank you very much!
-
Well, the weekend is over and RL stuff meant that I didn't get as much done on this as I would have liked. I'm still in the process of updating m!m's patch to get it into trunk. Once that's done I'll get Yarn's patch updated and put them both up for some review.
@Lykurgos88
Yep, I'm aiming to get Yarn's patch into the next official SCP version.
-
Yep, I'm aiming to get Yarn's patch into the next official SCP version.
Ok, so all I have to do is create a few builds here and there until this happens...cool.
Edit 1: And here we go with the latest Yarn Patch and build 10156 located here:- http://www17.zippyshare.com/v/88451529/file.html
-
Hi again,
I have two small (not game-breaking) HUD-related problems. The other is related to Yarn's patch, the other is not (but I thought it would probably better to bundle them together).
First off, the Adaptable HUD patch seems to screw up the Wings of Dawn video message screen. It is only partially filled, as demonstrated in this picture:
(http://koti.mbnet.fi/olzie/Moebius/Little-videochat.jpg)
I think this happens only in WoD. For example Dimensional Eclipse doesn't have this problem. The way I see it, either the animation itself is too small (resolution wise), the screen scaling doesn't work properly, or both.
---
The other problem has been present ever since I made a fresh install of FSO and downloaded the official 3.7.0 build. It also happens in all the other builds I have tried; including Yarn, BP and newest Nightlies. It's related to the in-game message screen. The invisible box, that is supposed to contain 3 lines at a time, is a bit too small on the left and on the top. This effectively means that some pixels on the left and on the top disappear even though there seems to be a enough room to render. To demonstrate this issue, I played the "Surrender, Belisarius" mission with both FSO and FS2 retail in order to make screenshot comparison.
This is how it looks in FSO:
(http://koti.mbnet.fi/olzie/Moebius/FSO-chat.bmp)
And this is how it looks in the retail FS2:
(http://koti.mbnet.fi/olzie/Moebius/Retail-chat.bmp)
The easiest way to spot these disappeared pixels is to look the first character of Alpha: "A" and the number "2". "A" is almost missing its left leg and "2" is missing its "hat". Retail seems to render messages pixel perfect, but FSO doesn't.
I played FSO with a resolution of 1920x1080@32bit and Retail FS2 with 1024x768@32bit.
-
@Lykurgos88:
1: What's happening here is that WoD: Stranded replaces the message window with a bigger one but does not include larger head ANIs. This causes exactly what you're seeing, whether or not you're using my patch (try it in 3.7.0 and you'll see the same thing). You should let the WoD team know about this so that they can fix it. (EDIT: Looks like they already know (http://www.hard-light.net/forums/index.php?topic=82674.0), so no need to tell them.) For now, you can work around this by removing Stranded_V0.99.vp from your WoD folder (but you do need that file to play Stranded, obviously).
2: This appears to have something to do with how the font is scaled (and it happens to me too, so you're not the only one). I suggest making a new thread about this. After all, as you effectively said, this has nothing to do with my patch.
-
It's Yarn's fault. By messing with the scaling of the HUD he messed with the scaling of the universe <- and THAT causes the text to be cut off at the top. Things have to be in "Sync" you know ;)
I think I may have noticed this issue myself but rather than point out the obvious like Lykurgos88, I developed the habit of always pressing F4 to check previous messages. Like he said it wasn't game-breaking so rather than report it I just developed that habit. It would be soo weird if font scaling was the issue.
-
1. What's happening here is that WoD: Stranded replaces the message window with a bigger one but does not include larger head ANIs.
Okay, that's good to know. It seems this was a coincidence I didn't even think about. Because originally I started Wings of Dawn with 3.7.0 and without any addons (like Stranded, A nordera day etc.) and then I moved to try other mods. At some point I got frustrated with the stretched HUD and I switched to Yarn's patch. Then I installed WoD expansions and continued the main campaign. So this gave me an illusion that this problem was caused by Yarn's patch, when in reality it apparently had nothing to do with it. :P
2: This appears to have something to do with how the font is scaled (and it happens to me too, so you're not the only one). I suggest making a new thread about this.
Right. I'll make a new thread in a moment or two.
-
I updated the builds again.
Can the HUD elements be relocated by editing Yarns patch file?
I'm trying to play this on my three monitor array. The .exe files with Yarns patch work pretty well, but the elements on the far edges of the monitors are just too far away.
I do want to allow easy adjustment for your kind of setup, but that's probably not going to happen until the command line is no longer used for options.
For now, try the attached file. Place it in mediavps_3612\data\tables (create it if it doesn't exist). Then, make sure that mediavps_3612 is selected as the active mod. Then, play the FS2 campaign and see how the HUD looks.
This is great! Thanks Yarn!
I use three old 20" Dell FP2001 displays. Each is 1600x1200, but with bezel compensation the total resolution is 5076x1200. In an attempt to improve immersion, I built my desk to allow me to sit close to the displays. The downside is when HUD elements are at the far edges.
(http://i187.photobucket.com/albums/x120/geo111/HOTAS2008.jpg)
-
Hi, thanks for all your work. But im pretty new to this stuff and it dosent work for me. My launcher freezes when i try to select the exe file. Could you perhaps do a step by step on howto use your patch? im not sure ive done it correctly.
thanks alot
-
Does it freeze if you try to select a normal 3.7.0 build (http://www.hard-light.net/forums/index.php?topic=85435.0)? If so, which ones (standard, SSE, no-SSE)?
-
hi thanks for your reply. No, it dosent freeze with the normal executables. Just when i try to use fs2_open_ant_7r_INF, fs2_open_3_7_1_SSE2_Yarn, fs2_open_3_7_1_SSE2_BP_Yarn, fred2_open_3_7_1-20131127_r10174. These are the ones ive tried, with hud tables, and your patch for the hud without. But they all freeze both launchers.
-
Try both of the attached builds and tell me which ones work. They're built with Visual Studio 2013 from the 3.7.0 branch without changes. If any of them crash or freeze, I want you to give me your system specs, primarily your operating system and CPU.
For the record, fs2_open_ant_7r_INF is old and obsolete, and all of its features have been in regular builds since 3.6.14.
[attachment deleted by an evil time traveler]
-
yea ok, i was just trying alot of different files to see if they would work. the same issue happens, but now i noticed that my launcher says "executable does not exist". im adding a prt screen so u can see.
my system specs are:
Win 7 64 bit
amd athlon 2 x4 640 3ghz
16gb ram
AMD Radeon HD 6900 Series primiary
AMD Radeon HD 6670 secondary
and i have 2 20 inch and one 24 inch monitor connected to primiary for eyefinity. and a tv on the secondary.
thanks alot for helping me out.
[attachment deleted by an evil time traveler]
-
So you tried both builds ("fs2_open_3_7_0_test" and "fs2_open_3_7_0_SSE2_test") and they both froze, correct?
(Protip: To keep animals out of your posts, spell "a lot" correctly. It's two words, not one.)
-
hehe, ok will do. was wondering why that kept happening. Yea they both froze with wxlauncher and fs2 open launcher. Do you know why?
-
Try renaming one of the builds to something short (no more than 14 characters) and then selecting that. If it still freezes, then something about your computer doesn't like most of the builds found here.
-
no still freezes. Thanks for trying tho. Thankfully i can still play the game, so not the worst case. This fs2 open is pretty amazing.
-
I can think of only four possible reasons for this happening:
- your OS X mod
- your CPU
- bad drivers
- malware (have you run a scan lately?)
Unfortunately, you might have to reinstall Windows to make the other builds work, and even that might not help, especially if your CPU is the problem.
-
Its probably my cpu then. I got it a year or two ago with the moba and it was pretty cheap. The osx mod is just an installable skin pack, my antivirus runs day n night and i had a fresh install of win 7 a couple weeks back.
ill try to disable my osx skin and update my drivers. Hopefully that does it!
-
Well there are a few questionable files that I see. Why do you have 3 data folders? You should only have "data" folder. I dunno why you have a CD.dll file and what that gfw_high does either. Google search indicates that it is something that comes with PlayonMac, which is used on a Mac, and yet you say it's not. I mean your specs are PC type. So why do you have PlayonMac files in that folder? I can only assume that there is something you're not telling us as the gfw_high file is the proof.
So let me ask you this: Is that a clean installation of FS2 or did you copy it from somewhere, say, from a Mac?
-
Why do you have 3 data folders? You should only have "data" folder.
GOG.com version of Freespace 2 has 3 data folders. Data2 and data3 only have cutscene.mve -files in them (10 in total).
Anyway,
I was noticing that this Adaptable_HUD patch no longer has any effect on the new MediaVP_2014 Beta, at least with a 16:9 monitor. No difference between this build and the newest nightly. However, the new HUD (even though it's NOT stretched anymore) is a bit buggy, as I demonstrated in the release thread.
-
That'd be because the new mediavps beta contains a hud gauges table designed for widescreen monitors, and that would be overriding Yarn's changes.
-
Well there are a few questionable files that I see. Why do you have 3 data folders? You should only have "data" folder. I dunno why you have a CD.dll file and what that gfw_high does either. Google search indicates that it is something that comes with PlayonMac, which is used on a Mac, and yet you say it's not. I mean your specs are PC type. So why do you have PlayonMac files in that folder? I can only assume that there is something you're not telling us as the gfw_high file is the proof.
So let me ask you this: Is that a clean installation of FS2 or did you copy it from somewhere, say, from a Mac?
all i did was a clean fs2 install and then the fs2 open full install on top. and my os is win 7. There might be some other exe files in my fs2 directory as ive tried several and not deleted all of the ones which didnt work.
-
I see. I have a feeling that the PlayonMac stuff sitting in that folder might be the cause for the game not starting. Somehow it might be overriding your OpenGL settings and trying to enforce them in a Mac-like execution. This is mere speculation though. Since you say you've tried multiple things, they could be somehow conflicting with each other.
First I want you to try downloading an OpenGL test like GpuTest or FurMark to see if OpenGL works on your machine. Don't run these tests for too long; anywhere below five minutes is fine unless you have absolute confidence in your machine. These will really stress your machine but will tell if OpenGL works or not.
If the above works, then you're gonna have to do this:-
I recommend you just delete that Freespace 2 installation and start from scratch. No need to reinstall Windows though. (Phew!) You know how to do this, right? Install Freespace 2, then download the latest 3.7.1 build (either in my previous posts or from the nightly builds). Download the latest mediavps. Download the campaigns. Download wxlauncher.
Yes, you might have some of those files already, but unless they've been updated in the past month or two I'd recommend redownloading them, even if they are big downloads (mediaVPs can be big). I did redownload myself. Let's see: Builds go in main Freespace 2 folder or a subfolder if you prefer, MediaVPs go in "mediavps_3612" folder in the main Freespace 2 folder. wxlauncher goes in main Freespace 2 folder. Campaigns go in whatever folder they extract as, BUT make sure they only go 1 level deep, ex: Freespace2/Sync .
-
You could just verify the MD5 checksums of the large files and move them to your new install one at a time as you verify. It might seem tedious but it's probably faster than redownloading (moving a file is instantanious while even a high-speed download will take minutes / hours)
Use the program HashTab (http://implbits.com/hashtab.aspx) to verify the MD5.
Just right-click the file, click properties, then File Hashes, then paste the correct (from the forums) MD5 into the compare box and it will tell you if it's the exact same or not. If it is, move that file to the new install directory.
Just a thought.
-
Well there are a few questionable files that I see. Why do you have 3 data folders? You should only have "data" folder. I dunno why you have a CD.dll file and what that gfw_high does either. Google search indicates that it is something that comes with PlayonMac, which is used on a Mac, and yet you say it's not. I mean your specs are PC type. So why do you have PlayonMac files in that folder? I can only assume that there is something you're not telling us as the gfw_high file is the proof.
All of the files and folders that you're questioning here is normal for GOG.com installations. Gfw_high.ico is just an icon file for the desktop and start menu shortcuts, and data2, data3, and CD.dll exist so that the original CDs are not required. They have nothing to do with PlayonMac.
-
I've finally got m!m's common hud parsing merged with Yarn's patch. I thought I try using the github pull process to get this reviewed, basically as a demo of how this could all work when we switch to git :) (note; DO NOT actually merge the pull request, it'll need to be converted & committed to SVN once the review process is completed)
Anyway - could someone please review my changes to ensure I haven't affected the behaviour of Yarn's original patch?
https://github.com/scp-fs2open/fs2open.github.com/pull/1
Here's the feature branch if you want to pull it down to compile/test:
https://github.com/niffiwan/fs2open.github.com/tree/yarn_hud
If you want to grab it via SVN, it's a little different from normal:
svn co -N https://github.com/niffiwan/fs2open.github.com fs2open
cd fs2open
svn up -N branches
svn up branches/yarn_hud
cd branches/yarn_hud
edit: typos
-
Anyway - could someone please review my changes to ensure I haven't affected the behaviour of Yarn's original patch?
The only problem that I noticed is that the if statement at line 1,115 in hudparse.cpp is missing an else statement that calls adjust_base_res(). Because of this, positionless gauges (such as target brackets) that are specified in a HUD table will stretch. (I'd post a patch, but I can't figure out how to create one. I'm using TortoiseGit, by the way.)
Another thing: the gauge_load_common() function has a parameter called default_position. It defaults to false, and no calls to this function ever set it to true. What is this parameter for?
EDIT: Oh, and you've got two semicolons at line 5,087 in hudparse.cpp.
-
Thanks for checking the patch. I've put some comments in the pull request - I'll also copy them here:
The only problem that I noticed is that the if statement at line 1,115 in hudparse.cpp is missing an else statement that calls adjust_base_res(). Because of this, positionless gauges (such as target brackets) that are specified in a HUD table will stretch.
If I understand correctly - you mean add:
} else {
adjust_base_res(base_res);
}
at line 1139?
Another thing: the gauge_load_common() function has a parameter called default_position. It defaults to false, and no calls to this function ever set it to true. What is this parameter for?
This is the one gauge (load_gauge_messages) that uses "default_position" - it's to deal with the magic number on line 4266
EDIT: Oh, and you've got two semicolons at line 5,087 in hudparse.cpp.
Thanks & fixed.
(I'd post a patch, but I can't figure out how to create one. I'm using TortoiseGit, by the way.)
I think TortoiseGit has a "diff" option in its menu, so I figure you mean that you can't get the code that you need to base the diff from?
I don't have much experience with TortoiseGit, but assuming that you've already got the main repo cloned, you can probably do this:
1) setup my fork as a remote (https://github.com/niffiwan/fs2open.github.com)
2) pull (i.e. fetch) the "yarn_hud" branch to a local branch
3) code & send diff
(there's probably other ways to move the commit around without pasting diffs, but I'm not 100% sure on how to do it, probably involves having your own fork on github, a copy of the yarn_hud branch & sending my fork a pull request)
Alternatively, you can just clone my fork and checkout/switch to the yarn_hud branch. I think this page has a decent explanation:
http://joelabrahamsson.com/remote-branches-with-tortoisegit/
The relevant section is titled "Fetching the remote branch", and the remote branch name to use is remotes/origin/yarn_hud.
If that doesn't help, let me know some details and I'll see how else I can help. I should note that this is exactly the type of issue that we want to sort out / document properly before we make a switch to git as the primary FSO repository.
-
(I'd post a patch, but I can't figure out how to create one. I'm using TortoiseGit, by the way.)
- Right click on the /code/ folder or, if you have the code folder already open, right click in an empty area of the File Explorer.
- Select "TortoiseGit" from the menu, then "Diff" (which should be somewhere in the middle of the r-click menu)
-- A dialog should pop up showing a diff, or another one to inform you that you haven't chosen a program that will operate on Diff's, TortoiseUDiff shall work fine
- You may copy all text in the diff and paste it in a forum post (encapsulated by the code tags), if the diff is short enough. If it's not, then you'll have to save the diff to a .diff file and upload it somewhere and then link us to it.
-
If I understand correctly - you mean add:
} else {
adjust_base_res(base_res);
}
at line 1139?
Correct.
This is the one gauge (load_gauge_messages) that uses "default_position" - it's to deal with the magic number on line 4266
I see what you mean. (It's actually load_gauge_fixed_messages(), though.) Your code appears to handle this correctly.
- Right click on the /code/ folder or, if you have the code folder already open, right click in an empty area of the File Explorer.
- Select "TortoiseGit" from the menu, then "Diff" (which should be somewhere in the middle of the r-click menu)
-- A dialog should pop up showing a diff, or another one to inform you that you haven't chosen a program that will operate on Diff's, TortoiseUDiff shall work fine
- You may copy all text in the diff and paste it in a forum post (encapsulated by the code tags), if the diff is short enough. If it's not, then you'll have to save the diff to a .diff file and upload it somewhere and then link us to it.
Thanks, this worked! I'm used to TortoiseSVN, so I was trying to use "Create Patch Serial" to make the patch, but it appeared to do nothing. I searched the Internet and found that "Create Patch Serial" required you to commit your changes first (what's the point of making a patch if you've already committed your changes?). Other instructions I found either didn't work or required me to enter a name and e-mail address (why, TortoiseGit?). I would have never guessed to pick "Diff" because, in TortoiseSVN, this option just shows a side-by-side comparison.
I have no idea why the TortoiseGit team decided to deviate so much from the more intuitive way that TortoiseSVN works. I know that Git works differently from SVN and that TortoiseGit had to be adapted to that system, complete with its different terminology, but there's still no obvious reason that they couldn't have made the equivalent of "Create Patch" work the way it does in TortoiseSVN.
-
The method just described does exist in TortoiseSVN, so possibly they removed the other Create Patch method because it was superfluous, and to trim down the interface a little bit to keep it usable.
-
Thanks for the feedback, I'll add a new commit with those updates (done - see the pull request), then merge it all back into SVN.
... "Create Patch Serial" required you to commit your changes first (what's the point of making a patch if you've already committed your changes?).
That's one profound difference between svn & git (or other DVCS). When you commit, you're only committing to your local copy of the repository, not to a public repository. So it's quite common to commit a patch to a local branch, then send the diff of that patch off somewhere, either via email/forum post, or push it to a public repo and issue a pull request.
-
Yeah I've recently gotten the hang of using git format-patch and git am at work, since we have a couple repositories with restricted access. Make your commits locally, email/IM the patch, and someone with push rights applies and pushes the commits to our primary server.
-
Well there are a few questionable files that I see. Why do you have 3 data folders? You should only have "data" folder. I dunno why you have a CD.dll file and what that gfw_high does either. Google search indicates that it is something that comes with PlayonMac, which is used on a Mac, and yet you say it's not. I mean your specs are PC type. So why do you have PlayonMac files in that folder? I can only assume that there is something you're not telling us as the gfw_high file is the proof.
All of the files and folders that you're questioning here is normal for GOG.com installations. Gfw_high.ico is just an icon file for the desktop and start menu shortcuts, and data2, data3, and CD.dll exist so that the original CDs are not required. They have nothing to do with PlayonMac.
Ok, that clears that up. I'm just questioning his installation because he had that FS2 "ant" file which you said was an old version build. Makes me wonder if he has a mixture of old and new files in his installation. I even see .dmg files which are for Mac. It seems to me like the installation itself is borked. This is why I recommended starting from scratch again. Just follow my previous post.
Also I wanted him to do an OpenGL test with one of the programs I mentioned just to see if his system installation isn't causing issues with OpenGL.
Right now I'm wondering how he's configured his desktop primary monitor settings. Whichever is set to primary will be the one the game is run on, unless there's an option to handle multiple video cards in wxLauncher?
-
And it's committed :)
-
Woot!
-
Wiki new HUD.tbl thangs, plz?
Can't make use of them for custom HUDs if you don't document it somewhere.
-
So I've been playing around with this awesome stuff a little bit and I have a (hopefully small) request. I like the re-positioning of the hud based on the resolution, but I don't like the scaling of the hud elements. (I really like this, (http://lazymodders.fsmods.net/files/1920-2014mvps.jpg) this is ok, (http://lazymodders.fsmods.net/files/1920-1yarn-clean.jpg) but this I also really like. (http://lazymodders.fsmods.net/files/1920-yarn-mod.jpg)) I like them to be sharp, even if they are smaller in size. I know that's a sort of a personal preference, but maybe there could be an option in like a mod table or hud gauge table to stop the hud element scaling? So it would be like the base hud resolution is always the current window resolution.
(FYI The pic with the table mod was just done with the table in the first post but with the base res changed to (1440,900))
-
Wiki new HUD.tbl thangs, plz?
Can't make use of them for custom HUDs if you don't document it somewhere.
Done, should just be two new options, origin & offset.
-
On the subject of always having non-scaled/crystal-clear gauges, I think this could be achieved by having adjust_base_res() always set the base res to the current screen res (activated by a global hud_gauges.tbl option). My only question is, what side effects might this have? I need to do some tests with odd resolutions, but I'm not sure I can properly test a triple-head style setup.
Also, I was wondering about the situation where a modder specifies only one of Origin: / Offset: for a gauge (e.g. the cause of this ticket (http://scp.indiegames.us/mantis/view.php?id=2982)).
If only Origin is specified, I thought that it would make most sense to set the Offsets to 0 (I think this situation could be fairly common)
If only Offset is specified, I thought that it would make most sense to leave the Origins as their default values (I think this situation would be fairly uncommon)
Anyone got any thoughts / comments on these points?
-
niffiwan,
I'd be glad to do any triple monitor testing you need.
I use three old Dell FP2001 displays, each has a native resolution of 1600x1200. The 3X1 array, with bezel compensation has a resolution of 5076x1200.
I can change the resolution some, or even shut off the bezel compensation if needed.
-
On the subject of always having non-scaled/crystal-clear gauges, I think this could be achieved by having adjust_base_res() always set the base res to the current screen res (activated by a global hud_gauges.tbl option). My only question is, what side effects might this have? I need to do some tests with odd resolutions, but I'm not sure I can properly test a triple-head style setup.
Also, I was wondering about the situation where a modder specifies only one of Origin: / Offset: for a gauge (e.g. the cause of this ticket (http://scp.indiegames.us/mantis/view.php?id=2982)).
If only Origin is specified, I thought that it would make most sense to set the Offsets to 0 (I think this situation could be fairly common)
If only Offset is specified, I thought that it would make most sense to leave the Origins as their default values (I think this situation would be fairly uncommon)
Anyone got any thoughts / comments on these points?
Disclaimer: I haven't worked much with HUD modding in general
If I want to position for example the crosshair in the center of the screen, do I have to repeat the offsets every time I add it to my hud table? If I understand your proposal correctly specifying something for Origin will reset the preset offsets to 0 so I will have to specify them in the table for every hud gauge that should not have the top left corner as the origin.
Please correct me if I misunderstood something you said :nod:
-
Thanks you for that, I think I misunderstood the purpose of offsets. With my proposed change then yes, in order to specify a gauge via its centre position then you'd need to add the offsets manually for each gauge.
However, my original thought process, and the thought process of some others that I discussed this with on IRC was that you specify gauge positions based on the top left corner of the gauge, not the centre. And thus the confusion :) I guess that the fact that the Origin: values used in the original patch were 0.0, 0.5 & 1.0 added to my confusion, i.e. the offsets didn't seem to be used to provide the position of the top left of the gauge compared to the centre of the gauge.
So, what is easier for the modder? Lets use the 1024x768 FS2 centre reticle (gunsight/crosshairs) as an example.
Defaults coded into FSO:
+Center Reticle:
Origin: (0.5, 0.5)
Offset: (-19, -14)
Example one: move the reticle off centre / ~50 pixels to the left for an Ursa/Rhea like offset firing point, using current code
+Center Reticle:
Offset: (-19, -64)
(assume the modder knows what the default offset is)
Example two: same thing except specify the top left corner position of the gauge and assume the proposed change was added
+Center Reticle:
Origin: (0.487,0.370)
Example three: same as two, except without the proposed change
+Center Reticle:
Origin: (0.487,0.370)
Offset: (0, 0)
Note, I have not tried these using these examples in game.
Is it simply a case of being easier to specify position via centre (current code), or via top left (proposed code)?
It the best solution just knowledge/documentation? (with a better Assertion message?)
-
I guess it depends on the orientation of the gauge, Top Left works well for gauges that'll be in the top left area, Top Right works well for gauges that'll be in the top right area, and so on.
Reticles, crosshairs, and the like shouldn't need to be offset unless some weirdness with the sizing of the graphic comes into play. I believe these should default to center themselves, favoring the pixel top-left immediately close to the center if a center pixel cannot be calculated. However, I have seen some gun sights that use a post instead of the cross hair, so a center alignment on both the x and y axes would not make sense for these types, and the inverted post likewise.
Maybe if an alignment, or draw direction, was specified, modders could specify a custom gauge like so:
+Center Reticle:
Origin: (0.5, 0.5)
Alignment: (center, center)
+ETS Retail:
Origin: (0.99, 0.66)
Alignment: (right, center)
+Target Monitor:
Origin: (0.1, 0.66)
Alignment: (left, bottom)
What do you think about this?
-
Example two: same thing except specify the top left corner position of the gauge and assume the proposed change was added
+Center Reticle:
Origin: (0.487,0.370)
Example three: same as two, except without the proposed change
+Center Reticle:
Origin: (0.487,0.370)
Offset: (0, 0)
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.
-
Doh, I misunderstood something somewhere.
Origin is where on the screen the graphic is placed, Offset is the point on the graphic itself that is placed at the Origin. So, alignment is taken care of depending on where you put the offset.
Again, with the crosshair example. If the graphic is a 32x32, then:
+Center Reticle:
Origin: (0.5, 0.5)
Offset: (16, 16)
Having a negative offset would mean that the point that's set at the origin is not on the graphic itself, but off to the left and/or above.
-
You got Offset backwards. Offset specifies how many pixels to add to the point calculated from Origin. Positive numbers move the gauge down and right, while negative numbers move it up and left. It's certainly not "the point on the graphic itself that is placed at the Origin."
The origin is not quite "where on the screen the graphic is placed." Rather, it serves as an "anchor point" for determining how the gauge is positioned if the game's aspect ratio is different from that of the HUD; it can and usually does lie outside the gauge graphic. Also, many gauges in the default HUD share an origin so they aren't spread out more in wider or taller resolutions.
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.
-
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 (http://gameware.autodesk.com/scaleform) 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
-
yeahno we're not doing that :p
-
Vector graphics based UIs would be great. Would that even be feasible? Maybe with the upcoming change to SDL?
-
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.
-
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%
-
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.
-
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***
-
IIRC it's: "yourmod/data/tables"
-
...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.
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.
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.
-
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.
-
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:
#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
-
That just seems.... Overly complicated.
You said you have a simple switch to disable gauge stretching... Why can't we just have that?
-
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.
-
The patch to add in a per-gauge option to disable scaling is simple:
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)
-
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.
-
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?
-
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.
-
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 (http://pastebin.com/GZX6NyRD)
- 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 (http://www.mediafire.com/download/e73p96z8o8nzf6a/hud_scale_mod.zip) 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)
(https://www.mediafire.com/convkey/3b70/157tpj59fmhx96s4g.jpg) (http://www.mediafire.com/view/157tpj59fmhx96s/hud-1440x900-base-1440x900.png)
1024x768 (4:3 down-scaled & changed aspect)
(https://www.mediafire.com/convkey/d9b2/im1kw6lfwi37pm84g.jpg) (http://www.mediafire.com/view/im1kw6lfwi37pm8/hud-1024x768-base-1440x900.png) OLD VERSION (https://www.mediafire.com/convkey/bb6d/sus5p7oagxdacbb4g.jpg) (http://www.mediafire.com/view/sus5p7oagxdacbb/hud-1024x768-base-1440x900-old.png)
1280x1024 (5:4 up & down-scaled & changed aspect)
(https://www.mediafire.com/convkey/3f58/nw9034qo2s7zavk4g.jpg) (http://www.mediafire.com/view/nw9034qo2s7zavk/hud-1280x1024-base-1440x900.png) OLD VERSION (https://www.mediafire.com/convkey/6f47/21braw1j5yvd2cq4g.jpg) (http://www.mediafire.com/view/21braw1j5yvd2cq/hud-1280x1024-base-1440x900-old.png)
1600x900 (16:9 up-scaled & changed aspect)
(https://www.mediafire.com/convkey/063b/w7na17md1squcoa4g.jpg) (http://www.mediafire.com/view/w7na17md1squcoa/hud-1600x900-base-1440x900.png)
1680x1050 (16:10 up-scaled)
(https://www.mediafire.com/convkey/4221/zioyxqkg40xfz1c4g.jpg) (http://www.mediafire.com/view/zioyxqkg40xfz1c/hud-1680x1050-base-1440x900.png)
1680x480 (pseudo triple head, see Yarns comment about how Min/Max res table config currently works)
(https://www.mediafire.com/convkey/0b30/tzbefgrcutxpedv4g.jpg) (http://www.mediafire.com/view/tzbefgrcutxpedv/hud-1680x480-base-1440x900.png) OLD VERSION (https://www.mediafire.com/convkey/221e/jbuer0e167bp9zy4g.jpg) (http://www.mediafire.com/view/jbuer0e167bp9zy/hud-1680x480-base-1440x900-old.png)
3200x960 (another pseudo triple head)
(https://www.mediafire.com/convkey/c324/9o2mevh2kmpwj9d4g.jpg) (http://www.mediafire.com/view/9o2mevh2kmpwj9d/hud-3200x960-base-1440x900.png)
-
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:
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 (http://www.hard-light.net/forums/index.php?topic=84567.0). (I suggest looking at the other two as well.)
-
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:
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 (http://www.hard-light.net/forums/index.php?topic=84567.0). (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.
-
UPDATE: now committed; let me know if there are any issues and I'll clean them up pronto.
Right, I'm happy with all the "retail" screenshots (see below) and code (https://github.com/niffiwan/fs2open.github.com/commits/hud-scale). Scaling can be set in three places in the hud gauges table:
1) At the top - also sets whether "missing retail gauges" will scale or not
2) At the start of each specified resolution filter (will override the setting from the top)
3) At each individual gauge (will override settings at both the top of the file and in the relevant resolution filter.
Any further comments before I commit this? (I've left scaling ON by default for now, but it's easy to change the other way if desired)
Screenies (scaled on the left, not scaled on the right)
1024x768
(https://www.mediafire.com/convkey/f444/y6vz8a3ppcqd6w94g.jpg) (http://www.mediafire.com/view/y6vz8a3ppcqd6w9/hud-1024x768-base-retail-scale.png) (https://www.mediafire.com/convkey/19b5/ut983f4tb9hlhuz4g.jpg) (http://www.mediafire.com/view/ut983f4tb9hlhuz/hud-1024x768-base-retail-noscale.png)
1280x1024
(https://www.mediafire.com/convkey/fb1a/7999qbh1892tiwy4g.jpg) (http://www.mediafire.com/view/7999qbh1892tiwy/hud-1280x1024-base-retail-scale.png) (https://www.mediafire.com/convkey/2689/19xywcu8aggq9pa4g.jpg) (http://www.mediafire.com/view/19xywcu8aggq9pa/hud-1280x1024-base-retail-noscale.png)
1440x900
(https://www.mediafire.com/convkey/9b2e/3935iv3pujgv7ga4g.jpg) (http://www.mediafire.com/view/3935iv3pujgv7ga/hud-1440x900-base-retail-scale.png) (https://www.mediafire.com/convkey/f93b/54z26iyafrcghnr4g.jpg) (http://www.mediafire.com/view/54z26iyafrcghnr/hud-1440x900-base-retail-noscale.png)
1600x900
(https://www.mediafire.com/convkey/32f3/g7qqen1o4mu1khy4g.jpg) (http://www.mediafire.com/view/g7qqen1o4mu1khy/hud-1600x900-base-retail-scale.png) (https://www.mediafire.com/convkey/b92e/ip1m1r81xf615cf4g.jpg) (http://www.mediafire.com/view/ip1m1r81xf615cf/hud-1600x900-base-retail-noscale.png)
1680x1050
(https://www.mediafire.com/convkey/78eb/866z60l6dkwr3j84g.jpg) (http://www.mediafire.com/view/866z60l6dkwr3j8/hud-1680x1050-base-retail-scale.png) (https://www.mediafire.com/convkey/3a57/pmbsj40jhpvl45w4g.jpg) (http://www.mediafire.com/view/pmbsj40jhpvl45w/hud-1680x1050-base-retail-noscale.png)
1680x480
(https://www.mediafire.com/convkey/341c/v4yo1qe066sdccq4g.jpg) (http://www.mediafire.com/view/v4yo1qe066sdccq/hud-1680x480-base-retail-scale.png) (https://www.mediafire.com/convkey/bbc0/9z9ne9kr6zw6tn74g.jpg) (http://www.mediafire.com/view/9z9ne9kr6zw6tn7/hud-1680x480-base-retail-noscale.png)
3200x960
(https://www.mediafire.com/convkey/21e4/lm7u11bce1z9w2o4g.jpg) (http://www.mediafire.com/view/lm7u11bce1z9w2o/hud-3200x960-base-retail-scale.png) (https://www.mediafire.com/convkey/03d4/4c19dnmgdpikqqq4g.jpg) (http://www.mediafire.com/view/4c19dnmgdpikqqq/hud-3200x960-base-retail-noscale.png)
$Scale Gauges: no
-
It seems all right to me.
-
Thanks.
I've also just committed two minor tweaks:
1) ensure that origin & offset are used together
2) moved one of the $Scale Gauges options to avoid causing issues when both it & $Reticle Style are used.
Any comments are welcome.
(next up will be a review of the other trio of patches from Yarn)
-
Is current fs2_open_3_7_1_SSE2_Yarn.exe version compatible with MediaVPS2014?
They say exec version must be later than 1 of january
In other hand:
Can someone place an example of hud_gauges.tbl with the "$Scale Gauges: no" sentence to see exact placement and "ortography"
(excuse mi poor english and tk in advance)
-
Is current fs2_open_3_7_1_SSE2_Yarn.exe version compatible with MediaVPS2014?
They say exec version must be later than 1 of january
Current nightly builds should have the adaptable HUD code.
-
I searched through this thread but didn't find an answer to this: Is the scaling, origin, and offset compatible with RTT, such as on a cockpit display?
-
Can someone place an example of hud_gauges.tbl with the "$Scale Gauges: no" sentence to see exact placement and "ortography"
This should be all you need to get a retail Freespace 2 hud without scaling:
$Scale Gauges: no
#End
(yes, just two lines is all you should need, and it'll even work without the 2nd one :))
I searched through this thread but didn't find an answer to this: Is the scaling, origin, and offset compatible with RTT, such as on a cockpit display?
Sorry, I didn't actually test RTT with the new parameters. I didn't think Origin/Offset/Scaling were related to RTT but I didn't examine the code to make sure.
-
Hi again
I receive this error when addinh non scaling line...
hud_gauges.tbl(line 61):
Error: Missing required token: [#End]. Found [$Scale Gauges: no] instead.
KERNELBASE.dll! ReleaseMutex + 109 bytes
kernel32.dll! WaitForSingleObjectEx + 67 bytes
kernel32.dll! WaitForSingleObject + 18 bytes
fs2_open_3_7_1-20140104_r10277.exe! <no symbol>
fs2_open_3_7_1-20140104_r10277.exe! <no symbol>
can someone help?
-
Are you using the most recent nightly build? http://www.hard-light.net/forums/index.php?topic=86488.0
-
fs2_open_3_7_1-20140104_r10277.exe
Certainly looks like it.
-
Yup, near the last
I think that's not poblem reason...
-
Can you post your HUD table?
-
#Gauge Config
$Base: (1280, 640)
$Min: (1280, 640)
$Gauges:
+Messages:
Origin: (0.34, 0.0)
Offset: (8, 5)
+Wingman Status:
Origin: (0.66, 0.0)
Offset: (-92, 144)
+Auto Speed:
Origin: (0.66, 1.0)
Offset: (-64, -96)
+Auto Target:
Origin: (0.66, 1.0)
Offset: (-64, -120)
+Countermeasures:
Origin: (0.66, 1.0)
Offset: (-144, -166)
+Talking Head:
Origin: (0.34, 0.0)
Offset: (5, 56)
+Directives:
Origin: (0.34, 0.5)
Offset: (5, -106)
+Weapons:
Origin: (0.66, 1.0)
Offset: (-144, -257)
+Squad Message:
Origin: (0.66, 0.0)
Offset: (-197, 5)
+Escort View:
Origin: (0.66, 0.5)
Offset: (-159, -54)
+Mission Time:
Origin: (0.66, 1.0)
Offset: (-55, -52)
+Target Monitor:
Origin: (0.34, 1.0)
Offset: (5, -178)
+Extra Target Data:
Origin: (0.34, 1.0)
Offset: (5, -216)
+Multiplayer Messages:
Origin: (0.34, 0.5)
Offset: (8, -144)
+Voice Status:
Origin: (0.34, 0.5)
Offset: (8, -129)
+Ping:
Origin: (0.66, 0.0)
Offset: (-128, 5)
+Kills:
Origin: (0.66, 1.0)
Offset: (-144, -144)
+Fixed Messages:
+ETS Retail:
Origin: (0.66, 1.0)
Offset: (-144, -120)
$End Gauges
#End
-
mi real res is 3840x1024
-
Does that mean you're trying to put it after "$End Gauges"?
-
fs2_open_3_7_1-20140104_r10277.exe
Certainly looks like it.
Oh derp! :banghead:
For that table, add it on the line before: "#Gauge Config"
$Scale Gauges: no
#Gauge Config
$Base: (1280, 640)
$Min: (1280, 640)
$Gauges:
+Messages:
Origin: (0.34, 0.0)
Offset: (8, 5)
(etc)
-
Now is working
Ty very much
-
Complete Newb Questions so I apologize in advace. I am trying to play Blue Planet but I would like to use Yarn's adaptable Hud as I really like the look of it in the Freespace 2 campaign. Originally it looks like their was a Blue Planet Build that had that hud in the original post but it is not crossed out and can't be accessed. Is there a BP build that uses the adaptable hud? Any help is greatly appreciated. Thanks
-
Even if there is, I'm not sure it's a good idea. BP adds a ton of custom hud gauges, and I'd have to ask a coder how well those are supported. (A coder will probably be by shortly to tell us!)
e: You can always install the BP Compatibility Package and then play on a recent nightly build. That should have the adaptable HUD stuff.
-
Even if there is, I'm not sure it's a good idea. BP adds a ton of custom hud gauges, and I'd have to ask a coder how well those are supported. (A coder will probably be by shortly to tell us!)
Custom gauges should be fully supported with the new adaptable hud code. The only caveat being that depending on the hud table config, the new code may not be used (and I would guess that the current BP HUD would be like this since it pre-dates the adaptable HUD)
e: You can always install the BP Compatibility Package and then play on a recent nightly build. That should have the adaptable HUD stuff.
Yeah - I've done this a few times and it works just fine, but I haven't been examining the HUD in detail to look for differences created by the new HUD code.
-
Thanks for the advice. I really appreciate it. I'll try the compatibility patch and the nightly build and see if it works. Thanks for the suggestion. I just got into this (I owned retail Freespace 2 when it first came out) and I am just amazed at what this team of people have out together given the age of the original engine.
Thanks again
-
Actually, Yarn's HUD patches should be in the most recent BP build as well.
-
Actually, Yarn's HUD patches should be in the most recent BP build as well.
Looks like they are not.
-
Actually, Yarn's HUD patches should be in the most recent BP build as well.
Looks like they are not.
D'oh, for some reason I thought the last BP build was rev 10280, but that's the build Diaspora 1.1 is using.
-
Yeah. The compatibility patch worked for Blue Planet 1....at the cost of some of the lighting effects. It doesn't work on Blue Planet 2 because I think they use their own hud tables because of the cockpit views that it uses (This is my first real experience with working with any modded software so I hope any of that made sense.)
Thanks for the suggestions.
-
Hi all
Is there a mod or a way to get a widescreen mainhall image?
-
Unfortunately not, implementing support for that is still on the coding TODO list.
-
I always meant to toy with some animorphic trickery... but I didn't want to re-render everything.
-
Couldn't you just take the current already-rendered images, vert-minus (or letterbox) them and stretch/compress them in such a way so that when the 4:3->16:9 conversion happens, you get proper aspect ratio? Your pixel aspect ratio will be off by a lot, but that doesn't matter as much.
You'd also have to redraw/reposition the animations, so maybe not.
-
Well, I could crop the current 4:3 mainhalls, but you'd lose a lot of the scene that was designed to be visible. (AKA: either the barrels, or Barracks Door in Galatea... or both)
But then yes.. I'd have to figure out the width compression ratio and apply that to all the animations as well. Then I'd have to re-position them all again. It'd be complicated and who knows if it would really be worth it. I honestly don't mind them being stretched to 16:10.. the worst part of it is that the people look like midgets. (Depending on how you view the FS universe, that could be what the people are actually like, too! :p )
-
Well, I could crop the current 4:3 mainhalls, but you'd lose a lot of the scene that was designed to be visible. (AKA: either the barrels, or Barracks Door in Galatea... or both)
But then yes.. I'd have to figure out the width compression ratio and apply that to all the animations as well. Then I'd have to re-position them all again. It'd be complicated and who knows if it would really be worth it. I honestly don't mind them being stretched to 16:10.. the worst part of it is that the people look like midgets. (Depending on how you view the FS universe, that could be what the people are actually like, too! :p )
It is way better not to crop, but to add margins to left | right to fix aspect ratio by compressing background horizontally. Anyway it definetly will require alot of calculations to place all the elements (however it could be done by excel or something similar). And calcualtion will be different for 16:10 or 16:9. Hell.
But content compatibility-wise it would be nice to solve it by overhauling rendering. But...
May be it doable to switch resolution between 1024X768 and 1920x1080 (for example) when launching a mission ?
-
It would be simpler to just render the retail interface with black borders or stretched to fit vertically.
-
It would be simpler to just render the retail interface with black borders or stretched to fit vertically.
That's exactly what I meant. Perfect solution. Render the retail interface with black horizontal borders , stretched to fit vertically.
:yes:
Volunteers? :)
-
+1 for black borders left and right for menus. Or maybe just fill those spaces with Freespace themed art. You know, like Duke Nukem 3d on Xbox 360 (http://www.mobygames.com/images/shots/l/406360-duke-nukem-3d-xbox-360-screenshot-you-can-toggle-the-sidebar.jpg). It might not be the ideal longtime solution, but it's still million times better than the current stretched menu.
Speaking of widescreens, could someone respond to my topic (http://www.hard-light.net/forums/index.php?topic=86665.0) regarding the in-game field of view? Thanks in advance :)
-
(however it could be done by excel or something similar). And calcualtion will be different for 16:10 or 16:9. Hell.
Not easily and nope. If the system works as it works now, and if everything was setup correctly the coords would not need to be different for different ratios. Otherwise the current mainhalls would be stretched with inaccurate coords already.
It would be simpler to just render the retail interface with black borders or stretched to fit vertically.
Honestly, I'd rather have stretching than vertical bars... but that's just me.
-
Honestly, I'd rather have stretching than vertical bars... but that's just me.
Are you sure? Take a look on illustration:
http://www.hard-light.net/forums/index.php?topic=86617.0
If there are people in scene, it looks even worse streched.
And remember nice BP wallpapers, streched circles to ovals :nono:
-
Yes I'm sure.
-
There is no reason why this can't be implemented in a way that can be controlled by the user.
-
So as a multimonitor user I've been looking for some time for a working hud_gauges.tbl to move the hud elements to the center screen. There's a position based table posted a few pages back but it has a few flaws, most notably the missile lock circle is erratic and getting a lock is significantly more difficult. The gauge positions also aren't correct. So I used the origin-offset stock table file in the first post and altered it for multimonitor use.
It was a lot more simple than I thought it would be. So kudos to the dev for it. Two simple replace commands is all it took "(0.0" -> "(0.333" and "(1.0" -> "(0.666" Also I changed the base res to 1920,1080. I found using 5760,1080 caused the erratic missile lock circle. Lower resolutions can be used to scale the UI.
EDIT: I spoke too soon about the missile lock. It's still an issue. The indicator's movement is very exaggerated horizontally. It makes lock difficult. Flying a bomber is almost impossible due to the slow lock time of the heavy weapons. Is there anyway to compensate for this? I can upload a video if that helps.
(http://i.imgur.com/8QXV1Dn.jpg)
#Gauge Config
$Base: (1920, 1080)
$Min: (1024, 600)
$Gauges:
+Messages:
Origin: (0.333, 0.0)
Offset: (8, 5)
+Training Messages:
Origin: (0.5, 0.5)
Offset: (-133, -259)
+Support:
Origin: (0.5, 0.5)
Offset: (-53, 150)
+Damage:
Origin: (0.5, 0.0)
Offset: (-72, 61)
+Wingman Status:
Origin: (0.666, 0.0)
Offset: (-92, 144)
+Auto Speed:
Origin: (0.666, 1.0)
Offset: (-64, -96)
+Auto Target:
Origin: (0.666, 1.0)
Offset: (-64, -120)
+Countermeasures:
Origin: (0.666, 1.0)
Offset: (-144, -166)
+Talking Head:
Origin: (0.333, 0.0)
Offset: (5, 56)
+Directives:
Origin: (0.333, 0.5)
Offset: (5, -106)
+Weapons:
Origin: (0.666, 1.0)
Offset: (-144, -257)
+Objective Notify:
Origin: (0.5, 0.5)
Offset: (-76, -200)
+Squad Message:
Origin: (0.666, 0.0)
Offset: (-197, 5)
+Lag:
Origin: (0.5, 0.5)
Offset: (115, 145)
+Mini Target Shields:
Origin: (0.5, 0.5)
Offset: (-15, 86)
+Player Shields:
Origin: (0.5, 1.0)
Offset: (112, -98)
+Target Shields:
Origin: (0.5, 1.0)
Offset: (-220, -98)
+Escort View:
Origin: (0.666, 0.5)
Offset: (-159, -54)
+Mission Time:
Origin: (0.666, 1.0)
Offset: (-55, -52)
+Target Monitor:
Origin: (0.333, 1.0)
Offset: (5, -178)
+Extra Target Data:
Origin: (0.333, 1.0)
Offset: (5, -216)
+Radar:
Origin: (0.5, 1.0)
Offset: (-101, -178)
+Afterburner Energy:
Origin: (0.5, 0.5)
Offset: (-238, 40)
+Weapon Energy:
Origin: (0.5, 0.5)
Offset: (154, 40)
+Text Warnings:
Origin: (0.5, 0.5)
Offset: (0, -109)
+Center Reticle:
Origin: (0.5, 0.5)
Offset: (-19, -14)
+Throttle:
Origin: (0.5, 0.5)
Offset: (-166, -115)
+Threat Indicator:
Origin: (0.5, 0.5)
Offset: (62, -115)
+Lead Indicator:
+Lock Indicator:
+Multiplayer Messages:
Origin: (0.333, 0.5)
Offset: (8, -144)
+Voice Status:
Origin: (0.333, 0.5)
Offset: (8, -129)
+Ping:
Origin: (0.666, 0.0)
Offset: (-128, 5)
+Supernova:
Origin: (0.5, 0.5)
Offset: (-342, -214)
+Offscreen Indicator:
+Target Brackets:
+Orientation Tee:
Origin: (0.5, 0.5)
Offset: (0, 3)
+Hostile Triangle:
Origin: (0.5, 0.5)
Offset: (0, 3)
+Target Triangle:
Origin: (0.5, 0.5)
Offset: (0, 3)
+Missile Triangles:
Origin: (0.5, 0.5)
Offset: (0, 3)
+Kills:
Origin: (0.666, 1.0)
Offset: (-144, -144)
+Fixed Messages:
+ETS Retail:
Origin: (0.666, 1.0)
Offset: (-144, -120)
$End Gauges
#End
-
EDIT: I spoke too soon about the missile lock. It's still an issue. The indicator's movement is very exaggerated horizontally. It makes lock difficult. Flying a bomber is almost impossible due to the slow lock time of the heavy weapons. Is there anyway to compensate for this? I can upload a video if that helps.
It sounds like the lock gauge movement scaling needs some work. A video would help, i.e. to see exactly when & what the erratic movement is, when locking, when losing a lock, etc.
-
Hello, I have a few newb questions. :confused:
I'm using fs2_open_3_7_2_RC4.exe and a 1920x1080 display.
1. Why is the HUD so small in 1920x1080 resolution?
2. Can I make it bigger again?
Thank you for your time.
-
1) It's small because the mod you're using has set the gauges to not scale up. This is to avoid fuzzy looking gauges.
2) Yes, but it's not super simple. Can you advise which mod you're using as the fix will probably be mod dependent.
-
The problem seems to be exclusive to the combination of 3.7.2 RC4 with MediaVPs_2014.
Curiously, the problem is not present when I'm using MediaVPs_3612 (with 3.7.2 RC4!) or any other mod as far as I can tell.
Is there some kind of flag or piece of code that controls the scaling? Can you tell me where to find it?
I tried playing MediaVPs_2014 with fs2_open_3_7_0.exe... but all I get is this error:
ERANGE: String error. Please Report.
Trying to put into 32 byte buffer:
ÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌ.
ntdll.dll! ZwWaitForSingleObject + 21 bytes
kernel32.dll! WaitForSingleObjectEx + 67 bytes
kernel32.dll! WaitForSingleObject + 18 bytes
fs2_open_3_7_0-DEBUG.exe! SCP_DumpStack + 354 bytes
fs2_open_3_7_0-DEBUG.exe! Error + 229 bytes
fs2_open_3_7_0-DEBUG.exe! scp_strcpy_s + 297 bytes
fs2_open_3_7_0-DEBUG.exe! scp_strcpy_s<32> + 53 bytes
fs2_open_3_7_0-DEBUG.exe! cf_search_root_pack + 873 bytes
fs2_open_3_7_0-DEBUG.exe! cf_build_file_list + 131 bytes
fs2_open_3_7_0-DEBUG.exe! cf_build_secondary_filelist + 166 bytes
fs2_open_3_7_0-DEBUG.exe! cfile_init + 398 bytes
fs2_open_3_7_0-DEBUG.exe! game_init + 291 bytes
fs2_open_3_7_0-DEBUG.exe! game_main + 519 bytes
fs2_open_3_7_0-DEBUG.exe! WinMain + 330 bytes
fs2_open_3_7_0-DEBUG.exe! __tmainCRTStartup + 358 bytes
fs2_open_3_7_0-DEBUG.exe! WinMainCRTStartup + 15 bytes
kernel32.dll! BaseThreadInitThunk + 18 bytes
ntdll.dll! RtlInitializeExceptionChain + 99 bytes
ntdll.dll! RtlInitializeExceptionChain + 54 bytes
-
I tried playing MediaVPs_2014 with fs2_open_3_7_0.exe... but all I get is this error:
First, the 2014 MediaVPs won't work with 3.7.0. Secondly, that error means that 3.7.0 won't work in a file path that long.
As niffiwan already said:
It's small because the mod you're using has set the gauges to not scale up.
The 2014 MediaVPs have a very simple mv_root-hdg.tbm, containing only 6 lines, of which 2 are blank and one is a comment, leaving only 3 actually parsed by the engine:
$Max Directives: 8
$Max Escort Ships: 13
$Scale Gauges: no
That last one is the one that is causing the HUD to be small. You can create your own *-hdg.tbm with a single line saying:
$Scale Gauges: yes
If you stick it in your /mediavps_2014/data/tables/ folder (which you will probably have to create), it will make the HUD scale without changing anything else. See the attached file for an example of such a modular table.
[attachment kidnapped by pirates]
-
@AdmiralRalwood Thank you very much, that worked like a charm. :yes:
-
I just noticed that in BtA the target brackets around talking ships aren't present. It works in retail still (and MediaVPs2014, but they don't really have a fully hud_gauges.tbl), so it's definitely mod specific. I'm guessing it's something in hud_gauges.tbl that I didn't include? Any chance someone can point me in the right direction?
EDIT: I figured it out. If you've specified a 'Dot Filename:' under '+Target Brackets:' then the message brackets won't be drawn. This is a bug, so I'm putting it on Mantis.
EDIT 2: Except I couldn't reproduce on retail... hrm... Well at least I fixed it in my mod.
I dunno what's going on.. more testing required.
EDIT FINAL: Turns out it's not hud_gauges at all!