David Megginson writes:
> Andy Ross writes:
>
> > Norman, this isn't constructive. Here are some things I'm quite
> > certain you don't want:
> >
> > + A velocity vector that doesn't point where the aircraft is going
see the discussion about the horizon below as to part of the problem
> > + HUD scaling that breaks with changes of aspect ratio
The scaling does NOT break with respect to aspect ratio
The display is designed to maintain 'local aspect ratio'
> > + HUD scaling that breaks with changes of resolution
see preceeding comment
> > + A horizon line that doesn't lie along the horizon
The horizon is in the middle of the screen
which is where the 'neutral' horizon should be
Someone has added a downward component
to the default 'Look Direction' which causes this
This is deflection is I believe a property thus tunable
> Perhaps the best solution will be to fork between the actual HUD
> (which should be 3D) and a screen-oriented 2D overlay module that uses
> the same configuration code to display things like frame-rate,
> network-connection status, etc. The beauty of configurability is that
> if Norm still wants to see the HUD ladder, etc. in 2D, it should be a
> simple matter to whip up an XML configuration file for it.
Yes the preexisting HUD code has been optimized to be just that a
screen-oriented overlay module and IMHO we do not want to lose
this module
Fortunately there is no need to fork
Someone just has to add a property as indicated below
void fgUpdateHUD( void ) {
// if(1) { // replace me with a property
if(fgGetBool("/sim/hud/use3d") {
fgUpdateHUDVirtual();
return;
}
* aside *
I submit that in general the 'proponent of a change' that will break
'long established' fgfs behaviour should consider ways to augment
rather then preclude the previous behaviour esp. in the case where
the vast majoriity of the code of the new behaviour is still the original
code such as this case.
FYI
The 2d HUD code is MUCH quicker then the Panel code and has
almost ZERO impact on framerate and IMHO should be kept intact as
the mechanism of choice for displaying general overlay information
either on the primary screen or on an external monitor. It is very useful
when using fgfs in 'magic mode' to inspect the scenery and I would
expect it to be the HUD of choice for other things like FDM monitoring,
flight reconstruction, inspector consoles etc.
Note this in no way precludes using Andy's 3D HUD patch which BTW
should also have ~zero impact on frame rate since all the real work is
still being done by the underlying screen-oriented module which hasn't
changed
Regards
Norman
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
