The current HUD code is a mishmash of animated clipping, multi-frame animations with individual frames overlaid over each other and gamma-controlled to show information, and other very interesting but somewhat obscure tricks.
I really think if you do anything with the HUD, you should aim to go far beyond what's in there now. The HUD is such a total waste of potential, because there's a lot of great bizarre gauges you could do with a little 2D knowledge and some 3D functions. It also practically hasn't been changed since Freespace 2 was released...even though the majority of it simple 2D functions. It's hard to deal with "the HUD" because it's so scattered and intertwined with the rest of the code, and incredibly hardcoded to boot. (Just check out the section of the code where it deals with the options screen for adjusting the brightness and settings of the various gauges....yuck.)
I wouldn't mind seeing any of that being changed. The current hud_gauges stuff is mostly a hack that tries to get around the convolutedness of the current code by just defining values to replace the ones that the original code uses. But it's not expected to be real consistent or flexible. If you add a 'text' field to the shield gauge, where ought it go? Should it be the same color? What font should it use? What coordinates should it use - relative to the gauge, relative to some corner of the screen, relative to
another gauge? Pretty soon you have enough options to use a significant number of variables and require a lot of code to deal with, none of which is really supported by the current HUD.
I think one way of dealing with this would be to define a standardized method for dealing with screen events that might impact the HUD, then develop some way of piping these events into gauges. That would be a ***** to do properly, but could be done cleverly...for example, a pipe to a text object generator that's connected to an autoscroller, so that the end result is to copy the current messaging window. That sort of thing would let you do HUD stuff in C space, rather than scripting or SEXP space, so you could work with what was coded in more efficiently.
Another route to go is with predefined gauge types (eg variable-height image, variable-transparency image, text, etc) whose attributes are settable via scripting, or SEXPs.
I think the base thing, though, is that I would hate to see something designed that's based on the current HUD. If it's flexible enough people will redesign the retail HUD. In fact, that's kind of ideal, because then you could distribute the scripting or configuration or whatever-file to people and they could tweak something that they're already familiar with. You could include it with the code, so you didn't have to rely on the hardcoded stuff and wouldn't have two separate ways of doing the same thing. Actually, I do think it's possible to convert a lot of the hardcoded stuff to use dynamic gauge names and such that would still be compatible with all missions.
Anyway, it's painful to me to read those threads because people get all worked up about things. "We're going to add in separate cockpit models" - that's about 15 lines of code. "We need to rip out the current way of doing cockpit models because it's stupid" - that's about 25 lines of code. The crux of that is 1 line in an if statement's conditional, the rest is just dealing with resetting the clipping plane and the code to toggle it from the table. Now, when you talk about all the nice little spoofs, showing damage and stuff, then you can add enough features to your heart's content and add as many lines of code as you want.
And when you talk about 3D hud gauges, you're talking about something else
entirely different from 3D cockpits.
That last thread especially really bugs me because it should not take 6-8 months to implement separate cockpit models. It probably literally took me longer to write this post than it would take to implement that feature. The only saving grace is that taylor talks about adding in LOD scaling and other nice features like that.
So detailed summary:
3D Cockpits as separate models: So easy that it's not even worth talking about anymore. I think after I finish this post, I'm just going to do it because I'm sick of people talking about it.
3D HUD Gauges: Also pretty easy. Freespace already has functions for drawing dots and lines and stuff in mission space for use with FRED. And obviously it can draw models in mission space too. So with a little use of model_find_world_point and some code in ship_render, after the ship- and cockpit- rendering stuff, you render your 3D gauges and presto! You can look around the cockpit and you have fixed 3D gauges (fixed relative to the ship, not to your view) floating in the air. If you're not happy with that, you just ignore the zbuffer and render them on top of whatever's there, and you can get 3D hud items much like the ship models in the targeting computer.
HUD gauges on 3D cockpits: bm_make_render_target. bm_set_render_target. Render gauge to your heart's content. bm_set_render_target(-1). Replace a texture on the 3D cockpit model with the render target texture. Rinse and repeat. (In fact you don't have to repeat bm_make or the texture replacement, just keep the texture handle around and re-render to it every time)
Another HUD management system: Priceless. And this is where the pain starts. Actually rendering 3D HUD gauges is already possible. But this is where you have to figure out how you're going to let the modder connect the data to the HUD gauges, and you have several options that involve tradeoffs between ease of use vs potential vs processing power.
This would be a perfect place for dual core stuff, in fact it may be the only place in Freespace 2 that dual core stuff would be practical to add, because the display is mostly passive and if it's off by even a half-second nobody cares.
You also have to figure out how to handle the retail HUD gauges. Are you going to leave them hardcoded and rewrite a completely new system that ignores the old code? Are you going to leave them hardcoded but integrate them into the new system? Or are you going to write the new system and then rewrite the retail gauges using the new system? How are you going to handle the options screen? What aspects will you give users to control vs modders vs mission-makers? Will you let any of these groups control what another group can do?
Will you allow interactivity with the HUD? How? Mouse/joystick/keyboard/TrackIR/speech?
How will you let people specify where HUD gauges go? Percentages? Pixels? Or will you let them use both? How will you let people specify if they need a hud gauge to move around, or be offset from a 3D object that may or may not be on the screen at a given time (eg the missile lockon indicator).
OK, I'll stop there so I don't scare you off. If I haven't already.
