Manuel Bessler wrote:
On Fri, Aug 06, 2004 at 01:54:06AM +0200, Boris Koenig wrote:
Of course, if there's running X11 on that other machine,
FlightGear could still provide the graphics for such an
externally displayed CDU via network without the need to
explicitly be running on that machine :-)
x11 yes, but what if not OpenGL capable.
well, in that specific example I was referring to the case
where a secondy machine would running dedicatedly for the
purpose of displaying a CDU for a FMS - so GENERALLY I would
doubt that for the display of a CDU there's any openGL
stuff necessary, I am not aware of any current CDUs that really
make use of advanced graphics - most CDUs could be really
implemented by using a simple alpha-numerical display mechanism
without the need to really draw advanced graphics.
That would exclude running
anthoer flightgear instance on that machine. (I'm thinking about old
cheap computers. Often those you can get for free)
I see - but even though this was mainly only a thought.I really
think that there's no need for any OpenGL requirements in order
to display something as trivial as a CDU.
Indeed, most of the graphics being displayed would be mainly
non-active, such as for example the keyboard graphics -
which at most _could_ be animated in very basic ways to
indicate that a button's been pressed.
The only thing that would really dynamically change during
runtime would be mainly the screen component on the virtual
CDU as well as some minor LED icons.
professional users who are building their own cockpits or
simply those users that are using those expensive external
standalone CDU units.
Or homebuilt cheap external CDUs :-)
don't know about these, if you've any experience with these
it might be interesting, maybe just for the sake of adding
support to deal with that stuff, there's probably some
basic specification using RS232 or USB for data exchange,
I'd guess ?
On the other hand I think one has to ponder about the pros & cons,
and certainly it would be more of an advantage for the AVERAGE
user to have a GENERAL xml-configurable mechanism to add support
for FMCs/CDUs to FlightGear than having merely a way to code
your own stuff by accessing the property tree via network.
Another idea I just had: Why not put all the general algorithms needed
in an average FMC into a library (possibly as part of SimGear).
Things like performance calculations, (access to) route databases, input
validation (eg: airport code exists?, does this airport have a runway
xxR?),routing calculations,...
SimGear itself is rather meant to provide a generic framework for
simulations - so, the things that you are mentioning would be rather
specific to flight simulator applications hence it would certainly
make more sense to directly integrate it into FG itself.
On the other hand, I really think that it's mainly about having on
the one hand the right data available and on the other hand doing
the right calculation with that data.
Most calculation can probably already be done using Nasal, there
were some examples on the Nasal webpage at plausible.org using
a maths function, IIRC.
Using a dynamic - non library-based - approach, possibly utilizing
Nasal for it, would probably be preferable if all the stuff is available
within the Nasal scope, that way one could easily borrow fragments of
code from other FMC implementations and add it to your own FMC.
Also, this would not require any changes to the FlightGear core, but
rather new additions to a FMC could easily be integrated using only
a scripting language.
So, you'd mainly want to have access to all the relevant data,
the first thing that comes to mind would be functions to
interactively retrieve data from the navaids/airports file
in order to deal with those value accordingly, I don't think
that Nasal can already retrieve such data !?
In order to really determine what data and functions to access
it would be necessary, one would first need to look into a
FMC manual and find out what data sources are being used to
compute the stuff, OR what -flightgear based data- could
ALTERNATIVELY be used for that purpose.
For example, one would certainly not want to create virtual
GPS or IRS units in order to simulate behaviour such as
mapshifts in the beginning.
Rather, one could directly use the positional data for these
computations.
---------
Boris
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
