[Flightgear-devel] RE: Two problems - 1 easy and 1 hard! - in XP using MSVC7
Hi, Thanks LeeE (Debian) and Oliver C. (Linux) for your --fog-disable --visability=12 tries ... this is almost, I say ALMOST, enough to get me to switch to a *nix system ;=)) =IF= I had got my no fog, maximum visibility, and disabled clouds, running, one of my next questions would have been - Why is it ALWAYS so dark in the distance? ;=/ This can be at noon, and it is the same all around ... and even if the sun is more over the distance scene, morning or evening, it is ALWAYS rendered black in the distance, except when fog is enabled ... then it is rendered all white ... ;=)) Judging by the size of the 'squares' on the ground, I guess Oliver's image must be from about 4 feet, and when I climb to this height I get a TOTAL BLACK scene below me ... only when I descend does the ground become lighted ... This is with the default visibility, whatever that is, and no fog ... of course, if I set the visibility to 6m, the MAXIMUM I can use without getting a memory ABORT, then looking straight down, the ground is lighted, but the distance is BLACK ... It definitely feels as if the lighting effect is taken from the position of the viewing aircraft, and certainly not from the actual position of the sun ... But, for the moment, I must settle for my windows less memory ;=(( Regards, Geoff. PS: I have put some images on this page - http://geoffmclane.com/fg/fgfs-017.htm since it is quite hard to explain ... It also includes my OpenAL change, and other things ... see separate post ... EOF _ REALESTATE: biggest buy/rent/share listings http://ninemsn.realestate.com.au ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RE: Two problems - 1 easy and 1 hard! - in XP using MSVC7
Geoff Air wrote: Hi, Thanks LeeE (Debian) and Oliver C. (Linux) for your --fog-disable --visability=12 tries ... this is almost, I say ALMOST, enough to get me to switch to a *nix system ;=)) =IF= I had got my no fog, maximum visibility, and disabled clouds, running, one of my next questions would have been - Why is it ALWAYS so dark in the distance? ;=/ This can be at noon, and it is the same all around ... and even if the sun is more over the distance scene, morning or evening, it is ALWAYS rendered black in the distance, except when fog is enabled ... then it is rendered all white ... ;=)) Judging by the size of the 'squares' on the ground, I guess Oliver's image must be from about 4 feet, and when I climb to this height I get a TOTAL BLACK scene below me ... only when I descend does the ground become lighted ... This is with the default visibility, whatever that is, and no fog ... of course, if I set the visibility to 6m, the MAXIMUM I can use without getting a memory ABORT, then looking straight down, the ground is lighted, but the distance is BLACK ... It definitely feels as if the lighting effect is taken from the position of the viewing aircraft, and certainly not from the actual position of the sun ... Ok, --disable-fog does *not* disable fog. Try this ;-) cvs -z3 diff -u -- renderer.cxx (in directory F:\dvlp\FG\source\src\Main\) @@ -472,7 +477,9 @@ glEnable( GL_FOG ); glFogi( GL_FOG_MODE, GL_EXP2 ); glFogfv( GL_FOG_COLOR, l-adj_fog_color() ); -} +} else +glDisable( GL_FOG ); + Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RE: Two problems - 1 easy and 1 hard! - in XP using MSVC7
On Saturday 22 Oct 2005 18:53, Oliver C. wrote: On Saturday 22 October 2005 19:09, Lee Elliott wrote: Hello Geoff, just tried fgfs --fog-disable --visibility=12 and it seemed to start ok. Didn't try flying as I'm just off out. This is on a Debian Linux system. LeeE I tried it too. It works okay running at about 7-11 fps on an Athlon 2000+, 1 GB Ram and Geforce 4200 Ti 64 MB on a Linux Slackware 10.0 machine. But the lightning is wrong, it is too dark in the far distance at midday. See screenshot: http://img460.imageshack.us/my.php?image=fgfsdark3xu.jpg Best Regards, Oliver C. Do you mean that the sky colour is wrong? That's a bit of a difficult one to assess because at low altitudes we always see through a lot of atmosphere. Setting no fog is a bit like removing _all_haze from the view, which is something you'll never see in real life, except perhaps at very high altitudes. Removing the fog is a bit like elevating your altitude. It may not be perfect but you'd be hard pressed to do much better with a fully featured ray-traced renderer, let alone OpenGL. Don't get me wrong, with ray-tracing you could account for variable refractive index and scattering based on altitude and wavelength but it would take a long time. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] RE: Two problems - 1 easy and 1 hard! - in XP using MSVC7
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 20, or even 12 ... 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=12 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 Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RE: Two problems - 1 easy and 1 hard! - in XP using MSVC7
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 20, or even 12 ... 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=12 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=12 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 Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Two problems - 1 easy and 1 hard! - in XP using MSVC7
So, maybe I can increase the swap file size, and certainly REDUCE my very unreasonable visibility, 20 meters, or BOTH ... The renderer uses an hardcoded far plane of 120 km so with a visibility 120k you load more tiles in memory but you can't see them. Note, Windows is not completely out of memory, since I was able to open Word, and commence writing this, while still in the debugger ... with several other windows open ... ??? Perhaps that the system allows *only* 1GB per process ;-) Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Two problems - 1 easy and 1 hard! - in XP using MSVC7
Harald JOHNSEN wrote: Geoff Air wrote: Note, Windows is not completely out of memory, Perhaps that the system allows *only* 1GB per process ;-) That's an interesting point. A quick google comes up with this MSDN page that seems to indicate that XP uses a 2/2 split of process address space, with an optional boot flag that will get you to 3G. http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Two problems - 1 easy and 1 hard! - in XP using MSVC7
Thank you, Harald for your quick reply ...
1. Easy fix - line endings
Glad you could confirm my CVS check out ... but the
suggested code fix takes care of it, which ever line
endings there are in zone.tab ;=))
2. Hard find - ABORT
Thank you for the Debug menu pointer ... I had not found
MSVC very good with exceptions, in the distant past,
but it has really improved ...
Trapping the exception, and returning to the debugger, the
Call Stack showed, in part, the simple answer ...
FlightGear.exe!_nh_malloc_dbg(unsigned int nSize=1, int nhFlag=3, int
nBlockUse=1235168, const char * szFileName=0x0012d9ec, int nLine=1242460)
Line 267 + 0x7
FlightGear.exe!_CxxThrowException(void * pExceptionObject=0x0012d8fc, const
_s__ThrowInfo * pThrowInfo=0x00e95db0) + 0x39
FlightGear.exe!std::_Nomemory() Line 10
FlightGear.exe!operator new(unsigned int size=73056) Line 15
...
FlightGear.exe!FGTileMgr::update(SGLocation * location=0x201ac898, double
visibility_meters=20.000) Line 437
And of course, passing the exception back to FG, I end up
at the lines in bootstrap.cxx -
} catch (...) {
cerr Unknown exception in the main loop. Aborting... endl;
perror(Possible cause);
}
The console last few lines showed, confirming the call stack -
FGTileMgr::update()
State == Running
Loading tile
C:/FG0981/FlightGear/data/Scenery/Terrain/e000n40/e001n47/2974291
token = OBJECT_BASE name = 2974291.btg
So these ABORTS were a SIMPLE case of OUT-OF-MEMORY, of a
certain type ... This is the very first time I have found
Windows wanting in the memory allocation area ... I
thought the virtual memory was virtually unlimited ;=))
well, depending only on settings, and HDD size ...
So, maybe I can increase the swap file size, and
certainly REDUCE my very unreasonable visibility,
20 meters, or BOTH ...
Note, Windows is not completely out of memory,
since I was able to open Word, and commence writing
this, while still in the debugger ... with several
other windows open ... ???
Removing my unrealistic 20 from my system.fgfsrc
file, thus allowing the default visibility, and I could
fly around, with fog, and sky-blend, all day ;=))
I took off from Orly, flew generally NNW, and ended up
at Lands End, with some help from Google Earth ...
followed the southern coast around to Manston,
then left into Heathrow, over London, then
took about a 160 track, hit the French coast at 49 48'N,
0 30'E, adjusted to 135 track, and back to Orly, after
some other adjustments ...
Over 2 hours of UFO flying ... sometimes at many times the
speed of sound ... stoping here and there to look around,
identify an airport, etc, and not a single ABORT ...
Checking my virtual memory options, I note it has
a maximum size of 1536MB, with 1534MB currently
allocated! ... since I have 30 plus GB left on the
drive, maybe I could increase the maximum ... and be
flying in clear air, with extreme visibility ...
but will experiment with that another day ;=))
Thank you ... thank you ... thank you
I have certainly learned a lesson about push the
parameters ... if you want clear air and long distant
vision, be careful about MEMORY ABORTS ;=)) I kind
of knew it had something to do with my system.fgfsrc
preferences ...
So, the problem is sort of solved ... back to
quiet flying ... thanks again
Regards,
Geoff.
EOF
_
REALESTATE: biggest buy/rent/share listings
http://ninemsn.realestate.com.au
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Two problems - 1 easy and 1 hard! - in XP using MSVC7
In regards to #2. Hard find - ABORT
Question, which version of MSVC7 are you using?
7.0 is .net 2002, 7.1 is .net 2003
I was having a memory allocation error in one application that I was using
.net 2002 (7.0) on that I could not solve. After upgrading to .net 2003 (7.1),
the memory allocation problem went away, in other words, it was a
compiler problem.
-- Original message -- Thank you, Harald for your quick reply ... 1. Easy fix - line endings Glad you could confirm my CVS check out ... but the suggested code fix takes care of it, which ever line endings there are in zone.tab ;=)) 2. Hard find - ABORT Thank you for the Debug menu pointer ... I had not found MSVC very good with exceptions, in the distant past, but it has really improved ... Trapping the exception, and returning to the debugger, the Call Stack showed, in part, the simple answer ... FlightGear.exe!_nh_malloc_dbg(unsigned int nSize=1, int nhFlag=3, int nBlockUse=1235168, const char * szFileName=0x0012d9ec, int nLine=1242460) Line 267 + 0x7 FlightGear.exe!_CxxThrowException(void * pExceptionObject=0x0012d8fc, const _s__ThrowInfo * pThrowInfo=0x00e95db0) + 0x39 FlightGear.exe!std::_Nomemory() Line 10 FlightGear.exe!operator new(unsigned int size=73056) Line 15 ... FlightGear.exe!FGTileMgr::update(SGLocation * location=0x201ac898, double visibility_meters=20.000) Line 437 And of course, passing the exception back to FG, I end up at the lines in bootstrap.cxx - } catch (...) { cerr "Unknown exception in the main loop. Aborting..." endl; perror("Possible cause"); } The console last few lines showed, confirming the call stack - FGTileMgr::update() State == Running Loading tile C:/FG0981/FlightGear/data/Scenery/Terrain/e000n40/e001n47/2974291 token = OBJECT_BASE name = 2974291.btg So these ABORTS were a SIMPLE case of OUT-OF-MEMORY, of a certain type ... This is the very first time I have found Windows wanting in the memory allocation area ... I thought the virtual memory was virtually unlimited ;=)) well, depending only on settings, and HDD size ... So, maybe I can increase the swap file size, and certainly REDUCE my very unreasonable visibility, 20 meters, or BOTH ... Note, Windows is not completely out of memory, since I was able to open Word, and commence writing this, while still in the debugger ... with several other windows open ... ??? Removing my unrealistic 20 from my system.fgfsrc file, thus allowing the default visibility, and I could fly around, with fog, and sky-blend, all day ;=)) I took off from Orly, flew generally NNW, and ended up at Lands End, with some help from Google Earth ... followed the southern coast around to Manston, then left into Heathrow, over London, then took about a 160 track, hit the French coast at 49 48'N, 0 30'E, adjusted to 135 track, and back to Orly, after some other adjustments ... Over 2 hours of UFO flying ... sometimes at many times the speed of sound ... stoping here and there to look around, identify an airport, etc, and not a single ABORT ... Checking my virtual memory options, I note it has a maximum size of 1536MB, with 1534MB currently allocated! ... since I have 30 plus GB left on the drive, maybe I could increase the maximum ... and be flying in clear air, with extreme visibility ... but will experiment with that another day ;=)) Thank you ... thank you ... thank you I have certainly learned a lesson about push the parameters ... if you want clear air and long distant vision, be careful about MEMORY ABORTS ;=)) I kind of knew it had something to do with my system.fgfsrc preferences ... So, the problem is sort of solved ... back to quiet flying ... thanks again Regards, Geoff. EOF _ REALESTATE: biggest buy/rent/share listings http://ninemsn.realestate.com.au___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
