Based off of Rev 6354. Sample HUD data with an exhaustive list of options per gauge inside Hud_Gauges.tbl. Download (http://www.mediafire.com/?4558ja4742g53n5)

Code has been committed to svn://svn.icculus.org/fs2open/branches/swifty

A screencast (http://www.youtube.com/watch?v=cqO7_ahyS4Q) on my Youtube channel showing an overview. Just for fun.

EDIT: Make sure you guys turn on all the HUD gauges in the HUD Options Menu. I know that FSO by default sets Squad Messages and Text Warnings off; originally FSO would just display them regardless of they were off or not but my code, for better or worse, does not make any such discrimination.

More sample HUD layouts that look way better than the examples in my build package:

#Gauge Config(HUD layout information goes here)#EndYou can define a HUD layout configuration for a specific ship or for the default configuration. The default configuration is the HUD layout which will be used for any ships that do not have its own layout. Ship specific gauge layouts will have "$Ship:" defined while non-specific layouts do not.

Each #Gauge Config will have a Base resolution. This resolution is the scale in which the corresponding HUD layout will be drawn regardless of the actual resolution. This is similar to how Freespace Open draws the HUD at a 640x480 or 1024x768 scale regardless of the resolution and aspect ratio. This scale is defined using the "$Base:" field.

#Gauge Config$Base: (1440, 900)$Gauges(List desired gauges here)$End Gauges#EndYou can restrict a given HUD layout to be used for specific resolutions and/or aspect ratios. The "$Required Aspect:" field will limit a HUD configuration for use for a specified aspect ratio. The "$Min:" field will set a minimum resolution. "$Max:" will set a maximum.

The following example will restrict this particular HUD gauge layout, that will be drawn in 1440x900 resolution, for use for in wide screen resolutions that are greater than 1280x719 and less than 1680x1051. Since this example does not have the "$Ship" field, it will be used for the default configuration.

#Gauge Config$Base: (1440, 900)$Required Aspect: Wide Screen ;Can be "Wide Screen" or "Full Screen" ATM$Min: (1280, 719)$Max: (1680, 1051)$Gauges(List desired gauges here)$End Gauges#EndAny desired gauges are encapsulated within $Gauges and $End Gauges. Each gauge is followed by a set of coordinates representing the desired screen position. Setting "default" instead of an ordered pair will set the HUD gauge to draw with it's original retail coordinates and scale (640x480 or 1024x768)

Right, here are the results of a bit of experimentation by me. This is optimized for 1440x900, just like Swifty's example tbl.

Screenies:(http://blueplanet.fsmods.net/E/screen0207.png)(http://blueplanet.fsmods.net/E/screen0208.png)Please ignore the crap that's displayed on the radar. Some custom radar images are broken, seemingly.

Also, here's the custom reticle: http://blueplanet.fsmods.net/E/2_reticle1.aniIf you want to use the retail one, you'll need to adjust the reticle coordinates to the same values used in Swifty's example tbl.

$Load Retail Configuration: No; If set to Yes, FSO will load any missing gauges necessary to complete the FS1/FS2 retail configuration. ; If field is not present, FSO will default this to Yes.;$Max Escort Ships:

One thing that should be fixed for the Wing display is that it needs a customizable direction to expand in. At the moment, new wings after Alpha are added to the left of Alpha, which a) looks weird and b) causes the gauge to expand in the wrong direction (at least for the custom layout I posted here).

Second, the interaction between the hud_gauges.tbl and the -orbradar commandline flag needs to be fixed. At the moment, if you have -orbradar enabled, but not defined any coordinates for it, the HUD will fall back to the standard radar (albeit without telling anyone about this). If both Orbradar and standard radar have coordinates defined and -orbradar is enabled, the game will, again, fall back to the standard radar (which, at least to me, sounds like unwanted behaviour).In other words, to get the orbradar working, you need to comment out the normal Radar gauge from the tbl, which is not that user-friendly, IMHO.

$Load Retail Configuration: No; If set to Yes, FSO will load any missing gauges necessary to complete the FS1/FS2 retail configuration. ; If field is not present, FSO will default this to Yes.;$Max Escort Ships:

Using extension "GL_EXT_fog_coord". Using extension "GL_ARB_multitexture". Using extension "GL_ARB_texture_env_add". Using extension "GL_ARB_texture_compression". Using extension "GL_EXT_texture_compression_s3tc". Using extension "GL_EXT_texture_filter_anisotropic". Using extension "GL_ARB_texture_env_combine". Using extension "GL_EXT_compiled_vertex_array". Using extension "GL_EXT_draw_range_elements". Using extension "GL_ARB_texture_mirrored_repeat". Using extension "GL_ARB_texture_non_power_of_two". Using extension "GL_ARB_vertex_buffer_object". Using extension "GL_ARB_pixel_buffer_object". Using extension "GL_SGIS_generate_mipmap". Using extension "GL_EXT_framebuffer_object". Using extension "GL_ARB_texture_rectangle". Using extension "GL_EXT_bgra". Using extension "GL_ARB_texture_cube_map". Using extension "GL_EXT_texture_lod_bias". Using extension "GL_ARB_point_sprite". Using extension "GL_ARB_shading_language_100". Using extension "GL_ARB_shader_objects". Using extension "GL_ARB_vertex_shader". Using extension "GL_ARB_fragment_shader". Unable to find extension "GL_ATI_shader_texture_lod". Found special extension function "wglSwapIntervalEXT".

Well Galemp, I can only hope that the default retail layout is in the code itself for when the table isn't present. Although it may not be optimized for non-4:3 in that case, I'm not sure how that works.

Well Galemp, I can only hope that the default retail layout is in the code itself for when the table isn't present. Although it may not be optimized for non-4:3 in that case, I'm not sure how that works.

Yes, without the tbl, you get the standard stretched layout from before.

Is that possible to assign HUD ani files on a per ship basis?I mean, being able to give, for example, a BTRL HUD gauges to Ulysses, while the rest of ships would retain standard layout? Or have custom HUDs for Vasudans and Shivans?

Is that possible to assign HUD ani files on a per ship basis?I mean, being able to give, for example, a BTRL HUD gauges to Ulysses, while the rest of ships would retain standard layout? Or have custom HUDs for Vasudans and Shivans?

Yup, the code can handle that. It's just a matter of exposing that functionality in hud_gauges.tbl. The position field is only supported right now since I wanted to push out a test build quickly.

Quote

I think that's the general idea, yes... but first we need a default hud layout table so we can manipulate it, instead of having to guess.

You could just load up Freespace in 1024x768, take a screenshot, and count pixels ;)

