Re: [Flightgear-devel] Serious simmer
Hi Ron, Robin van Steenbergen schrieb am 22.09.2007 02:14: > No, my original issue was to make external instrumentation possible over > the network, not on a single PC with 6 monitors on it. I think this is already possible within flightgear now. The only missing feature (if I remember correctly), is the switching off of the 3D-rendering of the surrounding, which is not necessary when rendering a panel only. But this should not be a big problem at all. As a ugly hack just use an empty scenery on the panel rendering machines. > Distribute the > computing power, allowing more processing power for the flight dynamics > and visuals and a flexible instrument setup. > > Take a real simulator as an example: The flight dynamics are run from a > system that does only that -- flight dynamics. Same issue here, the rendering need to be switched off, but the machine needs the scenery for scenery interaction. As a first step you can reduce the visibilty of the surrounding to a minimum, minimize the window and use no 3D-model of the aircraft. > Pure math that is, and > it's mostly done as a double redundant unit instead of a single one. > ... > My ultimate goal is to model a flight deck after the professional sims > -- each part of the simulator is dedicated to a system. This adds both > redundancy and flexibility -- if a system crashes, it doesn't take the > entire simulator with it as is the case with FS2004 based setups. The > data exchange doesn't stop, because it isn't tied to a single 'master' > unit -- if one unit should cease to respond (function), the rest of the > system is notified and possibly another unit or a hot standby might take > over. I think the redundant fdm on more than one machine is not supported by flightgear. But I think, that the implementation of this feature is much to much work compared with the result. Spending some time in a stable hardware should be much easier. (If flightgear crashes on one machine due to a software bug it will probably crash on the second machine, too. But the community works on avoiding and fixing such bugs.) > ... My proposal for the project would be to create a working framework for > 2D instruments, suitable for cockpit builders. The system would be > similar, if not identical in functionality, to X-Panel for X-Plane users > Wat's about programming an interface for X-Panel to flightgear? > (I would like to give you a URL but some fool took down the X-Panel > pages, every Google hit turns 404), which allows X-Plane instruments to > be displayed on a different system (or multiple). As for glass cockpits > go, an example is either OpenGC or Project Magenta, but both of these > have the design of their displays hard-coded, what I would really like > to see is that GC or steam panels could be designed in a WYSIWYG > graphics environment, and interactive script added later. SVG has > specifications for that. > The built-in interface in flightgear should be capable to fulfill all your request. Maik - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Serious simmer
On 9/22/07, Maik Justus <[EMAIL PROTECTED]> wrote: > > I think this is already possible within flightgear now. The only missing > feature (if I remember correctly), is the switching off of the > 3D-rendering of the surrounding, which is not necessary when rendering a > panel only. But this should not be a big problem at all. As a ugly hack > just use an empty scenery on the panel rendering machines. We can already switch off rendering of the 3d scene. Regards, Curt. -- Curtis Olson - University of Minnesota - FlightGear Project http://baron.flightgear.org/~curt/ http://www.humanfirst.umn.edu/ http://www.flightgear.org Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Serious simmer
Maik Justus schreef: > Hi Ron, > Robin van Steenbergen schrieb am 22.09.2007 02:14: > >> No, my original issue was to make external instrumentation possible over >> the network, not on a single PC with 6 monitors on it. >> > I think this is already possible within flightgear now. The only missing > feature (if I remember correctly), is the switching off of the > 3D-rendering of the surrounding, which is not necessary when rendering a > panel only. But this should not be a big problem at all. As a ugly hack > just use an empty scenery on the panel rendering machines. > Will network-linking of FG sessions synchronise ALL of the aircraft's property data, thus also syncing radio, instrument and cockpit data? For the visuals, only the basic 6DOF are needed, but is there also a way to keep everything inside the A/C's panels up to date all the time? That would get us a good start. Switch off the 3D rendering (as per Curt's instruction) and get 2D panels on the panel rendering machines. But we are going to need some good 2D panels, aside from the 3D cockpits already out there. Redundant FDM's is not a really neccessary step yet. I know that on some professional sims, all of the data is exchanged through a 'push' mechanism instead of a pull-style one. If one functional unit were to be stop sending data, the standby will immediately take over, as it was already receiving and processing data meant for the FDM system (it was only not transmitting data back). - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FGFS 0.9.11 release candidate two
Hi everybody, Are there any unresolved development issues regarding the plib branch? If not, I would like to try try and roll up a second release candidate this weekend (either tonight or tomorrow, depending on wether any pressing issues come up). If all goes well, I'm hoping to get the the new release ready in a week or two and transfered to the website soon thereafter. Please let me know if there are any issues that need to be addressed. Cheers, Durk - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Looks great
* Durk Talsma -- 9/19/2007 10:17 PM: > Currently, the situation isn't as clear anymore, because the OSG > version also has many new features which the PLib version doesn't, The most obvious differences are AFAIK: fg/plib fg/osg --- volumetric shadows -- random objects -- 3D clouds -- "bugfree" 2D clouds -- -- "pick" animation -- multi-view The rest should be pretty much on par, as fg/osg and fg/plib were developed side by side since fg/plib was branched off HEAD. On some people's machines fg/osg also seems to be a bit faster (and slower on other people's :-). But I think that the advantages of fg/osg don't outweigh the regressions, especially considering the new dependency. I think that taking fg/plib for 0.9.11 is a no-brainer, but that the release after it should follow as soon as possible. Let's not wait for another year. For me, having landing/taxi-lights is still a precondition for a release number 1.0. I'd feel rather embarrassed without. fg/osg has made a lot of progress, though, (mainly thanks to Mathias and Tim), and the above isn't meant as criticism at all. fg/osg is the future, and a rather bright one at that. :-) m. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGFS 0.9.11 release candidate two
Durk Talsma wrote: > Please let me know if there are any issues that need to be addressed. > > I just did a cvs up -dP for the plib branch of SimGear and then FlightGear to see if the periodic hesitation and drop in frame rate issue had been resolved. It has not been resolved. This problem is not in 0.9.10 and IMHO needs to be resolved before releasing 0.9.11. Am I missing/overlooking a fix. I have been working with Torsten Dreyer to implement the CenturyIII and a derivative AltimaticIIIc autopilot. So I have flown his SenecaII and the pa24-250 a lot while tweaking the two autopilot config files for these autopilots and aircraft. I do not see this issue at all when flying the pa24-250 and I see it every flight with the SenecaII. In the latter case, it is hardly noticable at first with only a slight variation in frame rate ( no more than 5 fps variation from 67 fps). As you continue to fly, the drop in frame rate increases (to 40+ fps after 15 minutes) and the duration of the drop increases. Also the time between drops increases. This has made the optimization of the autopilot config for the SenecaII difficult as this periodic hicup acts as an impulse response to the PID controllers. I am not changing anything but the aircraft between these flights. Two differences between these aircraft come to mind. First, the pa24-250 is a yasim model and the SenecaII is a jsbsim model. Second, the pa24-250 uses only three setlistener in the nasal I maintain and one of these goes away right away after the autopilot is powered up while the SenecaII uses a lot of setlisteners. I am not suggesting the cause, only noting the differences I am aware of between these aircraft. Regards, Dave Perry - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGFS 0.9.11 release candidate two
Hi, had the same notice: the 787 has this stutters too, the 777 also. Both uses a lot of nasal while the 737-300 seems to be much better. Only the old nasal air-ground. In the moment I improve the 737-300 and add the system of the 777/ 787 - the stutter increased dramatically! Melchior always saying that it is not the issue with the setlistner- but I'm sure there is a problem with which causes this stutters. Maybe it seems not to be logical, but it is remarkable, that the aircrafts with this typical nasal has this problems more than other. It would be better for the project, if we could solve this problem. But this needs a objective look into the possible causes. And I don't think we could solve this until 1st octobre. Greetings HHS --- dave perry <[EMAIL PROTECTED]> schrieb: > Durk Talsma wrote: > > Please let me know if there are any issues that > need to be addressed. > > > > > I just did a cvs up -dP for the plib branch of > SimGear and then > FlightGear to see if the periodic hesitation and > drop in frame rate > issue had been resolved. It has not been resolved. > This problem is not > in 0.9.10 and IMHO needs to be resolved before > releasing 0.9.11. Am I > missing/overlooking a fix. > > I have been working with Torsten Dreyer to implement > the CenturyIII and > a derivative AltimaticIIIc autopilot. So I have > flown his SenecaII and > the pa24-250 a lot while tweaking the two autopilot > config files for > these autopilots and aircraft. I do not see this > issue at all when > flying the pa24-250 and I see it every flight with > the SenecaII. In the > latter case, it is hardly noticable at first with > only a slight > variation in frame rate ( no more than 5 fps > variation from 67 fps). As > you continue to fly, the drop in frame rate > increases (to 40+ fps after > 15 minutes) and the duration of the drop increases. > Also the time > between drops increases. This has made the > optimization of the > autopilot config for the SenecaII difficult as this > periodic hicup acts > as an impulse response to the PID controllers. > > I am not changing anything but the aircraft between > these flights. Two > differences between these aircraft come to mind. > First, the pa24-250 is > a yasim model and the SenecaII is a jsbsim model. > Second, the pa24-250 > uses only three setlistener in the nasal I maintain > and one of these > goes away right away after the autopilot is powered > up while the > SenecaII uses a lot of setlisteners. > > I am not suggesting the cause, only noting the > differences I am aware of > between these aircraft. > > Regards, > Dave Perry > > > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio > 2005. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > __ Yahoo! Clever: Sie haben Fragen? Yahoo! Nutzer antworten Ihnen. www.yahoo.de/clever - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGFS 0.9.11 release candidate two
* Heiko Schulz -- 9/22/2007 6:19 PM: > Melchior always saying that it is not the issue with > the setlistner- but I'm sure there is a problem with > which causes this stutters. And I'm sure it's not. I had the same with the f16, which uses almost *no* Nasal, and the YF-23, which uses no Nasal at all(?). (Of course, there's always the global Nasal stuff, but there was much less at that time.) At one time when I researched the cause (without success), I ran fgfs in gdb, and always when the stutter appeared I pressed Ctrl-c. I almost always ended up in the nvidia driver code, and thought that some very expensive 3D drawing would be the cause. But that's as much guessing as the stale and as-good-as disproved setlistener() claim ... :-} m. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGFS 0.9.11 release candidate two
Hi, I think that there are maybe some more causes than only the setlistener. And I'm sure v0.9.10 had it too. That's why I said we should look objective into that. btw. what happens, if you press Ctrl-c outside the stutters? HHS --- Melchior FRANZ <[EMAIL PROTECTED]> schrieb: > * Heiko Schulz -- 9/22/2007 6:19 PM: > > Melchior always saying that it is not the issue > with > > the setlistner- but I'm sure there is a problem > with > > which causes this stutters. > > And I'm sure it's not. I had the same with the f16, > which uses almost *no* Nasal, and the YF-23, which > uses > no Nasal at all(?). (Of course, there's always the > global > Nasal stuff, but there was much less at that time.) > > At one time when I researched the cause (without > success), > I ran fgfs in gdb, and always when the stutter > appeared > I pressed Ctrl-c. I almost always ended up in the > nvidia > driver code, and thought that some very expensive 3D > drawing would be the cause. But that's as much > guessing > as the stale and as-good-as disproved setlistener() > claim ... :-} > > m. > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio > 2005. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > Die etwas anderen Infos rund um das Thema Reisen. BE A BETTER WELTENBUMMLER! www.yahoo.de/clever - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGFS 0.9.11 release candidate two
Hi, I think that there are maybe some more causes than only the setlistener. And I'm sure v0.9.10 had it too. That's why I said we should look objective into that. btw. what happens, if you press Ctrl-c outside the stutters? HHS --- Melchior FRANZ <[EMAIL PROTECTED]> schrieb: > * Heiko Schulz -- 9/22/2007 6:19 PM: > > Melchior always saying that it is not the issue > with > > the setlistner- but I'm sure there is a problem > with > > which causes this stutters. > > And I'm sure it's not. I had the same with the f16, > which uses almost *no* Nasal, and the YF-23, which > uses > no Nasal at all(?). (Of course, there's always the > global > Nasal stuff, but there was much less at that time.) > > At one time when I researched the cause (without > success), > I ran fgfs in gdb, and always when the stutter > appeared > I pressed Ctrl-c. I almost always ended up in the > nvidia > driver code, and thought that some very expensive 3D > drawing would be the cause. But that's as much > guessing > as the stale and as-good-as disproved setlistener() > claim ... :-} > > m. > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio > 2005. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > Wissenswertes zum Thema PC, Zubehör oder Programme. BE A BETTER INTERNET-GURU! www.yahoo.de/clever - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGFS 0.9.11 release candidate two
On Saturday 22 September 2007 18:53, Heiko Schulz wrote: > Hi, > > I think that there are maybe some more causes than > only the setlistener. And I'm sure v0.9.10 had it too. > That's why I said we should look objective into that. > btw. what happens, if you press Ctrl-c outside the > stutters? > We probably need an objective way of investigating this problem. One obvious solution would be to add a tic / toc mechanism to FlightGear's subsystem manager. I'm writing this off the top of my head, but I believe that tic; and toc; are the matlab commands to query how much execution time has passed between the two commands. we are currently already feeding delta t into each subsystem, so we have some redundant timing information available. I don't know yet how easy it would be to implement a profiling like functionality into the current architecture, but I might have a few hours to investigate tomorrow. Cheers, Durk - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGFS 0.9.11 release candidate two
Melchior FRANZ wrote: >* Heiko Schulz -- 9/22/2007 6:19 PM: > > >>Melchior always saying that it is not the issue with >>the setlistner- but I'm sure there is a problem with >>which causes this stutters. >> >> > >And I'm sure it's not. I had the same with the f16, >which uses almost *no* Nasal, and the YF-23, which uses >no Nasal at all(?). (Of course, there's always the global >Nasal stuff, but there was much less at that time.) > > > Can someone plays a bit with a profiler ? While a listener is nothing special, Nasal itself take a substancial part of the cpu time per frame (of course that depends on a few random parameter but I have between 20 & 35 % of the cpu used in the nasal sources). And some time ago I was refering to the garbage collector that causes mini stutters and the gc was running on a period like 1 gc every 20 seconds at fg start and after some time it was like 1 gc every 10 seconds, the time spent in the gc was increasing too. HJ. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGFS 0.9.11 release candidate two
* Heiko Schulz -- 9/22/2007 6:53 PM: > I think that there are maybe some more causes than > only the setlistener. While I still don't think that listeners are even one of the causes, I agree that there could be more sources. Some bad timing. > And I'm sure v0.9.10 had it too. So am I. Actually, I think I was (one of) the first who ever reported that problem, and I seem to remember that it was long before Nasal listeners even existed. :-} > what happens, if you press Ctrl-c outside the stutters? I end up in whatever code is currently executed. Most of the time it's outside the nVidia driver. If someone wonders how I could reliably press the key within the stutter: the stutters become longer and longer, and when they are half a second it's quite easy to hit them. ;-) (BTW: Yes, I also checked the other threads.) m. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGFS 0.9.11 release candidate two
Heiko Schulz wrote: > I think that there are maybe some more causes than > only the setlistener. Agreed. I should have included the following from fgrun: /usr/local/FlightGear-plib/data/bin/fgfs --fg-root=/usr/local/FlightGear-0.9/data --fg-scenery=/usr/local/FlightGear-0.9/data/Scenery:/usr/local/FlightGear-0.9/Scenery-0.9.10 --airport-id=KOTM --aircraft=pa28-161 --control=joystick --disable-random-objects --disable-ai-models [EMAIL PROTECTED] --geometry=1680x1050 --visibility-miles=15 --bpp=24 --fov=65 --nmea=socket,out,5,localhost,5500,udp --prop:/sim/frame-rate-throttle-hz=60 --nav1=111.6 --nav2=109.5 --adf=344 --dme=nav1 I did observe a stutter with the pa24-250 until I set --prop:/sim/frame-rate-throttle-hz=60 I just did the same rw 31 approach into KOTM with the pa28-161 (kap140 autopilot) and it also was smooth as silk with frame rate varying from 65 to 68, usually 67 fps. The nasal for this model is very similar to the pa24-250. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] [Fwd: Re: FGFS 0.9.11 release candidate two]
Durk Talsma wrote: We probably need an objective way of investigating this problem. One obvious solution would be to add a tic / toc mechanism to FlightGear's subsystem manager. I'm writing this off the top of my head, but I believe that tic; and toc; are the matlab commands to query how much execution time has passed between the two commands. we are currently already feeding delta t into each subsystem, so we have some redundant timing information available. I don't know yet how easy it would be to implement a profiling like functionality into the current architecture, but I might have a few hours to investigate tomorrow. Cheers, Durk Since we you are investigating I don't want to influence you, but I don't think that there is a lot in the susbsystem code after you disable ai and the like. I've attached a profiles I took in July (snapshot of a few seconds of run, does not include start of fg). If you want to profiles parts of the code and have the results in real time you can try iProf (http://silverspaceship.com/src/iprof/) HJ. DevPartner - Performance Analysis Session Summary Started:25/07/2007 21:16:11 Ended: 25/07/2007 21:19:11 Executable: f:\dvlp\plibfg\FlightGear\source\projects\VC7.1\Release\fgfs.exe Command Args:--fg-root=F:\dvlp\osgfg\FlightGear\data Exit Code: 0 Processor Speed:2400 Mhz # of Processors:1 OS Version: Microsoft Windows XP # of Called Methods (with thread starts): 2 023 # of Calls: 20 764 154 Total Timing: 7273,7 Milliseconds TIP-Z9UE7PTNCMA - 2884 (fgfs) Number of Called Methods: 2 024 Percent of Time Spent on Machine: 100,0 Instrumented Source Images fgfs.exe Number of Called Methods: 2 024 Percent of Time Spent in Image: 100,0 props.cxx Number of Called Methods: 97 Percent of Time Spent in File: 27,2 fg_os.cxx Number of Called Methods: 20 Percent of Time Spent in File: 13,8 misc.c Number of Called Methods: 34 Percent of Time Spent in File: 8,4 code.c Number of Called Methods: 35 Percent of Time Spent in File: 7,6 renderer.cxx Number of Called Methods: 9 Percent of Time Spent in File: 6,3 hash.c Number of Called Methods: 13 Percent of Time Spent in File: 5,7 gc.c Number of Called Methods: 22 Percent of Time Spent in File: 4,2 sg_random.c Number of Called Methods: 6 Percent of Time Spent in File: 3,3 tileentry.cxx Number of Called Methods: 8 Percent of Time Spent in File: 2,5 string.c Number of Called Methods: 17 Percent of Time Spent in File: 1,7 leaf.cxx Number of Called Methods: 3 Percent of Time Spent in File: 1,2 placementtrans.cxx Number of Called Methods: 5 Percent of Time Spent in File: 1,1 sg_time.cxx Number of Called Methods: 12 Percent of Time Spent in File: 1,0 sg_binobj.cxx Number of Called Methods: 2 Percent of Time Spent in File: 1,0 subsystem_mgr.cxx Number of Called Methods: 28 Percent of Time Spent in File: 0,9 vector.c Number of Called Methods: 8 Percent of Time Spent in File: 0,8 util.cxx Number of Called Methods: 2 Percent of Time Spent in Fi
Re: [Flightgear-devel] FGFS 0.9.11 release candidate two
Harald JOHNSEN a écrit :
> Melchior FRANZ wrote:
>
>
>> * Heiko Schulz -- 9/22/2007 6:19 PM:
>>
>>
>>
>>> Melchior always saying that it is not the issue with
>>> the setlistner- but I'm sure there is a problem with
>>> which causes this stutters.
>>>
>>>
>>>
>> And I'm sure it's not. I had the same with the f16,
>> which uses almost *no* Nasal, and the YF-23, which uses
>> no Nasal at all(?). (Of course, there's always the global
>> Nasal stuff, but there was much less at that time.)
>>
>>
>>
>>
> Can someone plays a bit with a profiler ? While a listener is nothing
> special, Nasal itself take a substancial part of the cpu time per frame
> (of course that depends on a few random parameter but I have between 20
> & 35 % of the cpu used in the nasal sources). And some time ago I was
> refering to the garbage collector that causes mini stutters and the gc
> was running on a period like 1 gc every 20 seconds at fg start and after
> some time it was like 1 gc every 10 seconds, the time spent in the gc
> was increasing too.
>
I used a profiler of my own :
cvs -z4 -w -q diff -u -wb -- simgear\structure\subsystem_mgr.cxx (in
directory I:\Devel\SimGear.plib\)
Index: simgear/structure/subsystem_mgr.cxx
===
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/structure/subsystem_mgr.cxx,v
retrieving revision 1.5
diff -u -w -b -r1.5 subsystem_mgr.cxx
--- simgear/structure/subsystem_mgr.cxx21 Feb 2006 12:59:31 -1.5
+++ simgear/structure/subsystem_mgr.cxx22 Sep 2007 22:12:50 -
@@ -4,6 +4,7 @@
#include "exception.hxx"
#include "subsystem_mgr.hxx"
+#include
@@ -124,7 +125,17 @@
SGSubsystemGroup::update (double delta_time_sec)
{
for (unsigned int i = 0; i < _members.size(); i++)
+{
+SGTimeStamp start, now;
+start.stamp();
_members[i]->update(delta_time_sec); // indirect call
+now.stamp();
+long b = ( now - start );
+if ( b > 1 ) {
+ cout << "D : " << b << " " << _members[i]->name << endl;
+ int a = 1;
+}
+}
}
void
It appears that it is the replay subsystem that creates long pauses
periodically, and sometimes the ai-model subsystem too :
( my traces : )
D : 12000 replay
D : 11000 replay
D : 17000 instrument20
D : 18000 instrumentation
D : 12000 replay
D : 12000 replay
D : 14000 replay
D : 19000 replay
D : 16000 replay
D : 18000 replay
D : 11000 replay
D : 22000 input
D : 13000 replay
D : 17000 replay
D : 14000 replay
D : 22000 replay
D : 18000 replay
D : 18000 replay
D : 18000 Traffic Manager
D : 17000 instrument13
D : 18000 instrumentation
D : 17000 replay
D : 23000 electrical0
D : 32000 systems
D : 18000 replay
D : 11000 replay
D : 16000 replay
D : 11000 replay
D : 11000 replay
D : 252000 input
D : 11000 replay
D : 12000 electrical0
D : 15000 systems
D : 11000 replay
D : 17000 ai_model
D : 11000 instrumentation
D : 11000 replay
D : 14000 replay
D : 18000 replay
D : 11000 replay
D : 12000 replay
D : 19000 replay
D : 15348000 replay
D : 16000 ai_model
D : 14000 replay
D : 11000 replay
D : 12000 replay
D : 14000 replay
D : 12000 replay
D : 15000 properties
D : 13000 replay
Very long pauses are caused by breakpoints in the debugger
regards,
-Fred
--
Frédéric Bouvier
http://frfoto.free.fr Photo gallery - album photo
http://www.fotolia.fr/p/2278 Other photo gallery
http://fgsd.sourceforge.net/ FlightGear Scenery Designer
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] For Robin van Steenbergen
Dear Robin, I wonder, can you advise me where I can get hold of some music for my movies that is none copyright? I am specifically looking for Aircraft themes such as Top Gun as example, but generally more tamed music for background tracks especially of the sort used in the Movie "Final Approach" not the recent one the old one with the stealth aircraft http://uk.rottentomatoes.com/m/1038120-final_approach/ I am working very hard at the moment on part 3, much more time is going into it than in previous episodes, so any help is much appreciated. Regards, Ortorea <> Aerotro Online FlightGear Simulator Tracker Page. http://mpserver04.flightgear.org http://www.flightgear.org- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Looks great
On Sat, 22 Sep 2007, Melchior FRANZ wrote: >For me, having landing/taxi-lights is still a precondition for >a release number 1.0. I'd feel rather embarrassed without. Is anyone working on this? I'm interested in helping. >fg/osg has made a lot of progress, though, (mainly thanks to >Mathias and Tim), and the above isn't meant as criticism at >all. fg/osg is the future, and a rather bright one at that. :-) And with the addition of aircraft lights, a brilliant one. I expect any work I might do on lighting to very illuminating, as it would give me an enlightening exposure to the FG code. (sorry - couldn't resist) (but I'm serious about helping out) -- Mike Schuh - Seattle, Washington USA http://www.farmdale.com - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] And again: VATSIM and FG?
On Tuesday 18 September 2007 00:50, Holger Wirtz wrote: > Hi *, > > On Mon, Sep 17, 2007 at 10:52:55AM -0500, Curtis Olson wrote: > > On 9/17/07, Ralf Gerlich wrote: > > > Holger Wirtz wrote: > > > > But they asked me if I want to write something like a VATSIM-proxy > > > > for FG to get arround the GPL problem. This proxy has to be > > > > closed-source. > > > --snip > Currently I have no interest in writing code for applications where > someone else can define who and under which conditions the software > gets. > > But perhaps someone else has interest in writing a VATSIM proxy? > > [...] > > Regards, Holger I know that their is a big interest on the users list in virtual airlines using flightgear and I personally am interested in voice ATC. I have no interest in either of the two networks VATSIM or IVAO. I would hate to see precious talent goi - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] For Robin van Steenbergen
On Saturday 22 September 2007 17:23, Forums Virgin Net wrote: > Dear Robin, > I wonder, can you advise me where I can get hold of some > music for my movies that is none copyright? I am specifically looking for > Aircraft themes such as Top Gun as example, but generally more tamed music > for background tracks especially of the sort used in the Movie "Final > Approach" not the recent one the old one with the stealth aircraft > http://uk.rottentomatoes.com/m/1038120-final_approach/ Search on Podsafe and see if you find anything. A small unknown that has something you like that would give permission for it to be distributed on your film in exchange for credits including a link to their website et Just an idea. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] For Robin van Steenbergen
Robert Black schreef: > On Saturday 22 September 2007 17:23, Forums Virgin Net wrote: > >> Dear Robin, >> I wonder, can you advise me where I can get hold of some >> music for my movies that is none copyright? I am specifically looking for >> Aircraft themes such as Top Gun as example, but generally more tamed music >> for background tracks especially of the sort used in the Movie "Final >> Approach" not the recent one the old one with the stealth aircraft >> http://uk.rottentomatoes.com/m/1038120-final_approach/ >> > > Search on Podsafe and see if you find anything. A small unknown that has > something you like that would give permission for it to be distributed on > your film in exchange for credits including a link to their website et > Just an idea. > > You could also talk to Justin R. Durban from Edgen Productions: http://www.edgen.com/ He has done the music for Dark Armada as well, free of charge, and likes to contribute to independent productions. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Weekly CVS Changelog Summary: SimGear
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-09-16_05:17:56 (durk) /var/cvs/SimGear-0.3/source/projects/VC8/SimGear.vcproj Olaf Flebbe: Update of MSVC8 project files. 2f585eeea02e2c79d7b1d8c4963bae2d - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Weekly CVS Changelog Summary: FlightGear source
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-09-16_05:18:37 (durk) /var/cvs/FlightGear-0.9/source/projects/VC8/FlightGear.sln /var/cvs/FlightGear-0.9/source/projects/VC8/FlightGear.vcproj /var/cvs/FlightGear-0.9/source/projects/VC8/FlightGearLib.vcproj Olaf Flebbe: Update of MSVC8 project files. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-09-22_12:42:21 (fredb) /var/cvs/FlightGear-0.9/source/src/Input/fgjs.cxx Compile again 2f585eeea02e2c79d7b1d8c4963bae2d - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Weekly CVS Changelog Summary: FlightGear data
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-09-16_08:23:16 (helijah) /var/cvs/FlightGear-0.9/data/Aircraft/P180/Models/p-180-model.xml - correction of the contrarotating propellers =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-09-17_22:20:56 (sydadams) /var/cvs/FlightGear-0.9/data/Aircraft/Sikorsky-76C/S76C-autopilot.xml S76C updates =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-09-17_22:20:57 (sydadams) /var/cvs/FlightGear-0.9/data/Aircraft/Sikorsky-76C/instrumentation.xml S76C updates =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-09-17_22:20:58 (sydadams) /var/cvs/FlightGear-0.9/data/Aircraft/Sikorsky-76C/Models/Attic/S76livery.rgb /var/cvs/FlightGear-0.9/data/Aircraft/Sikorsky-76C/Models/Attic/S76livery1.rgb /var/cvs/FlightGear-0.9/data/Aircraft/Sikorsky-76C/Models/Attic/S76livery2.rgb /var/cvs/FlightGear-0.9/data/Aircraft/Sikorsky-76C/Models/Attic/interior.rgb /var/cvs/FlightGear-0.9/data/Aircraft/Sikorsky-76C/Models/Attic/panel.rgb S76C updates =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-09-17_22:20:59 (sydadams) /var/cvs/FlightGear-0.9/data/Aircraft/Sikorsky-76C/Nasal/RTU4200.nas /var/cvs/FlightGear-0.9/data/Aircraft/Sikorsky-76C/Nasal/flightdirector.nas /var/cvs/FlightGear-0.9/data/Aircraft/Sikorsky-76C/Sound/whine.wav S76C updates =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-09-19_12:38:55 (helijah) /var/cvs/FlightGear-0.9/data/Aircraft/Lionceau/lionceau-splash.rgb /var/cvs/FlightGear-0.9/data/Aircraft/Lionceau/thumbnail.jpg - Add a shadow like DC3 for test. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-09-19_12:38:57 (helijah) /var/cvs/FlightGear-0.9/data/Aircraft/Lionceau/Models/lionceau.xml /var/cvs/FlightGear-0.9/data/Aircraft/Lionceau/Models/shadow.ac /var/cvs/FlightGear-0.9/data/Aircraft/Lionceau/Models/shadow.rgb /var/cvs/FlightGear-0.9/data/Aircraft/Lionceau/Models/shadow.xml - Add a shadow like DC3 for test. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-09-19_12:38:58 (helijah) /var/cvs/FlightGear-0.9/data/Aircraft/Lionceau/Nasal/lionceau-keyboard.xml - Add a shadow like DC3 for test. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-09-19_16:45:03 (martin) /var/cvs/FlightGear-0.9/data/Scenery/Objects/w130n30/w123n37/942043.stg /var/cvs/FlightGear-0.9/data/Scenery/Objects/w130n30/w123n37/moffett_hangar1.ac /var/cvs/FlightGear-0.9/data/Scenery/Objects/w130n30/w123n37/moffett_hangar1a.rgb /var/cvs/FlightGear-0.9/data/Scenery/Objects/w130n30/w123n37/moffett_hangar1b.rgb Stuart Buchanan: I've created a simple model of Hangar One at Moffett Field for inclusion in CVS. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-09-20_02:09:52 (sydadams) /var/cvs/FlightGear-0.9/data/Aircraft/Sikorsky-76C/Nasal/Attic/M877.nas more updates added a Davtron M877 chronometer... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-09-21_19:44:29 (sydadams) /var/cvs/FlightGear-0.9/data/Aircraft/Sikorsky-76C/s76c-1-set.xml /var/cvs/FlightGear-0.9/data/Aircraft/Sikorsky-76C/s76c-2-set.xml /var/cvs/FlightGear-0.9/data/Aircraft/Sikorsky-76C/s76c-3-set.xml /var/cvs/FlightGear-0.9/data/Aircraft/Sikorsky-76C/s76c-base.xml changed the livery setup, start now with --aircraft=s76c-1 ,s76c-2, or s76c-3 Fixed problem with Davtron clock crashing if Flight Time hour was zero ... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-09-21_19:44:30 (sydadams) /var/cvs/FlightGear-0.9/data/Aircraft/Sikorsky-76C/splash1.rgb /var/cvs/FlightGear-0.9/data/Aircraft/Sikorsky-76C/splash2.rgb /var/cvs/FlightGear-0.9/data/Aircraft/Sikorsky-76C/splash3.rgb changed the livery setup, start now with --aircraft=s76c-1 ,s76c-2, or s76c-3 Fixed problem with Davtron clock crashing if Flight Time hour was zero ... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-09-21_19:44:32 (sydadams) /var/cvs/FlightGear-0.9/data/Aircraft/Sikorsky-76C/Models/s76c-black.xml /var/cvs/FlightGear-0.9/data/Aircraft/Sikorsky-76C/Models/s76c-hk.xml /var/cvs/FlightGear-0.9/data/Aircraft/Sikorsky-76C/Models/s76c-rescue.xml changed the livery setup, start now with --aircraft=s76c-1 ,s76c-2, or s76c-3 Fixed problem with Davtron clock crashing if Flight Time hour was zero ... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-09-21_19:44:33 (sydadams) /var/cvs/FlightGear-0.9/data/Aircraft/Sikorsky-76C/Models/s76c.xml changed the livery setup, start now with --aircraft=s76c-1 ,s76c-2, or s76c-3 Fixed problem with Davtron clock crashing if Flight Time hour was zero ... 2f585eeea02e2c79d7b1d8c4963bae2d - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___
[Flightgear-devel] [Fwd: Re: [Flightgear-users] Nasal runtime error: non-scalar in string context]
Forwarded Message > From: Robert Fu <[EMAIL PROTECTED]> > Reply-To: FlightGear user discussions > <[EMAIL PROTECTED]> > To: FlightGear user discussions > <[EMAIL PROTECTED]> > Subject: Re: [Flightgear-users] Nasal runtime error: non-scalar in > string context > Date: Sat, 22 Sep 2007 21:38:05 -0700 > > Hi Ron, > > Thanks a lot for your help. After spending a lot of hours, I think > that the following factors seems contributed to the crash: > > 1. OpenSceneGraph uses STL a lot, and some STL classes manage their > own memory. > 2. I verified on Linux, similar setup worked. Thus the Flightgear and > OpenSceneGraph code seems fine. > 3. In my previous MinGW, libstdc++ is a statically linked, and it's > based on static version of system C library MSVCRT. For .EXE or .DLL > modules which are statically-linked C Run-time library, problem can > occur in some situations, such as allocating memory with a C Run-time > call in the .EXE/DLL and reallocating or freeing it in the other > module. Each of these .EXE or .DLL has its own heap space. I think in > my case, allocating memory in one heap space, and freeing it in > another heap space eventually crashed the system. When tracing the > execution in Eclipse, I noticed that in some situations, after > exiting a function, it came back to execute the last few lines of the > same function again. The following are some links for someone > interested in details of this cross DLL/EXE issue: > > http://www.nabble.com/C > ++-STL,-DLLs-and-our-friend-RtlFreeHeap-t1847074.html > > http://mail-archives.apache.org/mod_mbox/xerces-c-dev/24.mbox/% > [EMAIL PROTECTED] > > http://lists.trolltech.com/qt-interest/2004-12/thread00928-0.html > http://lists.trolltech.com/qt-interest/2001-10/thread00530-0.html > > http://support.microsoft.com/kb/140584 > http://support.microsoft.com/kb/94248 > > As suggested in the the above links, we need a DLL version of libstdc > ++ in MinGW. Fortunately in the latest preview version of gcc 4.2.1, > there is such a libstdc++. With some further steps like creating the > missing libgcc_s.a, etc, I finally made CVS version of Flightgear with > OpenSceneGraph worked with MinGW/MSYS on both Windows XP and Vista. > FGRun also worked with MinGW/MSYS. If anyone is interested in details, > please let me know. > > Thanks, > Robert Fu > > > On 9/11/07, Ron Jensen <[EMAIL PROTECTED]> wrote: > On Tue, 2007-09-11 at 09:37 -0700, Robert Fu wrote: > > Hi Ron, > > > > > So I set HOME environment variable, and the Nasal error > disappeared > > when running in DOS-Prompt. I noticed before that when > running in > > MSYS, I got different console output, and I realize now that > in MSYS, > > there is HOME environment variable. > > Cool :) > > > However, I got a different problem, and this time, there is > no error > > in console output. A Windows "Send Error Report" dialog came > up, after > > clicking on Don't Send button, fgfs application exited. When > I turned > > on log-level as the following > > > > fgfs --httpd=5500 --log-level=info > > > > There are a lot message output in console, and the last few > lines are: > > > > Adding subsystem nasal > > trying to load aircraft data from > > c:/gnu/depot/home/rfu/.fgfs/aircraft-data/c172p.xml (OK if > not found) > > Cannot load flight from > > c:/gnu/depot/home/rfu/.fgfs/aircraft-data/c172p.xml > > The above lines shouldn't be a problem as > ~/.fgfs/aircraft-data/c172p.xml doesn't exist here, either... > > > loading scenario 'aircraft_demo' > > Reading image "C:\gnu\msys\1.0.11\local\src\FlightGear-0.9 > \data > > \Aircraft\737-300\Models\733UAii.rgb" > > Reading model "C:/gnu/msys/1.0.11/local/src/FlightGear- > > 0.9/data/Aircraft/737-300/Models/737-300.ac" > > > > > > Splash screen progress setting up time & renderer > > > > > > If I click on Debug button on the Send Error Report dialog, > I got: > > > > unhandled exception in fgfs.exe:0xC005: Access > Violation. > > > > I guess something might not be loaded correctly, and I'll do > more > > tracing, and any advice is welcome. > > > Perhaps its not liking the aircraft demo? Try turning off > ai-models and > the traffic manager with this command line: > > fgfs --disable-ai-models --prop:/sim/traffic-manager/enabled=0 > > Or go into $FGROOT/preferences.xml and comment out the > aircraft-demo, it > should be around line 459. > > > > I have o
