On Saturday, February 15, 2003, at 11:19 pm, Jim Wilson wrote:
The two possible options that come to mind are as follows:My plan was to add a bunch of new panel element types, though at some stage we are going to need some big chunks of custom code. For example, for the KLN-89b, the screen is essentially a 4-line, 20? character display, so I was figuring on an ncurses-like markup of fields, pages and lists, all of fixed character positions and dimensions. This will work really well for the [M]CDUs of big jets too.
1) Use the current 3D Modeling system.
2) Take code from the opengc project and change it so that it gets data
directly off our property system (property paths configurable). The idea then
would be to load these using Andy's panelnode code that currently loads the 2D
panel into 3D cockpits. I'm thinking that these could be special 2D panel
types and there could be a separate panel class (inherited from a general) for
each glass display. Any comments?
But even the KLN-89b has the dreaded NAV4 mode, which provides a graphical map of the flightplan, waypoints, airspace boundaries an so on. I was mentally planning to cross that bridge when I got to it, but obviously it'd be nice to share code with other similar displays.
Basically, I think the currently panel method (a tree of elements we place) is essentially right model (i.e declarative, not just procedural bits of openGL). We would need quite a few custom elements in this approach, and NAV (map) displays are a special problem, but I think the other stuff is pretty doable (tapes, number fields, artificial horizon) in a tuneable way. And would also map closely to a XML-ified HUD.
Indecisively,
James
--
The lack of planning on your part does not constitute to an emergency on mine
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