I'll post an example table with the default values when I find the time.

disable-hud and disable-hud-except-messages work a little differently ingame (and in code too I hear). You can reverse the effects of disable-hud by just going Shift-o. However with disable-hud-except-messages, that doesn't work. It basically locks your hud off.

I humbly ask for a way to lock disable-hud like except-messages does (now I know with the way except-messages works, its more unintentional, but the end result is the same).

Here's an update to my previous custom layout. Note that again, you need to use my custom reticle or adjust the reticle coordinates for the retail one ( that is, (700, 438) ). Also note that due to some bugs and missing features in Swifty's released build, the escort list won't work as planned.

Either that, or instead of having a bunch of hardcoded tables, we just release a separate configs pack that could exist in the root directory without being a problem, kinda like the multiplayer mission pack or the cutscenes. Or could that end up being a headache?

That's an issue with the retail data. However, you can now create more accurate reticles. Also, since the error is exaggerated by the standard scaling, using the adapted tbls makes it less of an issue.

Hm mm I'm lost with mathematics i guess, any help would be great :here is what i m trying to do :Having the HUD centered in the center screen in a triplehead resolution (3840*1024 in my case)wich is basically 3* 1280*1024i've worked with the default position given in the topic for the default hud so i started with that :3840/1024= 3.75 (ratio between my x resolution and the default one)Now i ve multiply all x position in the hud_gauge.tbl by the value, but it's not centered at all, i guess my method is really wrong.

to be clear here is what i m looking to do : [ ] [X] [ ] (where brackets are screens and x the hud)

About the reticles and the rest of the table, adding a value ( i know it was commented as not necessary) does not affect its position, i've try many value and it doesn't move, and it's not centered at all.

ah and hurrah for swifty that was the last annoying thing when playing triplehead with fs2open (now it just lack the main hall non stretch support to be full support! )

And yes I've start with the 1024*768 resolution as a base (as i don't have the 1280*1024 default value, i should find a way to mathematical convert it to 1280*1024For the reticule I've set it manually to 1920,512 (3840/2 to get the x center of the screens and 1024/2 to get the y center)But it have no effect, the reticule doesn't seems to want to move.

If you start at a 3*1024x768 resolution, it should scale up to your 3*1280x1024 resolution nicely shouldn't it? I thought the whole point was that you shouldn't need to do the math. Get one table with the right aspect ratio and it should scale to yours fine.

yup, the e : you were right for the reticle it's well aligned now! it looks already better!

chief 1983 : no, it does not stretch up, the hud is not using the whole center screen (he"s up and left centered in fact)So if i want to fix this i have to find the formula to convert 1024*768 to 1280*1024 scale and then add 1280 to the x things

I mean you used numbers designed for a 1024x768 base and then set them to a 1280x1024 base. Of course it's going to be up and to the left. If you specify the base though as a 1024x768 base, and then give it a max res of a 1280x1024 base, it should scale up fine.

$End Gauges#EndTo transform this into 3840x1024, with the hud centered on the middle screen, multiply all x values by 1.25, and add 1280. To get the y values, just multiply them by 1.33, rounding as appropriate.

Oh no p)roblem i've played during two years with the stretched hud, so when i saw your post.... :cool:Now the last thing before we get the 5 star on 5 on the widescreengaming forum is to change the way the main hall behave (ie is not stretched like the old hud was)

And if someone provide me the formula to make a 3*16/10 (1680*1050) hud i'll give you the table that correspond to it (unfortunatly i won t be able to try it)

1) that's kinda ugly and you need time to pass through that2) more important : the reticle is so large that you can"t shoot anything with precision when using primary...3) have to turn off the hud before taking screenshot if not, many will post and trolls about triplehead :nervous:

The fading effect doesn't appear to be present on the grey message brackets.

This, and another: how are we supposed to customize the actual ANI files used? Suppose I wanted the FS1-style HUD in the Ulysses, Herc Mk 1, Loki, Zeus, Medusa, and Ursa; how would I specify the ANIs to use?

Swifty, as a quick fix, would it be easy to add a config to specify what portion of the screen to fill with the interface? Then 16x9 or 16x10 configs could just put it in the middle and not stretch it full width, and especially this 3*4x3 setup :)

This seems kind of odd to me... why create one set of component coordinates for each res, rather than using relative positions to specify where things go? That seems like it's really the way it ought to be done (IMHO).

This seems kind of odd to me... why create one set of component coordinates for each res, rather than using relative positions to specify where things go? That seems like it's really the way it ought to be done (IMHO).

In order to use relative positions effectively, you need definitive dimensions for all gauges to be able to place them relative to their centers, top-left, bottom-left, top-right, or bottom-right corners relative to whatever anchors on-screen (the corners or center).

Since FSO doesn't have definitive width and height data for all gauges (Directives, escort, weapons, messaging, etc), I figured the more effective way would be to just to give people more control over the HUD scaling when deciding top-left position.

And really, this isn't odd. Along with relative positioning, a lot of games these days define interface data for three key resolutions (480p, 720p, 1080p) and interpolate for resolutions in between.

