* Erik Hofman -- Thursday 15 June 2006 15:32:
> Melchior FRANZ wrote:
> > (a) an FGInstrumentMgr controlled class instance, and if so: should it
> > be moved to Instrumentation/HUD/?
>
> That's my preference, especially since it will be a completely
> overhauled version of the HUD code.
The default HUD could then be a HUD entry in
$FG_ROOT/Aircraft/Generic/generic-instrumentation.xml ...
<hud>
<name>hud</name>
<number>0</number> <!-- maybe some day an advanced UFO needs 2 HUDs :-) -->
<!-- <texture>Aircraft/f16/Models/hud.rgb</texture> -->
</hud>
that depends on electricity and <serviceable>. The <texture> entry could
be used once we have a *usable* render-to-texture HUD version. (My first
version wasn't that pretty.) This would then be the virtual texture that
can be mapped to a 3D HUD object of the aircraft model. Etc. etc.
> > (d) can I simply switch to properties, [...]
> I'm trying to guess how many newly created special HUD configurations
> can be. I think there are at least a few. So I would postpone dropping
> the old code to after 1.0 (maybe not even counting 1.x subversions).
OK. That makes sense. It could first output a warning on log level
"warning", then on "alert", and finally disappear. I'd also write
a section about the migration to properties.
> I would just copy the current code to a new location and rename it's
> class to maybe XMLHUD or something.
Hmm ... there is only one HUD, so I'd prefer just HUD (which is still
free as a class name). The XML prefix is as redundant as the "New" in
NewGUI will soon be. :-)
BTW: in case someone has looked at the current HUD files ... I left
quite some FIXME everywhere, and I will, of course, really fix those
soon, and also make other changes and improvments. So, don't panic. :-)
The HUD look/behaviour shouldn't have become worse. If you notice any
degradation, please shout in time! Well, there's one "degradation":
ticks and digits in the moving scales were before restricted to pixel
boundaries. This made them jump, which looked silly. Also the scale
ticks weren't evenly spaced because of that. I changed that, but now
digits can move "between" pixels, which may sometimes look like flicker.
If this is a problem, then I'd rather make it configurable, as the
current method is IMHO more correct.
m.
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
