On Saturday 22 Oct 2005 16:43, Geoff Air wrote: > Hi, > > I guess I should write MSVC7.1 ;=)) I am using the 2003, > version 7.1.3088 ... Have downloaded beta 2005, but still > to try this ... > > Thanks for the heads up about the 120km limit of the > renderer, Harald ... I will keep that in mind ... I > presume this is a constant defined in FG/SG/PLIB/?? > somewhere ... > > And thanks Andy, for the pointer - > > http://www.microsoft.com/whdc/system/platform/server/PAE/PAEme >m.mspx This explains it all ... a maximum of 2GB of process > memory, and 2GB for system memory, unless > you add /3GB to boot.ini *AND* reset the exe image using > Editbin.exe to set IMAGE_FILE_LARGE_ADDRESS_AWARE ... > which seems quite a lot of effort ... to gain an > extra GB ... but worth keeping in mind ... > > I had already experimented a little with the virtual > memory settings and discovered the 4GB LIMIT! And perhaps > now see why FG did NOT allow me to use my 200000, or > even 120000 ... even though windows had memory for > starting other memory hungry processes ... Word for > example ... > > It also perhaps explains why Word will also politely > reject say a paste operation, when copying in a large > site from IE ... by large here, I mean a site that > takes lots of memory to contain ... > > I can get a MEMORY ABORT ... it is a shame it does not > seem to set a memory error message that perror(...) sees ... > by just be removing the fog (--fog-disable), even with > the default visibility ... which is? > > So while the renderer might have a 120km (~75 miles) limit, > it is further reduced by the FOG ... at present, through > repeated experiments, the most I can push the fog > back is 45 miles (72420m) ... 50 miles produced an ABORT > after quite a number of minutes of flying ... aka tile > loading ... > > We could attack the tile manager ... but not suggesting > this literally, since it already does a good job ... it > could encase its 'new' in an exception handler, and > 'know' it is requesting too much memory ... and if a > distant tile, that it 'knows' can not really be rendered, > forget it, output a warning, or, remove (free) some of > the non-visible behind tiles ... but I agree, this is, > perhaps, way too complicated ... > > Also, if as Harald reports, the renderer has a hard > coded limit of 120km, then, at least, IGNORE a user > request for more ... what would be the use in loading > tiles out-of-range of the renderer, if there is such > a limit? > > The whole aim here is to produce an application that > withstands ALL user parameters entered ... especially > --fog-disable ... If I do not want REALISM, I want > to 'see' as far as possible ... then the application > should try to oblige ... IMHO ... > > Simply, I would prefer FG fly on, and not ABORT, just > because it passed the 2GB of process memory, in > WIN32. It is further assumed unix systems do not have > these constraints ... or a different set of memory > problems ... > > I would certainly be pleased if a *nix system user > could try - > --fog-disable > --visibility=120000 > Is no one else interested in 'seeing' as much of the > world as possible, as clear as possible, without > fog-blur? aka realism ... > > Anyway, I am happy, now I know the LIMITS, and will > try to work, quietly, within these constraints ;=)) > > Regards, > > Geoff. > > PS: I only get board messages in digest (batch) mode, > so may be behind what has been subsequently posted ;=()
Hello Geoff, just tried fgfs --fog-disable --visibility=120000 and it seemed to start ok. Didn't try flying as I'm just off out. This is on a Debian Linux system. LeeE _______________________________________________ Flightgear-devel mailing list [email protected] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
