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

Reply via email to