Isn't the interface rendered in a resolution independent of your game's resolution anyway?

If that's the case, then it makes sense for everything to be positioned absolutely according to 1600x900 or whatever. After all, I don't think you'd want shrinking/expanding HUD elements depending on what resolution you're using. I for one wouldn't care for extremely tiny gauges in higher resolutions.

I'm sorry to say this, but if you don't know what to do with it, I would have to recommend you steer clear of this for now. This is an experimental build for an unfinished feature, and not, at this time, intended for heavy use.

[14:49] <swashmebuckle> so the game appears to be using all the same low res gauges it was using before (damage, wingmen, weapons, energy1, objective, targetview, time etc.) even though there are high res 2_ versions present in SVN. It's a lot more obvious now too without the stretching[14:50] <swashmebuckle> (I just confirmed all the ANIs in the debug log)

(http://a.imageshack.us/img375/5891/nostretchwronganis.png)

This has apparently been an issue with the old HUD code, and we hoped this might fix it.

Yes, retail has the necessary artwork. No, it's not used (As in, the original HUD code doesn't load them, ever). Ask :V: why, but my personal guess is that they realized in testing that these hi-res art pieces are too big for 1024x768. Enabling their use is trivial, but as I said, requires more customization options in the new hud_gauges.tbl (which are trivial to add, btw).

Yeah apparently it's the one that wraps around that element normally. Looks like that was an issue before this and I just hadn't noticed it either. I started using our new HUD elements and the new HUD code at about the same time so I wasn't aware there were any of these existing issues.

Yes, retail has the necessary artwork. No, it's not used (As in, the original HUD code doesn't load them, ever). Ask :V: why, but my personal guess is that they realized in testing that these hi-res art pieces are too big for 1024x768. Enabling their use is trivial, but as I said, requires more customization options in the new hud_gauges.tbl (which are trivial to add, btw).

Yup. Plus, as I explained to chief over IRC, the unused hi-res artwork can't seem to decide what size font it's optimized for. The hi-res directives bitmaps assume the font used is 15 pixels height. The hi-res escort bitmaps assume a 19 pixel font height. Hi-res comm menu is supposed to be used with 17 pixel high fonts. I mean, make up your minds! :\

So, the unused hi-res HUD artwork need some work before they can be used. That's probably something for FSU to deal with for some hypothetical hi-res MediaVP HUD project.

This'll all come to fruition once I open up all sorts of definable options for each individual HUD gauge. However, you're still stuck with a 9 pixel tall font (font01.vf) unless you willing to experiment to find a bigger font that won't smedge up the menu interface. To truly have a hi-res HUD without the mentioned side-effects, I need to complete a feature that will allow the HUD to use a *.vf font file separate from the menu interface. Hopefully soon.

I've been busy the past couple days. Committed a **** load of bug fixes and tweaks along with a massive addition of gauge configuration options to hud_gauges.tbl. For those looking to assign different bitmaps per flyable ship class or tweak the dimensions of your HUD graphics, this is the build you've been waiting for.

