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

0 Members and 1 Guest are viewing this topic.

Offline Yarn

  • 210
Re: Adaptable HUD, a.k.a. No more HUD stretching, for real this time (with patch!)
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.
"Your fighter is running out of oil.  Please check under the hood and add more if necessary"
--strings.tbl, entry 177

"Freespace is very tired.  It is shutting down to get some rest."
--strings.tbl, entry 178

 

Offline Swifty

  • 210
  • I reject your fantasy & substitute my own
Re: Adaptable HUD, a.k.a. No more HUD stretching, for real this time (with patch!)
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.

Quote
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.
« Last Edit: April 22, 2013, 05:14:35 pm by Swifty »

 

Offline Yarn

  • 210
Re: Adaptable HUD, a.k.a. No more HUD stretching, for real this time (with patch!)
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.

Quote
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.
"Your fighter is running out of oil.  Please check under the hood and add more if necessary"
--strings.tbl, entry 177

"Freespace is very tired.  It is shutting down to get some rest."
--strings.tbl, entry 178

 

Offline chief1983

  • Still lacks a custom title
  • Moderator
  • 212
  • ⬇️⬆️⬅️⬅️🅰➡️⬇️
    • Minecraft
    • Skype
    • Steam
    • Twitter
    • Fate of the Galaxy
Re: Adaptable HUD, a.k.a. No more HUD stretching, for real this time (with patch!)
There has been work done on an in-game expanded user settings interface.  It might not be as far off as one would fear.
Fate of the Galaxy - Now Hiring!  Apply within | Diaspora | SCP Home | Collada Importer for PCS2
Karajorma's 'How to report bugs' | Mantis
#freespace | #scp-swc | #diaspora | #SCP | #hard-light on EsperNet

"You may not sell or otherwise commercially exploit the source or things you created based on the source." -- Excerpt from FSO license, for reference

Nuclear1:  Jesus Christ zack you're a little too hamyurger for HLP right now...
iamzack:  i dont have hamynerge i just want ptatoc hips D:
redsniper:  Platonic hips?!
iamzack:  lays

 

Offline Swifty

  • 210
  • I reject your fantasy & substitute my own
Re: Adaptable HUD, a.k.a. No more HUD stretching, for real this time (with patch!)
Who is working on that and where can I keep track of the progress? :O

 

Offline Yarn

  • 210
Re: Adaptable HUD, a.k.a. No more HUD stretching, for real this time (with patch!)
I updated the patch and the builds again to remove the -nohudscaling flag and make a few other minor improvements.
"Your fighter is running out of oil.  Please check under the hood and add more if necessary"
--strings.tbl, entry 177

"Freespace is very tired.  It is shutting down to get some rest."
--strings.tbl, entry 178

 

Offline Nuke

  • Ka-Boom!
  • 212
  • Mutants Worship Me
Re: Adaptable HUD, a.k.a. No more HUD stretching, for real this time (with patch!)
i 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 can no longer sit back and allow communist infiltration, communist indoctrination, communist subversion, and the international communist conspiracy to sap and impurify all of our precious bodily fluids.

Nuke's Scripting SVN

 

Offline Yarn

  • 210
Re: Adaptable HUD, a.k.a. No more HUD stretching, for real this time (with patch!)
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.
"Your fighter is running out of oil.  Please check under the hood and add more if necessary"
--strings.tbl, entry 177

"Freespace is very tired.  It is shutting down to get some rest."
--strings.tbl, entry 178

 
Re: Adaptable HUD, a.k.a. No more HUD stretching, for real this time (with patch!)
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.

 

Offline Yarn

  • 210
Re: Adaptable HUD, a.k.a. No more HUD stretching, for real this time (with patch!)
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 (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.
"Your fighter is running out of oil.  Please check under the hood and add more if necessary"
--strings.tbl, entry 177

"Freespace is very tired.  It is shutting down to get some rest."
--strings.tbl, entry 178

 

Offline Backslash

  • 29
  • Bring Our Might To Bear
Re: Adaptable HUD, a.k.a. No more HUD stretching, for real this time (with patch!)
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.

 
Re: Adaptable HUD, a.k.a. No more HUD stretching, for real this time (with patch!)
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]

 

Offline Yarn

  • 210
Re: Adaptable HUD, a.k.a. No more HUD stretching, for real this time (with patch!)
It's good that you were able to get it working.

However, you are missing the update for MV_Effects. Get it here.
"Your fighter is running out of oil.  Please check under the hood and add more if necessary"
--strings.tbl, entry 177

"Freespace is very tired.  It is shutting down to get some rest."
--strings.tbl, entry 178

 
Re: Adaptable HUD, a.k.a. No more HUD stretching, for real this time (with patch!)
Oops >_<. Downloaded it but forgot to install it. Thanks for the heads up, I didn't notice.

 
Re: Adaptable HUD, a.k.a. No more HUD stretching, for real this time (with patch!)
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)

 

Offline Yarn

  • 210
Re: Adaptable HUD, a.k.a. No more HUD stretching, for real this time (with patch!)
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:
Code: [Select]
$Reticle Style: FS1
$Max Escort Ships: 9
"Your fighter is running out of oil.  Please check under the hood and add more if necessary"
--strings.tbl, entry 177

"Freespace is very tired.  It is shutting down to get some rest."
--strings.tbl, entry 178

 
Re: Adaptable HUD, a.k.a. No more HUD stretching, for real this time (with patch!)
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

 
Re: Adaptable HUD, a.k.a. No more HUD stretching, for real this time (with patch!)
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

 

Offline niffiwan

  • 211
  • Eluder Class
Re: Adaptable HUD, a.k.a. No more HUD stretching, for real this time (with patch!)
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 :)
Creating a fs2_open.log | Red Alert Bug = Hex Edit | MediaVPs 2014: Bigger HUD gauges | 32bit libs for 64bit Ubuntu
----
Debian Packages (testing/unstable): Freespace2 | wxLauncher
----
m|m: I think I'm suffering from Stockholm syndrome. Bmpman is starting to make sense and it's actually written reasonably well...

 
Re: Adaptable HUD, a.k.a. No more HUD stretching, for real this time (with patch!)
ty for quick answering

theres a easy way to place lod1 at target window?