[Swifty]

Helmet mounted displays have been implemented with the latest fighter jets like the F-35 and the JAS 39 Gripen.

BTW, I'm one of karajorma's newbies from BTRL. I'm planned on popping my FSSCP cherry by working on a slewable 3D cockpit view, maybe compatible with TrackIR, for full support for situational awareness. So, karajorma led me to this thread and I'd like to help out on this part of the project. Nuke's explanation has pretty much reflects what I want to do.

instead you create a full cockpit with all the goodies i mentioned, combine that with something like a trackir or a couple view axes, and you got some total awesome. then you can have your panel which you can look at as needed, a hud at boresight where you need it and you can now follow the first rule of fighter combat, keep your head on a swivel

[jr2]

[Grizzly]

Oh noes! all my eyepoint recoractions in the HTL models where for naught!

[akenbosch]

oh well, your's needed the jpgatga flag to be turned off anyway.

[Cobra]

No they didn't.

[akenbosch]

it didnt?


god...i keep reading the wrong topics.

[Einstine909]

instead you create a full cockpit with all the goodies i mentioned, combine that with something like a trackir or a couple view axes, and you got some total awesome. then you can have your panel which you can look at as needed, a hud at boresight where you need it and you can now follow the first rule of fighter combat, keep your head on a swivel

Question regarding this: The red dot that is present when one is using the mouse look, can that be turned off? cuz it gets annoying after a while, plus, it wouldn't look good with this idea.

Oh, and if idea was put into FS2, i would go out and BUY the TrackIR just for it.

[Vasudan Admiral]

I'm currently partway through drawing up some more fitting elements for the in-cockpit view in vector graphics, which I am hoping will then be usable no matter which way the cockpit view ends up being implemented. They're essentially just going to make better use of the available space and the colours won't clash with the modeled control panel as those in the template do.

As to the implementation:
Currently I'm leaning towards just reconfiguring the existing HUD to make it look like some elements are being displayed on the panels.

I'd prefer to just reconfigure the existing HUD as opposed to script it using RTT as it's less work, probably a lot faster, closer to being possible at the moment and won't be basically re-implementing already existing features. It also has the advantage that the flashing guage effect you see in training missions will still work correctly.

On the other hand, this has me interested, and would probably need RTT:

BTW, I'm one of karajorma's newbies from BTRL. I'm planned on popping my FSSCP cherry by working on a slewable 3D cockpit view, maybe compatible with TrackIR, for full support for situational awareness. So, karajorma led me to this thread and I'd like to help out on this part of the project. Nuke's explanation has pretty much reflects what I want to do.

What sort of features are you refering to here? Ie, when you look at the cockpit in the pics, what sort of things would you hope to interact with in some way?
I ask because if you're willing to do the code behind it, I'd be happy to do things like moving controls, buttons that light up and that kind of thing.

Basically, if you want the model to do something, let me know what and how you'd need it set up and I'll implement it at the model level.

[Wanderer]

Well.. the idea behind the script thing was that then it might be possible to selectively replace hud gauges with scripted versions - instead of all or nothing system we currently have - and to move the gauges more or less freely on the hud. In addition to RTT that is.

[Grizzly]

it didnt?


god...i keep reading the wrong topics.

Well, turning of the Jpg/tga flag was one of the solutions... the other one was removing all other cockpit files or getting on with the cvs builds

[Swifty]

What sort of features are you refering to here? Ie, when you look at the cockpit in the pics, what sort of things would you hope to interact with in some way?
I ask because if you're willing to do the code behind it, I'd be happy to do things like moving controls, buttons that light up and that kind of thing.

Basically, if you want the model to do something, let me know what and how you'd need it set up and I'll implement it at the model level.

Well, for starters, I'm just on implementing a simple continuous padlock view where instead of having four different views (up, 3 o'clock, 6 o'clock, 9 o'clock), we can essentially have a continuous rotating pitch/yaw. I'm still just trying to get myself acquainted with the source code before I go on to do bigger and better things for BTRL and the FSSCP as a whole. Getting scripted avionics and instruments gauges implemented into a 3D cockpit right now is a bit way over my head... As of the moment. However, it is indeed something I'd like to pursue if I manage to gain some momentum contributing to the codebase.

[Nuke]

Hmph.  What about the new HUD-on-helmet visor thingy?

usually when a game has a helmet visor hud, its usually an excuse for doing a screen overlay. when they do this it should look like its been projected on to a curved screen.

this actually brings up the question of what were gonna do with the hud when we have fully interactive view controls. we can rtt the thing and stick it onto a modeled hud in the virtual cockpit. which changes the math for some hud emlements. like when you need to figure out where to put a lead indicator on an arbitrary surface in space while youre view angle changes as you look about. the math there is more complicated. definatly its gonna break the getScreenCoords function.you could probibly steal the solution from the orbiter source code.

