Curtis L. Olson > > Norman Vine writes: > > I am wondering what having multiple paths to search will do for 'stutter' > > > > and as far as LandMarks go I can't really see why they don't just go in the > > standard scenery file as since they are LandMarks they probably only > > apply to one location :-) > > It's more of an administrative convenience, not strictly necessary, > but useful for keeping the management of land mark development and > distribution under control.
Understood but these things of convenience have a habit of becoming more then what they started out life as :-) Since it seems as if creating Scenery is a popular thing these days my guess is that very shortly we will need to do some serious thinking about our naive use of flat files within the native file system as our data store. If and when we have a more 'compiled like' form of the scenery tree then having a multiple rooted path will make more sense to me as the 'developer's source tree' as the normal runtime FGFS will then use a FAST scenery repository. As an example of what this can mean on a WIN32 box one of my current jobs is tweaking an real time video image processing app that approx once in several frames (on ave. 5-10 times a second ) needs to save part of an image to disk. By changing from storing these images fragments into separate files to storing them in to a database I get a 'substantial' speedup primarily because I do not have to make all those expensive OS calls and am in essence just doing an expensive fwrite(). 'substantial' means that instead of 12 to 18 fps the program runs along happily meeting its 30fps target rate. I wouldn't expect much of a speedup by switching to a less fine grained scenery structure but I would expect substantially less 'stutter' < about the same proportion > Cheers Norman _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
