On Tuesday 24 May 2005 18:32, Erik Hofman wrote:
> Durk Talsma wrote:
> > Maybe this is a good time time to formulate a though I've had for some
> > time now: With rumours of a possible 1.0.0 version sometime in 2005, I
> > don't think it's a good time to start digging into the basic architecture
> > of FlightGear. However, once version 1.0 is out, wouldn't that be an
> > excellent opportunity to carefully scrutinize the core architecture of
> > FlightGear and redesign it with the goal of ruducing interdependencies,
> > memory requirements, and improving startup time?
> I've been working on this regularly the in the past. It's not easy and I
> doubt it will gain much.
> However, I think the current airport reading code is just a mixture of
> code from the past adopted to read the new data. So it could be the code
> currently is reading one file more than once ...
Erik, you are of course in a far better position to judge this than me. As far
as I know, though there still seem to be a few design issues with the
FlightGear architecture that have evolved into what they are today, yet being
slightly less than ideal. For example, back in January (Jan 16) David Luff
and I descussed dependencies and counter dependencies on location, weather,
wind and location. I also seem to remember a similar depency and counter
dependency between startup location, time, and sun position.
Another issue that has been brought up a number of times is the ascii vs
binary file format disussion. While I absolutely believe that ascii/xml files
are ideal for development work, combined they may have a pretty big impact on
loading time. Therefore, would it be an idea to 'precompile' the .xml files
and use a binary version during runtime? I'm personally considering doing
this for the trafficManager files, because the parsing, initialization, and
checking against unknown airports is taking huge amounts of time.
Flightgear-devel mailing list