the more likely solution is that the were gonna do the horrid thing that i really dont want to do, keep the hud drawn on the screen dispite the angle of the view. the function for gretting world coords to screen coords should still work.

for the wrap around hud viser look, rtt the whole thing and map it onts a partial sphere, then render it on top of everything. this of course fisheyes everything and things like get screen coords will no longer work properly. im sure theres some other math you can do to compensate the fishbowl effect.

a 4th possibility is something i wanted to do on the phoenix fighter, a holographic hud. actual 3d models or wireframe will be rendered in the forward section of cockpit where the hud would normally be. theese would either be submodels in the cockpit or models rendered through renderTechModel(). this would be on the same per-ship implementation for things like yokes, sticks, levers, pedals, and orientation spheres i already plan to use.

[Vasudan Admiral]

Well.. the idea behind the script thing was that then it might be possible to selectively replace hud gauges with scripted versions - instead of all or nothing system we currently have - and to move the gauges more or less freely on the hud. In addition to RTT that is.

I've thought about that, yeah. If this free-look thing happens, then the HUD will have to be RTT'ed onto the viewscreens. How feasible, how efficient and how good looking this would be I'm not sure.

At this stage though I'm just going to approach it as though it will just be the usual HUD elements reskinned and repositioned to *look* as though they're being displayed on the panels.

================================

Anyway, the next phase of development is really up to the coders. Here's the POF, texture, COB and TBM in it's current state if it's needed for testing:

http://webzoom.freewebs.com/twisted-infinities-va/TerranCockpit.rar

Note to modders: These files are NOT the final version! Don't begin incorporating them into fighters or anything, because you'll only have to yank them out and replace them when we get a final version happening!

I posted this list on Sectorgame, but maybe a coder here will read it and respond:

Before I go further with this, I really need a coders thoughts on the implementation.

What would be the best way to handle players turning cockpit view on or off?
My current idea is to have it as an in-game or at least launcher option rather than having to add bits and pieces in the right places.

==========

To get such a feature working, it would need a couple of aspects to it:

1) If the flag "show ship" is present on the ship the player is in, then nothing should happen. (Ie, this assumes the modder has their own cockpit model they want to use)

2) It would need to lock the FOV the game used to the default. (Using something else would totally mess it up)

3) It would need to load up this cockpit POF and position it so that the models eyepoint is placed around the viewpoint, and rendered only when in normal view (ie, it would be hidden when in chase view)

4) It would need to switch the HUD over to this alternate layout (once a form has been decided on). I'm not really sure how this would be handled - and it's the main part I need a coders input for.

===========

There are a couple of longer term and slightly more complex features that should probably be implemented eventually too:

5) This might be possible to do via scripting already, but it'd need to display the appropriate canopy struts for the ship the player is in. They'd then be set up as separate appropriately named submodels in the cockpit POF that could be hidden or revealed by the script/code.

Ie, you'd call the Herc's strut submodel "fighter06" or "GTF Hercules" depending on which is better/easier to access.

6) Some way for the modder to define the cockpit POF used so it could basically be changed on a per-fighter basis for anyone macho enough to make multiple cockpit models. This would really be needed for things like the SWC or BTRL which have craft that have very distinct cockpits rather than FS' style of one standard fits all.

I'm more than willing to help out the coders on the modeling/texturing/interface art side of things.

Incidentally, the HUD_gauges.tbl feature is currently only partially implemented. As is we can only modify: "Player Shield, Target Shield, Shield Mini, Afterburner Energy, Weapons Energy and Escort List" according to the Wiki. Any chance this could be completed?

=======================

Well, for starters, I'm just on implementing a simple continuous padlock view where instead of having four different views (up, 3 o'clock, 6 o'clock, 9 o'clock), we can essentially have a continuous rotating pitch/yaw. I'm still just trying to get myself acquainted with the source code before I go on to do bigger and better things for BTRL and the FSSCP as a whole. Getting scripted avionics and instruments gauges implemented into a 3D cockpit right now is a bit way over my head... As of the moment. However, it is indeed something I'd like to pursue if I manage to gain some momentum contributing to the codebase.

Ok, fair enough.

[WMCoolmon]

hud_gauges.tbl was designed from the start to be accessible to other coders besides me.

It looks like the main difficulty is that the NEW_HUD stuff clutters things up a bit. I don't think that's in use. I remember that it was 'better', but it was a work in progress when it was discontinued. Basically, I wanted to focus on the scripting stuff, because I was ending up redoing a lot of the internal FS2 gauges via copy-paste, and it seemed a bit silly to do all that when a full scripting language would let someone re-implement the entire HUD, and then other people could base various modifications off of that re-implemented HUD. Those modifications could have far more variety than just different images, text, or positions.

I'm doing some cursory looking at the code right now.

