Re: [Flightgear-devel] Main Airports Conflict with Graphic Card 6600GT !!!
Gerard ROBIN wrote: I will tell you the most FGFS incredible history: I have discovered a conflict between main Airports and the Nvidia graphic card 6600GT. I cannot explain what and why. Does anybody can help me to understand ? With the last Nvidia driver (7664) that graphic card perform fgfs at a 70 fps speed and decrease to suddenly 2 fps. Gerard, A few of us have had that problem. One solution, as pointed out by Melchior is to go back to 6629 drivers. If you're running 2.6.11 kernel you will have to patch them as per the instructions at: http://www.nvnews.net/vbulletin/showthread.php?t=46676 Though I didn't try the other solution suggested to turn off enhanced runway lighting, which would certainly be easier. The 6629 drivers also give better performance with the torcs driving sim so I'll stick with them for now. Geoff ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Strange acceleration issues with 9.8---possibly
Lee Elliott wrote: On Thursday 26 May 2005 19:56, Lee Elliott wrote: On Thursday 26 May 2005 02:50, Geoff Reidy wrote: Lee Elliott wrote: I'm having a strange problem that may be linked to this. Now when I start at KSFO, looking forward, I'm getting 1fps. Same with the heli chase views. If I switch to the tower it's the same until I start zooming in. At around 15 deg fov the frame rate jumps up to around 25-30 fps. Switch back to the chase view and it's back down to 1 fps. Incidentally, the a/c I'm checking with has slowly revolving props so I can see the changes in frame rate very clearly. Anyway, back to the chase view and rotate the view around using shift and the num-pad. Shift-9 is fine - 20 fps, shift-6 1 fps, shift-3 20 fps. From 2 through to 8 are all 1 fps. Try KJFK. Here only one view gives problems (can't remember exactly which one now though). It's also apparent while using the mouse to change the view. Back to KSFO, tower view and try a take off - 20 fps. Try chase view and 1 fps until just after the last of the white blocks on the runway (sorry, don't know their proper name) when it jumps to 20 fps. It'll also happen while I'm flying - I flew out over downtown SFO and was heading back to KSFO at 20 fps but then it dropped back down to 1fps. I'm guessing that it's due to a scenery or random object problem, as it also happened at KJFK where there're no custom scenery objects, but I can't identify what it can be. Any ideas anyone? FG is pretty unusable for me atm. FWIW, glxgears gives 3900 fps here. LeeE I get this problem also with any of the Nvidia Linux 7xxx drivers. Other programs like torcs still run fine, only fgfs seems to be affected. I used to get 30 to 40 fps at KSFO. If I look down at the cockpit (still at KSFO) or up at the sky or I look to the right more than about 15 degrees or to the left at about 90 degrees it runs at normal speed. Look straight ahead and I get about 1 frame every five seconds. Same result at KEMT. Have looked through the nvidia forums but haven't seen anyone complain of problems like this. Geoff Thanks for that Geoff. I've already got a couple of older drivers and I believe that all the old drivers can still be downloaded from the archive at nVidia. I'll give it a go here and report back. LeeE I have three version here 7174, 7167 6629. Both of the 7nnn exhibit the same problem and 6629 won't compile here. Drat! Which kernel version are you using? I'm on 2.6.11 here. LeeE 2.6.11 and also can't build the older drivers, as I since found out :( Just updated from 2.6.9 where only = 6629 worked properly with fgfs. Debian unstable. Geoff ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Strange acceleration issues with 9.8---possibly
Melchior FRANZ wrote: I compile and use 6629 with Linux 2.6.11.7 without problems. You only need to patch the driver source with an official nvidia patch: http://www.nvnews.net/vbulletin/showthread.php?t=46676 Thanks, will give that a go. PS: please, no fullquotes! Only quote what you are directly referring to. Sorry bout that! ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Strange acceleration issues with 9.8---possibly
Melchior FRANZ wrote: I compile and use 6629 with Linux 2.6.11.7 without problems. You only need to patch the driver source with an official nvidia patch: http://www.nvnews.net/vbulletin/showthread.php?t=46676 OK that's fixed my issues, thanks Melchior! ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Strange acceleration issues with 9.8---possibly
Lee Elliott wrote: I'm having a strange problem that may be linked to this. Now when I start at KSFO, looking forward, I'm getting 1fps. Same with the heli chase views. If I switch to the tower it's the same until I start zooming in. At around 15 deg fov the frame rate jumps up to around 25-30 fps. Switch back to the chase view and it's back down to 1 fps. Incidentally, the a/c I'm checking with has slowly revolving props so I can see the changes in frame rate very clearly. Anyway, back to the chase view and rotate the view around using shift and the num-pad. Shift-9 is fine - 20 fps, shift-6 1 fps, shift-3 20 fps. From 2 through to 8 are all 1 fps. Try KJFK. Here only one view gives problems (can't remember exactly which one now though). It's also apparent while using the mouse to change the view. Back to KSFO, tower view and try a take off - 20 fps. Try chase view and 1 fps until just after the last of the white blocks on the runway (sorry, don't know their proper name) when it jumps to 20 fps. It'll also happen while I'm flying - I flew out over downtown SFO and was heading back to KSFO at 20 fps but then it dropped back down to 1fps. I'm guessing that it's due to a scenery or random object problem, as it also happened at KJFK where there're no custom scenery objects, but I can't identify what it can be. Any ideas anyone? FG is pretty unusable for me atm. FWIW, glxgears gives 3900 fps here. LeeE I get this problem also with any of the Nvidia Linux 7xxx drivers. Other programs like torcs still run fine, only fgfs seems to be affected. I used to get 30 to 40 fps at KSFO. If I look down at the cockpit (still at KSFO) or up at the sky or I look to the right more than about 15 degrees or to the left at about 90 degrees it runs at normal speed. Look straight ahead and I get about 1 frame every five seconds. Same result at KEMT. Have looked through the nvidia forums but haven't seen anyone complain of problems like this. Geoff ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [RFC] swap chase views
Melchior FRANZ wrote: * Jim Wilson -- Wednesday 11 May 2005 03:38: Melchior FRANZ wrote: Anyone preferring Helicopter View? Yes, me. While the Chase view is a nice demonstration of the viewer code, I think most people prefer the Helicopter view because it doesn't have the problem of the view going out of sync with gravity. Oh. This is very suprising, if not to say shocking. The Helicopter View doesn't resemble *any* real-life view. Not even if you are sitting in the last row of a 747 you'll get anything like that. I tend to agree with Erik. I don't use the helicopter or chase view for a more realistic experience. Huh? The more realistic is without any doubt the Chase View, which I prefer. Erik prefers the Helicopter View nevertheless. You prefer neither? Anyway: I thought this was a no-brainer, and that the current setting was just a left-over from past times. (And I assume Erik meant most people who prefer Helicopter, prefer it because ..., not that most people prefer that awkward view.) I'll just continue to apologize to every new user about this and won't bring it up again. So much for usability ... :-/ m. PS: thanks for bothering to reply to all my RFCs! I guess I'm out of ideas now. :-) If an old user can pipe up, I prefer the chase view if I'm in spectator mode, such as watching a replay or on autopilot but if I'm flying and want an outside view then I'll use the helicopter view. Doing acrobatics in chase mode can be pretty hairy :) Mostly if I'm flying though I will be in the cockpit so I personally wouldn't mind if chase view was promoted. One vote for. Also I'd like to say the new 3d clouds and start up sequence are great. Also I've got some pretty nice screen shots taken at 1400x1050 with anti-aliasing and with the 3d clouds that I could put on a web page if they could be useful. Geoff ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [RFC] swap chase views
Curtis L. Olson wrote: Geoff Reidy wrote: Also I've got some pretty nice screen shots taken at 1400x1050 with anti-aliasing and with the 3d clouds that I could put on a web page if they could be useful. Send them over and if they meet some minimal level of aethetics I'll get them posted. Regards, Curt. Okay I've put them up, they are 1400x1050 jpegs at highest quality so are about 1 meg each. Let me know if you want them downsized or reduced in quality. http://home.pacific.net.au/~reidygh/fgfs/fgfs-screen-016.jpg http://home.pacific.net.au/~reidygh/fgfs/fgfs-screen-018.jpg http://home.pacific.net.au/~reidygh/fgfs/fgfs-screen-028.jpg http://home.pacific.net.au/~reidygh/fgfs/fgfs-screen-032.jpg http://home.pacific.net.au/~reidygh/fgfs/fgfs-screen-035.jpg http://home.pacific.net.au/~reidygh/fgfs/fgfs-screen-037.jpg http://home.pacific.net.au/~reidygh/fgfs/fgfs-screen-039.jpg http://home.pacific.net.au/~reidygh/fgfs/fgfs-screen-049.jpg http://home.pacific.net.au/~reidygh/fgfs/fgfs-screen-050.jpg http://home.pacific.net.au/~reidygh/fgfs/fgfs-screen-051.jpg http://home.pacific.net.au/~reidygh/fgfs/fgfs-screen-053.jpg Hmmm, seems to have filled up my web page. Have some nice ones of the ornithopter flapping it's way over San Fran but they're possibly not realistic. Regards, Geoff ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [RFC] swap chase views
Ampere K. Hardraade wrote: What kind of graphic cards do you have?! Ampere It's an Nvidia 6600gt, more specifically a Leadtek 6600gt tdh. Nice card and I think the 6600gts are the best bang-for-the-buck card at the moment on linux at least. Having said that the first card I got was defective and I had to get it replaced. Geoff ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] crease for ac3d files and speedup
Lee Elliott wrote: Hmm... Now I'm getting: config.status: error: cannot find input file: simgear/scene/fgsg/Makefile.in Making all in src-libs make[1]: Entering directory `/common/cvs/CVSROOT/SimGear/src-libs' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/common/cvs/CVSROOT/SimGear/src-libs' Making all in simgear make[1]: Entering directory `/common/cvs/CVSROOT/SimGear/simgear' cd .. /bin/sh ./config.status simgear/simgear_config.h config.status: creating simgear/simgear_config.h make all-recursive make[2]: Entering directory `/common/cvs/CVSROOT/SimGear/simgear' Making all in xml make[3]: Entering directory `/common/cvs/CVSROOT/SimGear/simgear/xml' make[3]: *** No rule to make target `all'. Stop. make[3]: Leaving directory `/common/cvs/CVSROOT/SimGear/simgear/xml' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/common/cvs/CVSROOT/SimGear/simgear' make[1]: *** [all] Error 2 make[1]: Leaving directory `/common/cvs/CVSROOT/SimGear/simgear' make: *** [all-recursive] Error 1 ...sure enough, there's nothing in ~CVSROOT/simgear/scene/fgsg - the directory's empty. :( LeeE Hi, you need to remove references to fgsg from configure.ac and simgear/scene/Makefile.am then it should build ok. Geoff ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Video card recommendation
Paul Surgeon wrote: Does FG run well on a FX 5200? Thanks Paul Be careful if you get a 5200. Some of them have a 128 bit memory bus and others have a 64 bit memory bus, so having half the memory bandwidth. They often have the same model number and unless it is explicitly stated that it is a 128 bit card it is probably a 64 bit job. I got a Leadtek A340TDH (128 bit memory bus) which has 4ns ram and can run the memory at 580MHz vs 400Mhz default using nvclock. The performance increase is pretty much linear showing that memory bandwidth is the main bottleneck of the card. Runs flightgear quite nicely though it bogs down a little bit at KSFO with 3d clouds enabled, drops to about 15fps depending on the plane, 24 bit colour at 1024x768. Much as I dislike binary drivers it is quite stable. $ uptime 09:32:53 up 32 days, 9:24, 8 users, load average: 0.15, 0.04, 0.01 Regards, Geoff ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound probs
Matevz Jekovec wrote: Over the past couple of weeks, I've been having problems with the sound in FG. I get this message: slDSP: getBufferInfo: Broken pipe on the terminal and lose the sound altogether. My audio apps and tuxracer work fine, so I suspect an FG or plib issue. This is from yesterday's CVS of FG, SG, and plib. Any ideas? I have the same problem and I'm playing without sound the last few *months* :(. I have SB Live! and ALSA. Do you use ALSA too? Yes, I'm using 0.9.6 and my sound card is a C-Media CM8738. Have you tried any other plib-based programs? Well, it appears to be something about the way FG is doing sound. tux_aqfh works just fine against cvs plib (you have to add -lplibjs to the makefile, though) Yes, it's only Alsa-FG issue then. Other plib programs work fine for me too. Did you try echo fgfs 0 0 direct /proc/asound/card0/pcm0p/oss echo fgfs 0 0 disable /proc/asound/card0/pcm0c/oss where card0 is your sound card which fgfs use? I tried it, but had no joy... But I'm having this strange feeling why are we the very few which have this Alsa problems. What about the others, Erik, Curtis, Norman, Frederic, Jim, LeeE?? Which driver/card are you using and does sound work for you normally? Not had any problems here: cat /etc/redhat-release ; uname -a ; cat /proc/pci |grep -B1 -A3 audio ; /sbin/lsmod |grep cmi ; cat /proc/asound/version Mandrake Linux release 9.0 (dolphin) for i586 Linux Vogon 2.4.21-pre5-ac3 #2 Mon Mar 24 09:55:22 EST 2003 i686 unknown unknown GNU/Linux Bus 0, device 5, function 0: Multimedia audio controller: C-Media Electronics Inc CM8738 (rev 16). IRQ 10. Master Capable. Latency=32. Min Gnt=2.Max Lat=24. I/O at 0xd800 [0xd8ff]. snd-cmipci 19968 2 (autoclean) snd-mpu401-uart 3264 0 (autoclean) [snd-cmipci] snd-pcm59840 0 [snd-cmipci snd-pcm-oss] snd-opl3-lib6788 0 [snd-opl3-synth snd-cmipci] snd31268 1 [snd-seq-midi snd-opl3-synth snd-seq-instr snd-cmipci snd-mpu401-uart snd-rawmidi snd-seq-oss snd-seq-midi-event snd-seq snd-pcm-oss snd-mixer-oss snd-pcm snd-opl3-lib snd-hwdep snd-timer snd-seq-device] Advanced Linux Sound Architecture Driver Version 0.9.1. Compiled on Aug 13 2003 for kernel 2.4.21-pre5-ac3 with versioned symbols. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Under the bridge
Norman Vine wrote: For those that want to fly under the bridges /// scenery.cxx Hey I like it, once I figured out the change only involves uncommenting a line in tilemgr.cxx. Only catch is I can't fly between buildings anymore. Or have I missed something? Regards, Geoff ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Under the bridge
Norman Vine wrote: Jim Wilson writes: BTW It didn't seem that taxiing on the bridge was working with the current code. I didn't pursue the issue with other things more pressing. But I'm wondering, has anyone else been able to do so? Does the carrier landing work with the current code? I haven't tried the bridge but landing on a carrier should still work i.e. you should be able to test this by psoitioning yourself such that you start up ontop of the terminal building :-) Cheers Norman Tried landing on the long bridge (not the golden gate). If you touch down very softly it seems to work, the wheels squeal and you can apply brakes but then you start to sink through the surface, then it's like you hit something and get bounced up into the air again. This is with the standard cvs code and the c310-3d. While I was playing around I managed to take off upside down in the c310 :) Geoff ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Bug in menu code?
Maybe it's just me but when I click on the menu and slowly bring the
cursor down I can get two options highlighted.
Clicking the mouse at this point freezes the program completely and I
have to kill it.
Happens with any of the menu options.
Haven't been able to figure out why it's happening, thought I'd better
mention it with a release coming out.
Seems to get stuck in an endless loop in the menu code:
318 int isEmpty ( void ) const { return min[0]max[0] ||
min[1]max[1] ; }
(gdb)
33if ( min[0]bx-min[0] ) min[0] = bx-min[0] ;
(gdb)
34if ( min[1]bx-min[1] ) min[1] = bx-min[1] ;
(gdb)
35if ( max[0]bx-max[0] ) max[0] = bx-max[0] ;
(gdb)
36if ( max[1]bx-max[1] ) max[1] = bx-max[1] ;
(gdb)
37 }
(gdb)
puGroup::recalc_bbox() (this=0x88d42d0) at pu.h:666
666 puObject*getNextObject ( void ) const{ return next ; }
(gdb)
324 for ( puObject *bo = dlist ;
(gdb)
666 puObject*getNextObject ( void ) const{ return next ; }
(gdb)
600 puBox *getBBox ( void ) const { return (puBox *) bbox ; }
(gdb)
puBox::extend(puBox*) (this=0x88dc218, bx=0xb100) at pu.h:318
318 int isEmpty ( void ) const { return min[0]max[0] ||
min[1]max[1] ; }
(gdb)
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug in menu code?
Ah, that makes sense.
Have to say there seems to have been a big improvement in memory
consumption lately, had the program running for over 33 hours now and I
can switch views without any hard drive thrashing at all, very nice.
Curtis L. Olson wrote:
I believe this is a plib bug ...
Geoff Reidy writes:
Maybe it's just me but when I click on the menu and slowly bring the
cursor down I can get two options highlighted.
Clicking the mouse at this point freezes the program completely and I
have to kill it.
Happens with any of the menu options.
Haven't been able to figure out why it's happening, thought I'd better
mention it with a release coming out.
Seems to get stuck in an endless loop in the menu code:
318 int isEmpty ( void ) const { return min[0]max[0] ||
min[1]max[1] ; }
(gdb)
33if ( min[0]bx-min[0] ) min[0] = bx-min[0] ;
(gdb)
34if ( min[1]bx-min[1] ) min[1] = bx-min[1] ;
(gdb)
35if ( max[0]bx-max[0] ) max[0] = bx-max[0] ;
(gdb)
36if ( max[1]bx-max[1] ) max[1] = bx-max[1] ;
(gdb)
37 }
(gdb)
puGroup::recalc_bbox() (this=0x88d42d0) at pu.h:666
666 puObject*getNextObject ( void ) const{ return next ; }
(gdb)
324 for ( puObject *bo = dlist ;
(gdb)
666 puObject*getNextObject ( void ) const{ return next ; }
(gdb)
600 puBox *getBBox ( void ) const { return (puBox *) bbox ; }
(gdb)
puBox::extend(puBox*) (this=0x88dc218, bx=0xb100) at pu.h:318
318 int isEmpty ( void ) const { return min[0]max[0] ||
min[1]max[1] ; }
(gdb)
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] cvs compile error
Hi, Got some errors trying to compile current cvs with gcc-3.2 on Mandrake 9.0. This fixed it: Index: src/FDM/ExternalPipe/ExternalPipe.cxx === RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/FDM/ExternalPipe/ExternalPipe.cxx,v retrieving revision 1.3 diff -r1.3 ExternalPipe.cxx 131c131 result = std::write( pd1, cmd, strlen(cmd) ); --- result = write( pd1, cmd, strlen(cmd) ); 137c137 result = ::write( pd1, cmd, strlen(cmd) ); --- result = write( pd1, cmd, strlen(cmd) ); 143c143 result = std::write( pd1, cmd, strlen(cmd) ); --- result = write( pd1, cmd, strlen(cmd) ); 149c149 result = std::write( pd1, cmd, strlen(cmd) ); --- result = write( pd1, cmd, strlen(cmd) ); 155c155 result = std::write( pd1, cmd, strlen(cmd) ); --- result = write( pd1, cmd, strlen(cmd) ); 161c161 result = std::write( pd1, cmd, strlen(cmd) ); --- result = write( pd1, cmd, strlen(cmd) ); 173c173 result = std::write( pd1, cmd, strlen(cmd) ); --- result = write( pd1, cmd, strlen(cmd) ); 206c206 result = std::write( pd1, buf, length + 1 ); --- result = write( pd1, buf, length + 1 ); 214c214 result = std::read( pd2, (char *)( fdm), length ); --- result = read( pd2, (char *)( fdm), length ); ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [PATCH] switching views (trivial)
Martin Spott wrote: [... Geoff Reidy wrote ...] Jim Wilson wrote: It's been done for a couple weeks now. I'll try and get it together and submit the changes in the next day or two. Got the best of both worlds now :) v forward cycle shift-v reverse cycle control-v return to view 0 Should this be working already ? The current CVS tree does not contain this funcionality. I have: v: forward cycle shift-v: return to view 0 control-v: jump to some view following a schema I did not understand ;-) May this probably be related to different keyboard layouts (I have a german layout ) ? Martin. P.S.: There are similar issues with the magneto switches who don't follow the intended layout on non-English keyboards: I have to key AltGr-Q before I can dial the second magneto switch on a C-310 (instead of Shift-2), Martin, It's just a modification I made locally. I found switching through the tower views would tend to stall things if fgfs had been running for a while so I wanted a way to avoid that. The patches referred to in my original mail should apply cleanly to current cvs. Otherwise control-v should not be bound to anything? See the keyboard.xml file in your base directory. Geoff ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [PATCH] switching views (trivial)
Jim Wilson wrote: Hi Geoff, I've got several changes and fixes to the viewer code, one of which changes the view manager to allow what you are describing. It is actually a little more flexible than just reversing, you can select the view through a property. This allows going forward, backward and directly to any specific view without using a special command. It's been done for a couple weeks now. I'll try and get it together and submit the changes in the next day or two. Best, Jim Got the best of both worlds now :) v forward cycle shift-v reverse cycle control-v return to view 0 Cheers, Geoff ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] [PATCH] switching views (trivial)
Hi all, I always wanted to be able to hit shift v to be able to cycle through views the other way. That way you can toggle between 2 views without having to go through them all, which can be uncomfortable if you're about to run into a mountain or something. It looked like the code was all there to do it so I have made these minor modifications to enable it. It works fine for me but be warned I know just enough C++ to be dangerous ;) Diffs are against current cvs. There is one patch for the base: home.pacific.net.au/~greendog/flightgear/rev-view-cycle-fgfsbase.diff and one for Flightgear: home.pacific.net.au/~greendog/flightgear/rev-view-cycle-FlightGear.diff Regards, Geoff ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS Confusion
Arnt Karlsen wrote: ..most people will the source tarballs goes into the /usr/local/ tree as told by the docs. When co'ing from cvs, they haul in _everything_ _again_, instead of just update what's new in cvs since the tarball release. As I did, it's been a bit of a learning curve but well worthwhile. Decisions of where to drop the cvs sources has to be made at check out ..yep, but we should advice on the ideal cvs for FG. Where to install the binaries seems to be another issue :) time and I'm not too sure how to take the pain out of that operation. ..you hardcoded '~/games/' painlessly ;-), it should be $FG-CVS-ROOT or some such, and just where do we put FG-CVS-ROOT? '/usr/local/'? Everything's hardcoded here, I think I've done it all the hard way. Anyway, I seem to have been trumped by Jon's Perl script. I'll give that a go and see how it works. Hope noones offended by me having flightgear under games :) ..hiring expensive hitman/ ;-) Whoops, now I've done it... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS Confusion
Arnt Karlsen wrote: On Sun, 12 Jan 2003 11:03:21 +1100, Geoff Reidy [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: If you've got plib, SimGear, FlightGear, and fgfsbase installed from cvs you can use this script to keep it up to date: http://home.pacific.net.au/~greendog/flightgear/fgupdate ..yeeha! I was going to write something like this, thanks! Neat job! :-) Glad you like it :) ..a wee policy nit: This _is_ where we (FG) wanna drop in the FG family cvs trees? : PLIB_DIR=~/games/flightgear/plib SIMGEAR_DIR=~/games/flightgear/SimGear FLIGHTGEAR_DIR=~/games/flightgear/FlightGear FGFSBASE_DIR=~/games/flightgear/fgfsbase ..most FG newcomers on thin metered wires will likely first try a tarball or a binary, when we tell'em try cvs, we should also help'em minimize the DL by dropping the cvs in somewhere convenient, so their old working binaries are left working while their old source trees are reused when possible. Not quite sure what you mean. This script is only useful once you've already checked out all the sources from cvs. Just removes the routine from keeping them up to date. Decisions of where to drop the cvs sources has to be made at check out time and I'm not too sure how to take the pain out of that operation. Can you run cvs co or update over the source from a tarball? I seem to remember having trouble doing that, though it was ages ago. Hope noones offended by me having flightgear under games :) Geoff ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS Confusion
Mike Bonar wrote: Please help a newbie out. I am a little confused about how to stay up to date with CVS. MIke If you've got plib, SimGear, FlightGear, and fgfsbase installed from cvs you can use this script to keep it up to date: http://home.pacific.net.au/~greendog/flightgear/fgupdate Occasionally you might hit a build error and have to look at the logs but most of the time it just works (for me anyway). Regards, Geoff ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Failed assertion in ssg.h
Curtis L. Olson wrote: Geoff Reidy writes: I still have the fgfs: ssg.h:302: void ssgBase::deRef(): Assertion `refc 0' failed. error with the random-objects disabled, just tried with current cvs. Happens after about the same distance as with them enabled. Strange, after many long flights ( 3500 nm) I have yet to see a crash with --disable-random-objects Regards, Curt. Curt, don't know if you're still watching this thread :) Just wanted to let you know that fg runs forever now if I compile single threaded, even with random objects enabled. Can't remember if I tried this earlier. Still seg faults if compiled multi threaded but no matter. Happy now :) Projects going great, thanks for your efforts. Regards, Geoff ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Failed assertion in ssg.h
Curtis L. Olson wrote: Geoff, I did some testing at home this weekend and I think there is something going on here related to the random ground cover objects. If I run with --disable-random-objects I have never seen a crash. If I run with the random objects I do see a similar crash after flying 3000 miles give or take a couple thousand. So I will say the following: For long haul flights, consider running without random objects. Random objects have a couple issues: - program crash after a few thousand miles. (To be fair, this may not directly be the random object code's fault. It could be an interaction issue with other portions of the program?) - issues with freeing tiles ... this can lead to substantially reduced frame rates while the system is struggling to free memory associated with a tile that has just been removed from the cache. For short hops, training, or any other sort of flight where you aren't venturing too far from home base, then it should be safe to leave random objects on. Regards, Curt. Curt, I still have the fgfs: ssg.h:302: void ssgBase::deRef(): Assertion `refc 0' failed. error with the random-objects disabled, just tried with current cvs. Happens after about the same distance as with them enabled. Regards, Geoff ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Failed assertion in ssg.h
Hi again,
This could be time consuming :)
I bypassed the asserts in plib to try and see what's really happening
and whether it's fatal or not. I think it was removing the
deadBeefCheck that made a difference. cvsdiff is included below.
Before when flying from Sydney to Katmandu the program always aborted
just off the north coast of Australia. I can hit a a few times to get
there quicker and it will still abort at the same place, which saves
some time anyway...
Just now with the changes I got all the way to Katmandu and then down
the length of India before it seg faulted. Backtrace from gdb included
below.
I have more time than expertise in these matters so any hints would be
appreciated :)
Regards,
Geoff
Index: src/ssg/ssg.h
===
RCS file: /cvsroot/plib/plib/src/ssg/ssg.h,v
retrieving revision 1.157
diff -r1.157 ssg.h
302c302,309
void deRef () { assert ( refc 0 ) ; refc-- ; }
---
// void deRef () { assert ( refc 0 ) ; refc-- ; }
void deRef () {
if ( refc 0 ) refc-- ;
else {
printf(refc was %d\n, refc);
refc = 0;
}
}
Index: src/ssg/ssgBase.cxx
===
RCS file: /cvsroot/plib/plib/src/ssg/ssgBase.cxx,v
retrieving revision 1.21
diff -r1.21 ssgBase.cxx
77c77
deadBeefCheck () ;
---
// deadBeefCheck () ;
$GPRMC,014714,A,1014.239,N,08035.811,E,628.6,-166.9,2311102,0.000,E*66
$GPGGA,014714,1014.239,N,08035.811,E,1,,,13051,F*21
Program received signal SIGSEGV, Segmentation fault.
0x4046e42d in malloc () from /lib/i686/libc.so.6
(gdb) bt
#0 0x4046e42d in malloc () from /lib/i686/libc.so.6
#1 0x4046e262 in malloc () from /lib/i686/libc.so.6
#2 0x4012771e in operator new(unsigned) () from /usr/X11R6/lib/libGLU.so.1
#3 0x403a1900 in std::__default_alloc_templatetrue,
0::allocate(unsigned) ()
from /usr/lib/libstdc++.so.5
#4 0x081eda30 in FGNavList::query(double, double, double, double,
FGNav*) (this=0x9144388,
lon=1.4066544783701858, lat=0.17856467335732401,
elev=3978.113809261698, freq=379,
n=0xb1b0) at /usr/include/c++/3.2/bits/stl_vector.h:123
#5 0x080b6d73 in FGKR_87::search() (this=0x98ae504) at kr_87.cxx:487
#6 0x080b2026 in FGRadioStack::search() (this=0x98ae448) at
radiostack.cxx:129
#7 0x080b21bb in fgMethodCallbackFGRadioStack*, void
(FGRadioStack::*)()::operator()() (
this=0xc26e7a6) at ../../src/Include/fg_callback.hxx:117
#8 0x0824319f in FGEventMgr::FGEvent::run() (this=0x8fe6228) at
FGEventMgr.cxx:86
#9 0x08243530 in FGEventMgr::update(double) (this=0x83bce58,
dt=0.0066742)
at /usr/include/c++/3.2/bits/stl_iterator.h:596
#10 0x0805170a in fgRenderFrame() () at main.cxx:440
#11 0x08053388 in fgMainLoop () at main.cxx:1263
#12 0x40084df2 in glutMainLoop () from /usr/X11R6/lib/libglut.so.3
#13 0x4008406d in glutMainLoop () from /usr/X11R6/lib/libglut.so.3
#14 0x08054708 in fgMainInit (argc=1, argv=0xb774) at main.cxx:1729
#15 0x08054cff in main (argc=1, argv=0xb774) at main.cxx:1821
#16 0x40419082 in __libc_start_main () from /lib/i686/libc.so.6
(gdb)
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Failed assertion in ssg.h
Curtis L. Olson wrote: What version of FlightGear are you running with? You really don't want to comment out the deadbeef checks in plib. That a patch they certainly would not accept ... it indicates the program is trying to use memory it previously freed. Curt. Running cvs plib simgear flightgear as of yesterday, though this problem has existed for some time, for me at least. I realise the deadbeef check is there for a reason and am not suggesting it be removed. I'm just fumbling around trying to figure why I can't travel more than about 3500 kms before fgfs dies. I guess the question is why is flightgear trying to reuse the memory and is it easier or harder to find the problem with the asserts in place? Basically I'm hoping someone will hit me over the head with a clue, or that I can provide information that will help someone who knows how the program works to find the problem. I have the time to do testing but it may take me a looong time to figure out what's going wrong. Possibly you have missed my first post in this thread where I did a backtrace from when this error appears: fgfs: ssg.h:302: void ssgBase::deRef(): Assertion `refc 0' failed. Aborted Geoff ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Failed assertion in ssg.h
Curtis L. Olson wrote: Geoff, this would appear to be a potential problem in the tile freeing code. Can you give me a route (i.e. a series of waypoints) that will show the problem (and the approximate place where things die.) Also, leave the visibility at the default for the test (or tell me what visibility you are using) because the visibility value determines the size of the tile cache which affects when tiles need to be removed. Regards, Curt. OK to test this I have been flying the a4, taking off from Sydney (YSSY) and immediately going into autopilot with waypoint set to Katmandu (VNKT). Using visibility=64000 and cruising at about 12000ft. Also I'm running in 16bpp if that makes any difference. The assert error occurs shortly after crossing 125°E and about halfway between the Australian coast and Timor. Oh, and this is before I started mucking about with the code :) Regards, Geoff ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Failed assertion in ssg.h
Hi all, I'm running current cvs of plib, simgear and flightgear on linux. Compiled with threads and without logging. After running for 3 or 4 hours fgfs always seg faults on me, normally I strip the binary but this time I didn't and now I get this error: fgfs: ssg.h:302: void ssgBase::deRef(): Assertion `refc 0' failed. Aborted So I ran it through gdb and did a backtrace. (The nav-vor-ident errors occur the whole time the program is running at the rate of about one per second.) Let me know if there's anything else I can do. Regards, Geoff $GPRMC,091314,A,1153.264,S,12434.835,E,610.9,-43.4,1411102,0.000,E*4B $GPGGA,091314,1153.264,S,12434.835,E,1,,,15031,F*37 $GPRMC,091314,A,1153.264,S,12434.835,E,610.9,-43.4,1411102,0.000,E*4B $GPGGA,091314,1153.264,S,12434.835,E,1,,,15031,F*37 Failed to remove nav-vor-ident sound Failed to remove nav-vor-ident sound Failed to remove nav-vor-ident sound Failed to remove nav-vor-ident sound fgfs: ssg.h:302: void ssgBase::deRef(): Assertion `refc 0' failed. Program received signal SIGABRT, Aborted. 0x4042a3d1 in kill () from /lib/i686/libc.so.6 (gdb) bt #0 0x4042a3d1 in kill () from /lib/i686/libc.so.6 #1 0x40305dad in raise () from /lib/i686/libpthread.so.0 #2 0x4042b979 in abort () from /lib/i686/libc.so.6 #3 0x4042466f in __assert_fail () from /lib/i686/libc.so.6 #4 0x082b2c56 in ssgDeRefDelete(ssgBase*) () at ssg.cxx:89 #5 0x082b89c9 in ~ssgLeaf (this=0xccb62a0) at ssgLeaf.cxx:79 #6 0x082ce88b in ~ssgVtxTable (this=0xccb62a0) at ssgVtxTable.cxx:148 #7 0x082b2c38 in ssgDeRefDelete(ssgBase*) (s=0x1) at ssg.cxx:89 #8 0x082b59c4 in ssgBranch::removeKid(int) (this=0xcca3660, n=1076928544) at ssgBranch.cxx:97 #9 0x081f036e in fgPartialFreeSSGtree (b=0xcca3660, n=90) at tileentry.cxx:724 #10 0x081f0385 in fgPartialFreeSSGtree (b=0xcca3500, n=100) at tileentry.cxx:713 #11 0x081f0385 in fgPartialFreeSSGtree (b=0x52128070, n=100) at tileentry.cxx:713 #12 0x081f0385 in fgPartialFreeSSGtree (b=0x52932bb0, n=100) at tileentry.cxx:713 #13 0x081f0695 in FGTileEntry::free_tile() (this=0x52932ab8) at tileentry.cxx:777 #14 0x081f4562 in FGTileMgr::update(double, double, double, double*, SGBucket, SGBucket, Point3D) (this=0x8401b40, lon=1.2731974745791634e-313, lat=0.005715523559064053, visibility_meters=64000, abs_pos_vector=0x8bc0314, p_current=Cannot access memory at address 0x6 ) at tilemgr.cxx:398 #15 0x08053126 in fgMainLoop () at ../../src/Main/location.hxx:116 #16 0x40084df2 in glutMainLoop () from /usr/X11R6/lib/libglut.so.3 #17 0x4008406d in glutMainLoop () from /usr/X11R6/lib/libglut.so.3 #18 0x08054803 in mainLoop(int, char**) (argc=1, argv=0xb5d0) at main.cxx:1742 #19 0x08054ebf in main (argc=1, argv=0xb774) at main.cxx:1834 #20 0x40419082 in __libc_start_main () from /lib/i686/libc.so.6 (gdb) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] new 'v' view for preferences.xml
Michael Selig wrote: I added the new 5th view which I have mentioned. This is an external view looking in a fixed direction at the airplane, e.g. the view looks north even as the airplane may turn. Mousing around will change the view direction. The advantage is that the horizon does not slew back and forth when the aircraft yaws, etc. Also, 3rd parties can watch the sim w/o getting sick! Regards, Michael Hi, I like the new 5th view but have noticed something odd. I you use it around dusk or dawn the sky colouration caused by the sun appears in the wrong part of the sky. If you switch between the external views you can see the difference, sometimes it's out by almost 180°. Geoff ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FSAA frustration continues (Nvidia forum post)
Curtis L. Olson wrote: Geoff Reidy writes: The major problem I have with fgfs is that I seem to hit a race condition where all graphics and sound stop for extended periods of time (up to about 30 secs), long enough for autopilot (or me!) to lose control and the plane will always crash. During this time there is no disk access happening or lack of memory, fgfs still uses 99% CPU. Doesn't make any difference whether I use the Mesa files or not. Tried compiling with/without random-objects and threading. Tried running with textures disabled, 16 or 24 bit. It happens after covering a certain amount of terrain. It doesn't matter if I'm flying the A4 or a Cessna I will go down about 1000km north of Sydney, give or take a couple of hundred. Over other parts of the world I usually get further but it always gets me in the end. The program itself never crashes. It's been happening since before version 8.0 came out but noone else seems to have the problem? I had put it down to some gcc3.2 weirdness but others are using it now. I can sometimes precipitate it by switching to tower view, will get a white screen, elevation goes to 4 ft or so, sound stops, oh-oh. This most likely relates to freeing tile memory (i.e. moving old tiles out of the cache and reclaiming their memory.) This was never a fast process and could result in frame rate glitches. When David added random ground cover objects, the problem got *really* bad because the scene graph structure of a tile got a lot larger. David and I worked really hard to optimize that, and I further worked on a partial tile free-er so we could spread the load out over multiple frames. This should have been all fixed by version 0.8.0 so that you should see very little frame rate impact when you cross a tile boundary. What version of flightgear are you running? Regards, Curt. I last did a cvs update and rebuild of plib, simgear and fgfs on 4th October. Regards, Geoff ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FSAA frustration continues (Nvidia forum post)
David Findlay wrote: How do you enable FSAA on Linux with FGFS? Thanks, David For NVidia cards you set the environment variable __GL_FSAA_ e.g. export __GL_FSAA_=4 fgfs will give 2x2 on a Geforce 2. All the options are listed at http://download.nvidia.com/XFree86_40/1.0-2960/README.txt see APPENDIX E. Works with pretty much any OpenGL app. Geoff ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FSAA frustration continues (Nvidia forum post)
Wolfram Kuss wrote: Geoff wrote: I was getting lockups in some games and fgfs before making my memory timings a bit more conservative, though it had passed memtest86 previously. Haven't had a lockup for weeks now. Interesting. You are speaking about the timings of the main memory, correct? Did the problems you had beforehand only occur with FSAA on or regardless of FSAA? Bye bye, Wolfram. I had selected turbo in the bios as I have good quality ram. Lockups were not related to fsaa. Symptoms were pretty strange - fgfs would trigger it randomly, povray would do it on one particular scene. A couple of other programs would also cause it. Lockups were hard and neccesitated a reboot with the reset button. I thought it might have been the Athlon agp bug but upgrading the kernel didn't help. Then I tried disabling the turbo option. I guess to be scientific I should turn it back on to check... Geoff ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FSAA frustration continues (Nvidia forum post)
Dave Perry wrote: My system is an Athlon XP 1800+ with an Asus A7M266 mother board, 512MB of PC2100 memory and 3 Seagate Baracuda IV (80GB each). My GF3 is an Asus V8200 Deluxe. My Linux is a RH7.3 with recent up2date, but I am running a 2.4.19 kernel compiled from tarball. This kernel has the patch for the speculative cache conflict also mentioned in the Nvidia docs. The behavior described is similar for either the 1.0-3123 or the 1.0-2960 drivers. I always install Nvidia drivers from the source RPMS using the --rebuild switch so that they for sure match the current kernel headers, etc. What is wierd is that FlightGear 8.0 (recent stable release) runs with no FSAA no matter what value I export for __GL_FSAA_MODE and therfore runs w/o crash. However, the CVS version 0.9.0 runs with FSAA ok with depth 16 and 1600x1200 or 1280x1024. With depth 24, there is no FSAA at 1600x1200 (thus stable runs), but there is FSAA at 1280x1024 resolution. In order to switch from the default 800x600 startup window to a 1600x1200 window, I first must cycle the resolutions (ctrl-alt-+) and then resize the window. When I use the normal exit option from fgfs, occaionally the system hard locks when i click on the yes box. With depth 16, and any resolution, (1600x1200, or 1280x1024), I must disable the splash screen, or the system locks up 100% of the time when running FlightGear with FSAA enabled. This is clearly an Nvidia driver bug! Are others having similar issues with complex applications? - Frustrated Dave Here fsaa works fine in 16bbp at 1280x960 or 24bpp at 800x600. Higher res at 24bpp and fsaa doesn't enable. I think this is the drivers way of telling me I don't have enough video memory. If I start at 800x600 and resize the window I'm down to about 1 frame/sec fsaa or not. Running the same kernel 2.4.19 on Mandrake 8.2. XP2000 on ASUS A7V333 and GF2 32MB. Latest NV drivers built from source RPMs. All compiled with gcc3.2. FSAA works with most of my openGL stuff including quake3. I was getting lockups in some games and fgfs before making my memory timings a bit more conservative, though it had passed memtest86 previously. Haven't had a lockup for weeks now. One weird thing I have have noticed, and I'd be interested if you see the same thing: When you install the drivers it renames some Mesa files, e.g. /usr/X11R6/lib/libGL.so.1.3.403 becomes /usr/X11R6/lib/xxx.libGL.so.1.3.403.RPMSAVE 1) If I compile and run at this point I see fgfs using about 75% CPU and X using the rest. 2) If I reinstate the Mesa files, recompile and run fgfs gets 99% of the CPU and I get significantly better framerates. ldd (for case 2) shows that it's using /usr/X11R6/lib/libGLU.so.1.3.403 which is from Mesa and is not renamed by nvidia, and /usr/lib/libGLcore.so.1.0.3123 which belongs to nvidia, and /usr/X11R6/lib/libGLwrapper.so.0.1.6 which belongs to XFree. From memory I think ldd showed the same files for case 1, it only matters which files are there at compile time. The major problem I have with fgfs is that I seem to hit a race condition where all graphics and sound stop for extended periods of time (up to about 30 secs), long enough for autopilot (or me!) to lose control and the plane will always crash. During this time there is no disk access happening or lack of memory, fgfs still uses 99% CPU. Doesn't make any difference whether I use the Mesa files or not. Tried compiling with/without random-objects and threading. Tried running with textures disabled, 16 or 24 bit. It happens after covering a certain amount of terrain. It doesn't matter if I'm flying the A4 or a Cessna I will go down about 1000km north of Sydney, give or take a couple of hundred. Over other parts of the world I usually get further but it always gets me in the end. The program itself never crashes. It's been happening since before version 8.0 came out but noone else seems to have the problem? I had put it down to some gcc3.2 weirdness but others are using it now. I can sometimes precipitate it by switching to tower view, will get a white screen, elevation goes to 4 ft or so, sound stops, oh-oh. Geoff ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