Check the updated original post of this thread for the download package. Inside are the new executables and a sample working table (Based off on The_E's standard layouts for both widescreen and fullscreen) with all the configurable fields commented out.

This is all very cool but it's still not working with FSPort. Turning on $Reticle Style: FS1 gives me no HUD at all, and replacing the HUD element filenames with their FS1 counterparts (such as replacing 2_leftarc with 2_leftarc_fs1) gives me a horrible mess.

There's a bug when parsing the hud_gauge.tbl file which prevents the parser from parsing any of the configuration entries after reading $Reticle Style. It's been fixed and I uploaded a new build with that fixed. Check the first post for the usual link.

Keep in mind that the packaged hud_gauge.tbl assumes that the HUD bitmaps being used are the FS2 retail bitmaps and are positioned accordingly. So, even though the threat indicator will use the correct FS1 bitmaps and have the dumbfire and missile lock blinkers in the right place, they're going to be positioned in the same FS2 place right of the reticle. You're also going to have to un-comment the Weapon Linking gauge entry in the file and I'm not too sure if it's positioned correctly either.

Good luck incorporating this for FSPort. If you need help finding out the hardcoded values present in the code for the FS1 defaults, I can help doing that and adopt them for widescreen. That is, if The_E can't do it. :)

I don't care how close to the center of the screen it is, I'm not going to read it if I'm trying to shoot something. Battle dialog simply has to take a back seat to the action if it's not VA'd. I may pause it, but I'll still want to read top to bottom then.

Really enjoying working on custom HUDs with this stuff--awesome work. I'd like to use the high res target viewer (2_targetviewx), but the game persists in using the standard res anis. I remember hearing something about the appropriate text sizes being unavailable for some of these elements, but would it be possible to just continue using the smaller text? I only ask because it seems that all the information for working out the proper text offsets is present, it's just the Monitor Filename and Integrity Bar Filename lines themselves that appear to be locked out...Might be completely wrong here, apologies if so.

Is that possible to add support for adjusting top arc of the HUD? There is a blank ANI file for it in retail files, so it's invisible on default HUD, but some mods used it and made custom interface art for it (TVWP comes to mind).

Just to add to my earlier comment, the wingman anis and the weapons5 ani (bottom of the weapons gauge) seem to be similarly locked out, and I'm finding that most of the parameters for the latter don't seem to do anything yet either. I love that you can change the header in the escort list--is this planned for the other gauges as well? Also it would be awesome if the font size was controlled in the table--most of the stock high res anis look a little silly with the small text. Great stuff.

Just to add to my earlier comment, the wingman anis and the weapons5 ani (bottom of the weapons gauge) seem to be similarly locked out, and I'm finding that most of the parameters for the latter don't seem to do anything yet either. I love that you can change the header in the escort list--is this planned for the other gauges as well? Also it would be awesome if the font size was controlled in the table--most of the stock high res anis look a little silly with the small text. Great stuff.

Your concerns have been noted. Yes, I'll get around to changing the header text for the other gauges.

As for font size, that's something out of my control. Font sizes are fixed in the engine. As I explained earlier in this thread, I plan to implement the ability for the HUD to choose and use a font separate from the menu interface as a work around.

A general question (in response to seeing mention of ship/gauge/HUD-specific stuff)...

How much support (if any) for doing stuff like... creating a HUD specific for one ship class, which copies all the properties of another HUD, but changes one aspect of it (without requiring the mod developer to basically copy-paste the entire thing)? Also, for stuff like defining positions relative to other stuff?

And will scripting be able to control HUD components, without having to fully recreate the HUD? I remember a while ago (and maybe to this day) it was rather frustrating that if you overrode the $On HUD Draw: scripting hook, you had to completely re-implement all of the parts of the HUD you didn't want to get rid of... Meaning getting rid of 1 gauge via scripting was as bad as adding dozens of gauges.

Ship specific HUD is exactly the reason why I tested this build and it does indeed work. (http://a.imageshack.us/img826/9649/screen1518.th.png) (http://img826.imageshack.us/i/screen1518.png/)That thing written over the grid is the model number and "official" name of fighter it's installed on.

Been working on refining the HUD with the latest build, and the new font support is freaking sweet. Though the wingman anis still seem to be locked out, the target viewer now is working great with the high res artwork. When I tried to use the "Integrity Bar Foreground Clip Height: 88" option though, I get a crash on startup where it says the game is looking for an INT (even though it is using an integer), so I've had to leave that commented out. I also sometimes see a problem with the extra target data gauge where "waypoint" and "time to 01:30" are overlaid on top of each other rather than showing up as "time to waypoint 01:25" or however it's supposed to read. Anyway, the awesomeness of this feature cannot be overstated.

A general question (in response to seeing mention of ship/gauge/HUD-specific stuff)...

How much support (if any) for doing stuff like... creating a HUD specific for one ship class, which copies all the properties of another HUD, but changes one aspect of it (without requiring the mod developer to basically copy-paste the entire thing)? Also, for stuff like defining positions relative to other stuff?

And will scripting be able to control HUD components, without having to fully recreate the HUD? I remember a while ago (and maybe to this day) it was rather frustrating that if you overrode the $On HUD Draw: scripting hook, you had to completely re-implement all of the parts of the HUD you didn't want to get rid of... Meaning getting rid of 1 gauge via scripting was as bad as adding dozens of gauges.

i wouldnt mind having hooks for some gauges, like radar and anything else that can be recreated with scripting fairly easily, like weapon info and different styles of lead indicators. these hooks might want variables like where its supposed to go, what size its supposed to be. of course that sounds somewhat complicated.

it might be easier just to disable certain gauges on certain ships, and place a scripted gauge in the resulting hole, crude but somewhat effective (and made somewhat easier if your first suggestion is implemented). it would help though if you could find out some info about the gauge you are replacing through scripting, like its position/size/color and other parameters. the script doesnt need to know what configuration your using, just what parameters are currently in use. and if you could disable and enable the gauge from the script as well (make it one of the parameters), then the scripter really doesnt need to concern themselves with the hud table at all.

also a small fiy, my attempt to render a hud to polygons in the cockpit model with scripting have hit a brick wall. seems i cant tell the hud to render at an arbitrary time, and if i recreate everything in scripting, i cant seem to draw anything transparent to the dynamic texture, so even if i could render the hud, the bitmap would be opaque and completely block your view. so li be keeping an eye on this, waiting for scrpting features to pop up.

Scripting features involving the new HUD specification are planned. The plan would be to perhaps have the Custom gauge HUD object type have a Script: field which a user can define a Lua function or source file that will provide additional logic for a more dynamic user-defined gauge with access to the HudGauge class methods so the script writer won't have to worry about the various transformations that FS2 does (TrackIR, afterburner shakes, screen position)

In any case, would it really bother anyone if we change the behavior of On HUD Draw to not disable the HUD? If someone really wants to completely replace the HUD with this new HUD spec, they can just set Load Retail Configuration to No in hud_gauges.tbl and not define any gauges.

Been working on refining the HUD with the latest build, and the new font support is freaking sweet. Though the wingman anis still seem to be locked out, the target viewer now is working great with the high res artwork. When I tried to use the "Integrity Bar Foreground Clip Height: 88" option though, I get a crash on startup where it says the game is looking for an INT (even though it is using an integer), so I've had to leave that commented out. I also sometimes see a problem with the extra target data gauge where "waypoint" and "time to 01:30" are overlaid on top of each other rather than showing up as "time to waypoint 01:25" or however it's supposed to read. Anyway, the awesomeness of this feature cannot be overstated.

Uploaded a new build in the OP with all the stuff you reported fixed. Thanks for reporting them.

As for the Extra Target Data gauge, I forgot to properly initialize the offsets that handle "Time to waypoint". There's an extra field that I forgot to add for it before but it's now there. I've updated the sample hud_gauges.tbl with the extra field.

In any case, would it really bother anyone if we change the behavior of On HUD Draw to not disable the HUD? If someone really wants to completely replace the HUD with this new HUD spec, they can just set Load Retail Configuration to No in hud_gauges.tbl and not define any gauges.

Yes. The ability to completely override the entire HUD through scripting should still be present. What should be added would be a "Override HUD gauge type" option, as well as the "integrated scripting" thing you proposed.

Custom gauges already have a "Gauge Type" field. If you want to hypothetically replace the weapons gauge, you'd define a Custom gauge in hud_gauges.tbl with Gauge Type: WEAPONS_GAUGE and Script: hud_new_weapons.lua or something like that.

That's the best I can think of a scripting interface that plays nice with the new HUD spec.

Scripting features involving the new HUD specification are planned. The plan would be to perhaps have the Custom gauge HUD object type have a Script: field which a user can define a Lua function or source file that will provide additional logic for a more dynamic user-defined gauge with access to the HudGauge class methods so the script writer won't have to worry about the various transformations that FS2 does (TrackIR, afterburner shakes, screen position)

In any case, would it really bother anyone if we change the behavior of On HUD Draw to not disable the HUD? If someone really wants to completely replace the HUD with this new HUD spec, they can just set Load Retail Configuration to No in hud_gauges.tbl and not define any gauges.

i kinda think it should still use the existing overrides and toggles. one way to toggle the hud is to use hu.HUDDrawn, this allows you to turn the hud on and off say, if youre using a camera view. unfortunately it doesnt give you control over when the hud is rendered, and i assume it runs immediately after scene render. the other is with the +override: tag in the scripting.tbl. i think if the existing features remain functional that should be satisfactory, and should allow for complete hud replacement.

Custom gauges already have a "Gauge Type" field. If you want to hypothetically replace the weapons gauge, you'd define a Custom gauge in hud_gauges.tbl with Gauge Type: WEAPONS_GAUGE and Script: hud_new_weapons.lua or something like that.

That's the best I can think of a scripting interface that plays nice with the new HUD spec.

id make available an array of hud gauges available to scripting (much how ships or weapons would work). you could iterate through gauges, or pull one up by name, and each one would have all the relevant parameters associated with that gauge, size, position, etc, including the ability to turn it on or off, render it, and so on. this could be used in the embedded script, or in your usual scripting files. it would be the most convenient and familiar way to go about it.

Sweet, the Target viewer/extra target info are now working great, and wingman1-3 have been unlocked. I still can't use the wingman "Dot Filename" line, and there are collisions between the lowest dots (in their retail positions) and the wing name text--will there be an option to control the wing name's Y-position based on the number of dots present? And would it be possible to now enable more than 6 dots per wing? It'd be great for SWC if we could do full squadrons of 12 Tie Fighters, etc.

Damn, other than that and the lines to rename gauge headers, I can't think of anything else I might need. Impressive...most impressive :)

Bigger wings I think might be limited by more than just the HUD, but I'm not sure about that.

It's limited by MAX_SHIPS_PER_WING. It's used by the code everywhere from mission management, AI, FRED, and of course, the HUD. God knows what will happen if you arbitarily changed that value. It's not something we can willy nilly cap off.

I still can't use the wingman "Dot Filename" line, and there are collisions between the lowest dots (in their retail positions) and the wing name text--will there be an option to control the wing name's Y-position based on the number of dots present?

BTW, swashmebuckle, can you give me a screenshot in 1024x768 res of the wingmen gauge with wings of 6? I'd like to do some pixel counting to make sure the retail defaults are correct. :P

Hey Swifty, I've been testing with chief's mac build at r6481 and the wingman dots are up and running for me. I'm now trying to integrate some new fonts in, and having some difficulty with vertical spacing. Basically, my replacement 9pt font seems to be a little taller than what can be cleanly supported atm and I am getting collisions in the messages window and the objectives gauge. I got around this problem with my replacement for the smaller font01 by putting in an extra blank pixel of height under each character in the font file, but there seems to be a set line spacing value that the 9 point font is just too large for. With even larger fonts it starts to clip the bottoms of the characters off. If the line spacing and how many lines appear at once in the messages could be controlled in the table that would enable me to use the bigger font for all of the gauges (though training messages seems a little odd too--no assignable image or text spacing so far?).

That and the documentation for how to implement the wing name spacing and custom headers are all I can think of for how to improve the HUD. It's really looking fantastic: Huge props :yes:

If you're asking what this entire thread is about, it's about revamping the retail ship HUD to be much, much, much more flexible, including things like full repositioning of gauges, full custom gauge support, and fixing non-4:3 stretching issues. I don't know how else to take your question if that's not what you meant, it doesn't seem like it's in the context of a recent reply. In fact, this code is just about ready for Antipodes testing, either preceded or followed by taylor's go_faster code likely.

Hey Swifty, I've been testing with chief's mac build at r6481 and the wingman dots are up and running for me. I'm now trying to integrate some new fonts in, and having some difficulty with vertical spacing. Basically, my replacement 9pt font seems to be a little taller than what can be cleanly supported atm and I am getting collisions in the messages window and the objectives gauge. I got around this problem with my replacement for the smaller font01 by putting in an extra blank pixel of height under each character in the font file, but there seems to be a set line spacing value that the 9 point font is just too large for. With even larger fonts it starts to clip the bottoms of the characters off. If the line spacing and how many lines appear at once in the messages could be controlled in the table that would enable me to use the bigger font for all of the gauges (though training messages seems a little odd too--no assignable image or text spacing so far?).

That and the documentation for how to implement the wing name spacing and custom headers are all I can think of for how to improve the HUD. It's really looking fantastic: Huge props :yes:

It doesn't matter how big your font is. The engine will always use the individual gauge's "Entry Height" value. You have to change the line spacing for each and every gauge to account for your new font. Look for an option called "Entry Height" in some of the gauge fields.

EDIT: I guess I don't have "entry height" for all of the gauges. Especially Training Messages.

If you're asking what this entire thread is about, it's about revamping the retail ship HUD to be much, much, much more flexible, including things like full repositioning of gauges, full custom gauge support, and fixing non-4:3 stretching issues. I don't know how else to take your question if that's not what you meant, it doesn't seem like it's in the context of a recent reply. In fact, this code is just about ready for Antipodes testing, either preceded or followed by taylor's go_faster code likely.

Sorry, I was half asleep trying to read though it. Very cool now you'll be able to modify the helmet hud however you like. (I was original referring to render hud to texture for cockpit models)

I went ahead and created a hud for 16:10 triple monitor configs. (might also work for 16:9, haven't tested). I'm running 3x 1920*1200, for a 5760*1200 display. Problem is, when I fire my primary weapons, the bolts seem to be firing a bit left of the reticule. Checked my table, and it appears the reticle is right in the middle of the screen, so I'm not sure what is wrong.

The problem is that the reticle x coordinate is exactly on the center. It needs to be on (Screenwidth - Reticlewidth)/2 instead.Since the retail reticle is 40 pixels wide, you should place it at 2860, not 2880.

Well, playing around with this build got me thinking on a couple different angles.

1. Creating native huds for larger resolutions makes all of the elements tiny. It's probably best to create a table entry at a lower resolution than native so that it scales up the elements in size somewhat. For example, instead of making the default resolution for my 16:10 eyefinity hud 5760x1200, I perhaps should have used 4320x900, or 5040x1050. On the other hand, someone at 7680x1600 might want to use my 5760x1200 hud (so that the elements aren't too far blown up)

2. A much more elegant solution would be to have all of the basic positioning and and scaling in the source code rather than in a table file. Instead of an absolute postional value, the hud elements should be based on a reference to either the center of the screen or one of it's sides. Common eyefinity/surround resolutions can be detected and compensated in the source code. It also shouldn't take too much extra too detect and compensate for bezel correction (which most surround users will be using) by looking for 'near' eyefinity-type resolutions with slightly extnded horizontal resolution (say, within 512px). For example, the program would see 6016x1200 as 5760x1200 with a bezel correction of 128px per side and move the side elements closer to the center.

The table method is certainly welcome, and aside from bezel correction it should be easy enough to load the table with all of the common resolutions people use. The issue I see is that any mod that decides to rearrange the hud elements will have to create a large amount of table entries. And if that mod wants to create custom huds on a per-ship basis then that's going to be a lot of table editing to cover all of the different aspects/resolutions. An automated system where they only need to create one template and the engine intuitively scales the template to any resolution would be better.

Yeah, there *is* that. With the lowering costs of monitors and the march towards graphics cards with three display outputs, there will be more and more of us, but we'll always be in the minority. I can see more FS2 players using triple head than average, just as more FS2 players use TrackIR than average. 5:4 is still going to stretched 4:3 (albiet not extremely noticable like 4:3 vs. 16:9), as is 16:9 vs. 16:10.

Now, obviously the new system for HUDs is a million times better than what we had before, but it would still be nice to have a more intuitive approach to how things are handled. Another thing to keep in mind is that people with triple head setups tend to actively seek out games that handle ultra-wide resolutions well. Again, I'm perfectly happy (and thankful!) with the new system, but a relative hud would just be that much better.

Well, I don't see a reason not to include configs for these additional setups, whether it be 3x 16:10 or 3x 10:16, or 3 wide with another one on top of the middle one, etc. But someone has to create the tables is all. Once that's done just about any mod that uses the MediaVPs could probably have them available. I'm not sure how to make it much more intuitive the way the engine is set up right now.

me personally im happy with a single 1080p screen and my trackir. 3 or more screens would be awesome, but nowhere within my budget. also, while it may give you a huge natural field of view in the horizontal, you still have a very narrow vertical view angle. you could pair it with the trackir but i think it would be too disorientating. i kinda wish instead that each monitor would have its own camera space, so that you can put the monitors in any position in real space and have them correspond to similar positions in simulated space. this would make it better for example if you had screens of various native resolutions. you could arrange them any way you see fit and you would just have to model the configuration in the table. would also solve the bezel management issues. doesnt sound very likely (any time in the near future) though.

it also seems to me that while game graphics have kind of stagnated in the past few years in terms of the speed at which they improve. monitor resolutions are going up. maybe we should consider the possibility that we need additional art sets for the hud (and interface) to accommodate less archaic resolutions. when you start picking up 1024x768 screens at garage sales for 5 bucks, its a sign that any screens at that native resolution is obsolete junk. :D

you could stretch the hud graphics, but you can only make them so big before you get ugly scaling artifacts. since the scaling difference between 640x480 (is that resolution even supported on modern operating systems?) and 1024x768 is 1.6x in the horizontal, which means we need something in the 1600 wide ballpark, and since many monitors above 1024 (aside from the 1280x1024 era that seemed to last forever) seem to be widescreen resolutions, i think a set in the 1680 x 1050 resolution would be a good point to create an image set for. it would scale up to other 16:9/10 resolutions pretty well. i wouldnt mind having a set in the 1080p standard, but that might be asking too much. pretty soon you would end up with art sets for every resolution.

i wouldnt mind the game being completely agnostic to the size of the images it would use on the hud. it would find the one that closest matches the required size and then scale it automatically. then make it so aspect ratio, not screen resolution, determines the layout data to use. images can always be scaled to whatever multiple of the aspect ratio is in use.

another thing i think we should consider is to not invalidate someone's hud tables if they are trying to make the game work with their video hardware. you can do this either by considering every possible screen resolution known to man, and include it in the tables (youd still get issues with people running multiple screens). something where hud layout by aspect ratio would come in handy. the other way to make an edit-friendly hud table for setting resolutions that the table distributed with the freespace upgrade doesnt include.

another thing i forgot to mention that i didnt want to stick in another post edit. something that may have been addressed before. the possibility to use non-ani graphics for the hud and shield icons. i noticed that most hud graphics have been limited to 16 color ani files. i wouldnt mind seeing those replaced by eff/dds graphics. that is of course if it hasnt been done yet. i havent really been keeping up with that stuff, but it would greatly improve the quality of the hud graphics if it were possible. ani is not manditory in most of the game and i would like you guys to take the format out back and shoot it. indexed color is so 90s.

another thing i forgot to mention that i didnt want to stick in another post edit. something that may have been addressed before. the possibility to use non-ani graphics for the hud and shield icons. i noticed that most hud graphics have been limited to 16 color ani files. i wouldnt mind seeing those replaced by eff/dds graphics. that is of course if it hasnt been done yet. i havent really been keeping up with that stuff, but it would greatly improve the quality of the hud graphics if it were possible. ani is not manditory in most of the game and i would like you guys to take the format out back and shoot it. indexed color is so 90s.

I've done some testing with this actually. The engine is perfectly suited to use EFF/DDS in place of ANI. You have to make sure that the color palette is in grayscale if you want to make it look right with the color blending.

another thing i forgot to mention that i didnt want to stick in another post edit. something that may have been addressed before. the possibility to use non-ani graphics for the hud and shield icons. i noticed that most hud graphics have been limited to 16 color ani files. i wouldnt mind seeing those replaced by eff/dds graphics. that is of course if it hasnt been done yet. i havent really been keeping up with that stuff, but it would greatly improve the quality of the hud graphics if it were possible. ani is not manditory in most of the game and i would like you guys to take the format out back and shoot it. indexed color is so 90s.

I've done some testing with this actually. The engine is perfectly suited to use EFF/DDS in place of ANI. You have to make sure that the color palette is in grayscale if you want to make it look right with the color blending.

would that be along the lines of the dds formats like 8l or 88al or palletized (a)rgb at 4/8 bpp? those formats would certainly match the need for a single channel image. though i think it would be better to use the full range of values. some images (shield icons for example) only allow the use of the first 16 colors in an indexed color table, using anything else never worked any of the times i tested it (it also had me swearing over the creation of many a shield icon back in the day). i certainly wouldnt mind being able to have alpha information in the hud graphics, or use full color hud graphics. i just think that graphics that are always visible should have a little bit more emphasis on quality, which depends mostly on the artist (who wouldnt mind being able to use an argb8888 format). multiplicative blending seems to look ok when used with color graphics.

even though dxt1/5's only real requirement is that they be multiples of four. of course if the engine still wants powers of two, then it is ample reason to have good scaling code, since a power of two image is all you can guarantee.

and back to the issue with shield icons, could you use effs for those, but expand the color range to the full 0-255 instead of 0-15?

I don't see anything with the HUD shield code stopping you from doing that, so try it out.

i went ahead and make a rather rushed sheild icon, i went with a full color dxt1 eff and set its scale to 128^2 (hopefully the engine dont care much about the resolution not being typical of a hud icon). ingame the icon is not visible.

even though dxt1/5's only real requirement is that they be multiples of four. of course if the engine still wants powers of two, then it is ample reason to have good scaling code, since a power of two image is all you can guarantee.

It's a video card requirement, not really an engine one, in general. If the video card allows for NPOT then they will be used as-is, if not then they will be made POT. That doesn't really work for DXT compressed images though, since they would have to decoded in software, re-sized, have mipmaps recreated, and then be re-compressed. It's much less trouble to simply not support them. :)

NPOT textures were available at one time for interface graphics through the ARB_texture_rectangle extension. However I believe that somebody (don't actually remember who without looking it up) couldn't figure that out with some sort of radar graphics or something and subsequently disabled the functionality of the extension in order to get things working for them.

I'm having difficulty specifying a HUD layout for the GenericCP.pof. I was thinking that I would specify the ships that I use the pof for but it doesn't seem to make a difference what ship is listed the layout comes up anyway on top of the layout for the other ship. I must be missing something. Is the feature for different layouts for different ships not implemented yet or am I screwing up the table?

I noticed that there isn't a real 16:9 sample table to use. There's a 16:10, but I'm worried that the engine will render it to 16:10 before stretching it to 16:9. Is that the case? If so, I'll try to make a table specifically for 16:9 and post it up when I get that done. (I'll probably be basing it off The_E's 16:10 layout if anything).

Go for it. Feel free to post it in the Antipodes 7 release thread too, this one is now no longer needed really. But stretching between those two similar ratios shouldn't be too apparent compared to 4:3 stretched to 16:9. Might not be worth it.

This is the *actual* 16:9 setup using 1440x810 as the base resolution. All I did was multiply the Y coordinates by 0.9 using The_E's 16:10's layout as a base, so really, all the work should still be credited to him.

I also took the liberty to move the guns and burner energy down a fair bit and also further from the center so that they look closer to the retail appearance. That is the only change I made.

That's not stretched anymore. 1448x810 is 16:9. If you bump up the res, things will get smaller (and need to be re-adjusted for positioning) but the "stretching" or lack thereof will be the exact same.

Edit: Er, if you meant bumping up the max res (which is currently 1920x1080), that should be easy to do user-side. I merely left it as-is from before because I didn't think many people would be playing at above 1080p.

Update:

Okay, so I got bored and decided to tweak the 16:9 HUD to resemble the Vanilla HUD much more closely. Screenshot is attached, so you be the judge on whether you want to use it.

Right, but then you'll get the FS2 HUD, which is decidedly different from the FS1 HUD. I mean, that's way better than omgwtf scrambled fugliness, but I personally would like to see an FSPort HUD table.

The fact that FSPort only has two ETS gauges at the start does raise the question for what exactly happens in subspace missions using mediavps_3612, (like derelict, for example). Do they come together like they should, or do they leave a gaping hole like the screenshots above?

Actually, either of The_E's 1440x900 display settings, will scale to 1280x1024 just fine. A few elements (such as talking head and dialogue) might need a teensy shuffle, but that's it.(Also, on the above, you might be tempted to change the line "$Base: (1440, 900)" ... don't. Then it will look anything but okay because that is what it will scale itself to)

Testing the desired resolutions with the layouts already available is a good idea.

Actually, either of The_E's 1440x900 display settings, will scale to 1280x1024 just fine. A few elements (such as talking head and dialogue) might need a teensy shuffle, but that's it.(Also, on the above, you might be tempted to change the line "$Base: (1440, 900)" ... don't. Then it will look anything but okay because that is what it will scale itself to)

Testing the desired resolutions with the layouts already available is a good idea.

16:10 stretched to 5:4 will have extremely noticeable vertical distortion. In fact, all HUD elements will be taller by a factor of 1.28, which isn't good looking in the slightest. I personally wouldn't recommend doing that. Give me some time and I'll try to make a workable 1280x1024 HUD. I won't be able to test it though, since my gfx card doesn't support 5:4 resolutions without hacking the registry.

As for "stretching" there isn't any. It just adapts the positioning from 16:9 to 5:4, it doesn't actually "distort" any of the graphics used to fit within the specified spaces, just offsets the coordinates given to determine placement.

Again, trying it out first is probably a good idea. I've run my own layout through:16:91280x7201366x7681920x1080

8:51280x8001440x9001680x1050

5:41280x1024 <-- On this one, messages still take place above the head.ani and the Comms menu isn't over as left as I would like.

As I tend to run Debug builds almost exclusively, a few things are moved ever so slightly from "retail". The Comms Menu is a little left so that it will clear the VRAM usage section. The Mission Directives is elevated to go below FPS and above the -show_mem_usage output. Wessages are to the right of the head.ani spot.Centered around the Reticle (or aligned with the center of it) is the damage indicator, Objective notification, mini-enemy shield icon, radar and Support ship notifier. ETS, Auto Speed/Target, mission timer and the like are all nicely grouped together.

I'm also trying to determine, for the purposes of the MediaVPs, if the elements should be "spread out" to their respective (per-resolution) locations (like ETS/etc on the bottom right corner, target data on the bottom left) , or constraining it to maintaining the same aspect in terms of related distance from each other towards the center of the screen instead.

Whoa there, chill. I wouldn't be saying that there is distortion unless there actually was. I'll give you screenshots between your 1440x900 config and my 1440x810 config to prove that yours draws to 16:10 first before stretching it to fit 16:9 and that mine doesn't. I'm using the regular build though, not the debug.

On another note, I've made an excel calculator that will calculate positions for any screen resolution. It looks at HUD elements as either Left, Center, or Right, and puts Left/Right elements against the edges, and (attempts to) center the Center elements. As of now, the default 1024x768 table The_E posted on page 2 has wrong coords for Throttle and Threat gauge, so my calculator similarly makes mistakes there.

That happened, so I went back and made the file sizes smaller. The table files are as-is from the previous few posts, with the head ani moved over 50 pixels just to show that the tables are actually kicking in. The second one is 16:10. Notice that there is definite stretching happening, most noticeable from the shape of the radar.

My point is only that stretching will exist, so that it may be useful to have a calculator to help you figure out a 0-stretch HUD_guages.tbl for any resolution out there.

Said calculator is already done. I just need the *actual* (x,y) for Throttle and Threat Indicator, since the ones I have are wrong. I'd make up values that look right, but I wish to stay as true as possible to vanilla (and I'm OCD). (Assuming the table The_E posted a long time back is the real vanilla table. If he got as close as possible by eyeballing, then I might as well do the same).

Another option I have is to screw 1024x768 as a base, and instead use my adapted 1440x810 version as the base. I'll instead use a 4-corners + center shuffling system so that you won't get such vertically spread out/scattered elements when using taller aspect ratios. I won't be doing both though, since I'm lazy and stuff like that. Thoughts?

Granted, both of those are taken at LESS than the "$Base: (1440, 900)" but here's the neat part....the same holds true at the aspects at resolutions higher than the specified base as well.I screen capped 1920x1080 and 1680x1050 and resized them down to match, and they matched.

I've got a pretty good (artist's) eye, and I can tell you straight up that your 16:9 one is stretched. Compare the two Ulysses, or the angles in the center reticle, or your orb radar, or Command's head, or anything else on the HUD that's shown.

It's incredibly minor, but it's there.

Also, when you resized them, you should have noticed that the HUD elements didn't overlap. (If they did, it means while resizing, you also changed the aspect ratio of one of your two comparison images, which, obviously, would mean that the HUD elements would definitely overlap.)

In other news, the 1440x810 calculator is done, and I'd like people to do some testing with it. Unfortunately, I am illiterate in coding, so it doesn't spit out a ready-to-use tbl. You'll need to find a template earlier in this thread and copy in the values the calculator gives you, making sure to set $base to the same resolution you entered into the calc. The only thing you need to do in the calculator is to enter your desired HUD overlay render resolution. I made it in Excel 2007, btw, so if you can't open that, I guess you're out of luck :(

The E's 1024x768 is actually really damn accurate to Retail with the exception of the center reticle being down a few pixels.

In an effort to prevent the moderate to mild amount of skewing that seems to exist for some, I've resolved to making a series of TBM's for the MediaVPs where every HUD resolution is specifically laid out. This comprises of 6 *-hdg.tbm files and does not count the 1024x768 or 640x480 that will be in mv_core-hdg.tbm.

So far, I have: 3-2_Aspect, 4-3_Aspect, 5-3_Aspect, 5-4_Aspect, 8-5_Aspect and 16-9_Aspect comprising of 25 resolutions. I hope this will be sufficient and that there won't be any missed resolutions. (List was derived from: Available launcher resolutions and this Wiki image: http://en.wikipedia.org/wiki/File:Vector_Video_Standards2.svg plus a few extras)

That being said, as the single monitor resolutions get larger, should elements be anchored to their respective corners, or to a respective position to the center reticle?

And would people like the layout _slightly_ modified in order to be also usable with Debug Builds so that the mem_usage and VRAM elements don't obscure anything?