Old hud_gauges

I'm assuming this is the current version because NEW_HUD is commented out in hudparse.h

The old HUD system defines an array at the very top of hudparse.cpp. It's very big, you can't miss it. Each entry in this array represents a HUD gauge. Rather than taking responsibility for drawing each gauge, though, the old HUD system simply manages the information required to store the gauge, and even then, only in a limited fashion. You can store the position and size (which is what people are most interested in) as well as an image, some text, and a color. These are specified either via SEXPs or via hud_gauges.tbl.

The interesting thing about the way the array stores the data lies in the offset operation it uses to do so.

To add a gauge to hud_gauges.tbl, you:
(1) Add variables (of the appropriate type, of course) to the hud_info struct in hudparse.h. Look at the custom_gauge_* variables to see what kind of information hud_gauges.tbl supports. If you wanted to add support for the radar, for instance, a good starting point would be to create a "int radar_coords[2];" array to store the coordinates for the radar in.

(2) Add a new line to the "gauges" array at the top of hudparse.cpp. If the gauge location is independent of anything else, it should go in the top row. If it is dependent, it should go in the bottom row.

(3) Fill out the new line in the "gauges" array
(3a) Parent specifies the parent gauge, if there is one. For example, the parent gauge of an entry in the escort list would be the main escort gauge.
(3b) coord_dest refers to one of the variables you added in one, specifically, the one you created for the gauge coordinates (an int[2] array...right?). To refer to it, just use "HUD_VAR()" with the name in between the parentheses. Do not ask what HUD_VAR does, assume it is magic and it works. Or look at the define and do research on your own.
(3c) The token name that the gauge should be referred to in the table. This includes the "$" and ":", see the existing entries.
(3d) The next four variables are integers specifying the default X and Y positions in 640x480 and 1024x768, respectively. This one is the X for 640x480
(3e) Y 640x480
(3f) X 1024x768
(3g) Y 1024x768
(3h) This refers to the variable in hud_info for the gauge size (int[2])
(3i) Ditto for the image name (char[MAX_FILENAME_LEN])
(3j) Frame number of image to display (int)
(3k) Text to display (char[NAME_LENGTH])
(3l) Color of gauge (color)
(3m) Placement flags. Basically, the system will automatically offset child gauges from their parent gauge by the specified coordinates unless you add the HG_NOADD flag here. If you are dealing with the position of list items, you will want to use HG_NOADD and handle the values specified for the list items in the HUD update function. See the escort list for more details.
(3n) Show flags. I don't know if this actually does anything so ignore it.

(4) If you added fields for color, size, text, etc you should specify the default values in the load_hud_defaults() function. See the comments in that function.

(Timeout) Now that you have all the info for the gauge_info struct filled in, you should be able to specify the gauge in hud_gauges.tbl and have Freespace 2 load it. However, you will see no changes.

(5) Go to the location in the code where the gauge is displayed. This is the fun part. You can now access any of the variables that you created in step 1 using the current_hud-> pointer. hud_gauges.tbl will take care of filling out this pointer (though an assert wouldn't be a bad idea). In addition, hud_gauges.tbl will take care of filling out the values and interpolating for the various screen resolutions. You can choose to use the fields in whatever way you please.

(6) Increment Num_gauge_types to reflect the number of items in the gauges array.

New hud gauges

I spent a lot of time on the last section so I will only provide a brief summary of what I remember/have determined about the new hud gauges.

The idea of the new HUD gauges was to redesign the entire Freespace 2 HUD API to make it infinitely easier to work with, mostly by making things object oriented. This would also add some nifty new functionality, like gauges would be tied into the ship you're currently viewing from, rather than always being focused on the player ship.

In addition, it was supposed to add the ability to predefine certain gauge types and create all-new gauges. So you could turn a number gauge into a bar gauge, for instance.

As time went on, though, it became apparent I would have to implement a fair chunk of a scripting system's functionality in order to make the new HUD gauge system fully functional. So I dropped it in favor of scripting, which became my focus for the next two years. (That's kinda scary, actually)

The new system is infinitely better than the old one, IMHO. However, it requires extra work on a per-gauge basis to get the :V: gauges to conform to the new system. It doesn't implement a table, although it would probably be only moderately difficult to tie it into the hud_gauges.tbl system. Furthermore, key features like flashing are not implemented with the new system. The idea was to have it be possible to transparently swap the :V: system for the new HUD system. But that was, IIRC, starting to become something of a nightmare because of how hardcoded the :V: system was. Imagine the Beast from Homeworld infesting the FS2_Open HUD subroutines. That's kind of what it seemed like.

The NEW_HUD stuff also worked on the idea that the update functions for each hud gauge should not directly display the HUD media. This would allow the data to be cached and the image or text to simply be re-displayed without any calculations for each frame that the gauge didn't change.

