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/PAEmem.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 ;=()
_________________________________________________________________
SEEK: Over 80,000 jobs across all industries at Australia's #1 job site.
http://ninemsn.seek.com.au?hotmail
_______________________________________________
Flightgear-devel mailing list
[email protected]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