At this point, it would be great to see some of those advancements hit the FS2_Open HUD system. But it would take a lot of work to get to a 'completed' point.

Summary[/u]
Adding gauges to hud_gauges.tbl is not as scary as it seems, once you figure it out. Beware the NEW_HUD defines.

[WMCoolmon]

Hmm...I didn't mean to scare everyone off.

[akenbosch]

its just that none of us understand that mass of code you call hudparse.h and hudparse.cpp.

[Cobra]

Have you even seen it? I really doubt you have.

[akenbosch]

yes

Code: [Select]

#ifndef NEW_HUD
//Set coord_x or coord_y to -1 to not change that value
//void resize_coords(int* values, float* factors);
//void set_coords_if_clear(int* dest_coords, int coord_x, int coord_y = -1);

//ADD YOUR VARIABLES HERE
//Gauges MUST come first, and all variables MUST be in the hud struct.

//Use this when setting gauge variables. It gets the OFFSET of the value in the hud_info struct
#define HUD_VAR(a) offsetof(hud_info, a)

gauge_info gauges[MAX_HUD_GAUGE_TYPES] = {
{ NULL, HUD_VAR(Player_shield_coords), "$Player Shield:", 396, 379, 634, 670, 0, 0, 0, 0, 0, -1, -1 },
{ NULL, HUD_VAR(Target_shield_coords), "$Target Shield:", 142, 379, 292, 670, 0, 0, 0, 0, 0, -1, -1 },
{ NULL, HUD_VAR(Shield_mini_coords), "$Shield Mini:", 305, 291, 497, 470, 0, HUD_VAR(Shield_mini_fname), 0, 0, 0, -1, -1 },
{ NULL, HUD_VAR(Aburn_coords), "$Afterburner Energy:", 171, 265, 274, 424, HUD_VAR(Aburn_size), HUD_VAR(Aburn_fname), 0, 0, 0, -1, -1 },
{ NULL, HUD_VAR(Wenergy_coords), "$Weapons Energy:", 416, 265, 666, 424, HUD_VAR(Wenergy_size), HUD_VAR(Wenergy_fname), 0, 0, 0, -1, -1 },
{ NULL, HUD_VAR(Wenergy_text_coords), "$Weapons Energy Text:", 439, 318, 708, 509, 0, 0, 0, 0, 0, -1, -1 },
{ NULL, HUD_VAR(Escort_coords), "$Escort List:", 486, 206, 865, 330, 0, HUD_VAR(Escort_filename[0]), 0, HUD_VAR(Escort_htext), 0, -1, -1 },

//Mini-gauges
{ &gauges[2], HUD_VAR(Hud_mini_3digit), "$Text Base:", 310, 298, 502, 477, 0, 0, 0, 0, 0, -1, -1 },
{ &gauges[2], HUD_VAR(Hud_mini_1digit), "$Text 1 digit:", 316, 298, 511, 477, 0, 0, 0, 0, 0, -1, -1 },
// { &gauges[2], HUD_VAR(Hud_mini_2digit), "$Text 2 digit:", 213, 298, 346, 477, 0, 0, 0, 0, 0, -1, -1 },
{ &gauges[2], HUD_VAR(Hud_mini_2digit), "$Text 2 digit:", 313, 298, 506, 477, 0, 0, 0, 0, 0, -1, -1 },
{ &gauges[5], HUD_VAR(Escort_htext_coords), "$Header Text:", 489, 208, 869, 331, 0, 0, 0, 0, 0, -1, -1 },
{ &gauges[5], HUD_VAR(Escort_list), "$List:", 0, 12, 0, 13, 0, 0, 0, 0, 0, HG_NOADD, -1 },
{ &gauges[5], HUD_VAR(Escort_entry), "$Ship:", 0, 11, 0, 11, 0, HUD_VAR(Escort_filename[1]), 0, 0, 0, HG_NOADD, -1 },
{ &gauges[5], HUD_VAR(Escort_entry_last), "$Last Ship:", 0, 11, 0, 11, 0, HUD_VAR(Escort_filename[2]), 0, 0, 0, HG_NOADD, -1 },
{ &gauges[5], HUD_VAR(Escort_name), "$Ship Name:", 3, 0, 4, 0, 0, 0, 0, 0, 0, HG_NOADD, -1 },
{ &gauges[5], HUD_VAR(Escort_integrity), "$Ship Hull:", 128, 0, 116, 0, 0, 0, 0, 0, 0, HG_NOADD, -1 },
{ &gauges[5], HUD_VAR(Escort_status), "$Ship Status:", -12, 0, -11, 0, 0, 0, 0, 0, 0, HG_NOADD, -1 }
};

[Cobra]

...Well, I'm speechless.

[Snail]

...Well, I'm speechless.

Aken is now backing up his claims.