Re: [Flightgear-devel] cycling w/ right mouse button && pause
Curtis L. Olson writes: > Yes, I observe this problem. Also a related problem is that incoming > network packets are not read. What's going on is that when the sim is > paused, the subsystems are not executed, but some of these things > should be executed even when the sim is paused ... I haven't had time > to look into it yet. David Megginson is the architect of the > flightgear subsystem system so it's all his fault. :-) Yes it is. I don't think it will take too much work to fix. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] F-16
I'll second the awesome! I'll try it soon. On Sun, 2003-02-23 at 20:31, John Check wrote: > On Sunday 23 February 2003 2:49 pm, Erik Hofman wrote: > > Christopher S Horler wrote: > > > Erik, > > > > > > I'm not running flightgear at the moment, any chance of a screenshot? > > > > http://www.a1.nl/~ehofman/fgfs/ > > (and scroll down a bit). > > > > That's awesome. I'll commit it after I give it a test run. > > > Erik > > > > > > ___ > > 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 mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] cycling w/ right mouse button && pause
Manuel Bessler writes: > Since nobody posted anything about my first question/possible bug report > I'll try it again: > > On Wed, Feb 19, 2003 at 02:57:40AM +0100, Manuel Bessler wrote: > > Hi > > > > I've noticed that cycling (right clicking) between mouse pointer mode, yoke mode, > > and > > view mode has no effect while paused. If you right click while paused it > > does not change mode until I hit 'p' again to unpause. It seems that it > > 'records' at most one right click in paused mode. > > > > It worked for me in 0.8.0, but in all 0.9.x and CVS versions I tried, > > it didn't. > > > Flightgear and base CVS from Feb 17. > > Platform: Debian Woody, 2.4.16 Yes, I observe this problem. Also a related problem is that incoming network packets are not read. What's going on is that when the sim is paused, the subsystems are not executed, but some of these things should be executed even when the sim is paused ... I haven't had time to look into it yet. David Megginson is the architect of the flightgear subsystem system so it's all his fault. :-) Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] cycling w/ right mouse button && pause
Since nobody posted anything about my first question/possible bug report I'll try it again: On Wed, Feb 19, 2003 at 02:57:40AM +0100, Manuel Bessler wrote: > Hi > > I've noticed that cycling (right clicking) between mouse pointer mode, yoke mode, and > view mode has no effect while paused. If you right click while paused it > does not change mode until I hit 'p' again to unpause. It seems that it > 'records' at most one right click in paused mode. > > It worked for me in 0.8.0, but in all 0.9.x and CVS versions I tried, > it didn't. > Flightgear and base CVS from Feb 17. > Platform: Debian Woody, 2.4.16 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] EXC_BAD_ACCESS in modified FGFS (on mac os x)
On Monday, February 24, 2003, at 07:28 AM,
[EMAIL PROTECTED] wrote:
Message: 6
Date: Sun, 23 Feb 2003 22:16:32 -0500
From: Ima Sudonim <[EMAIL PROTECTED]>
To: flightgear flightgear <[EMAIL PROTECTED]>
Subject: [Flightgear-devel] EXC_BAD_ACCESS in modified FGFS (on mac os
x)
Reply-To: [EMAIL PROTECTED]
Are there any ways to test MALLOC/NEW within flightgear looking for bad
pointer manipulation or allocation problems? (NOT in CVS but local
modifications)
MallocDebug is the program/tool you want. It overrides malloc and free
(and hence new) to detect memory allocation errors.
Is there a way to increase the size of the stack given to fgfs in Mac
OS X? I heard of a ulimit command but my machine (10.2.4) doesn't seem
to have this. Unsure if stack growing into the heap or vice versa is
the problem here.
I don't have this either (I used it once on a solaris box). Unless
there is infinite recursion, you probably won't overflow the stack. I
think you can adjust the underlying thread's stack size though (see man
pthread).
This is a modified version of flightgear of a friend with a mixture of
C++ and C pointer manipulation.
Any suggestions on how to begin debugging this? They're currently doing
the cout/asm ("trap") route. The problem seems specific to memory
allocation, some local (stack), some via new. He swears that he isn't
deleting anything twice. Problem usually occurs soon after the
procedure is called and returns (in a call or object allocation
immediately following this proc). The pointer work steps through a
buffer got from handleBufferRead() (netBufferChannel)
It's probably got a memory smasher. MallocDebug will help you find it
(make sure to read MallocDebug's help docs). You can use MallocDebug
within GDB, and there are directions on how to do that. I've used
MallocDebug to find many memory-related errors, so feel free to email
me off-list for further help.
HTH,
Darrell
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] OT: distributed terrain rendering
Did anyone already mention ? For those who know to read German, there might be an interesting article: Primarily it's about implementing the algorithm used by Terragen (http://www.planetside.co.uk/terragen/) for distributed rendering - coded in Java3D http://www.unc.de/terrain.html There's also a bit of description on the algorithm used here, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Speed Bottlenecks in FlightGear
Martin Spott writes: > I'm running FlightGear on an SGI Octane MXI (supplied with the recommended > texture cache RAM, so called TRAM). Besides, this machine employs a cross > bar switch to connect CPU, RAM and display (which provides a theoretical > bandwidth of 1.6 GByte/sec) and has two parallel rendering pipelines/engines > so I expect this machine to be 'pretty fast' (TM) at rendering a whole > scene. This can be demonstrated with several demos (SGI and 3rd party). > > Unfortunately this machine is still quite slow at FlightGear (even without > using textures) - I believe this is caused by the slow CPU (195 MHz only). > So if you say that the FDM only takes a few cycles the conclusion would be, > that processing the scene graph takes most of the time, If you do a profiling run of FlightGear, you will see that ssgCullAndDraw() takes a big chunk of the CPU as well as the terrain intersection. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Speed Bottlenecks in FlightGear
Jonathan Polley <[EMAIL PROTECTED]> wrote: > [...] Does anyone know if it is the actual rendering > of the display that is taking the time, or is it the math required to > process the scene graph? I'm running FlightGear on an SGI Octane MXI (supplied with the recommended texture cache RAM, so called TRAM). Besides, this machine employs a cross bar switch to connect CPU, RAM and display (which provides a theoretical bandwidth of 1.6 GByte/sec) and has two parallel rendering pipelines/engines so I expect this machine to be 'pretty fast' (TM) at rendering a whole scene. This can be demonstrated with several demos (SGI and 3rd party). Unfortunately this machine is still quite slow at FlightGear (even without using textures) - I believe this is caused by the slow CPU (195 MHz only). So if you say that the FDM only takes a few cycles the conclusion would be, that processing the scene graph takes most of the time, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Speed Bottlenecks in FlightGear
I have been using the remote display interface for quite some time, using a proprietary aircraft model. Since the frame rates were basically the same as when I was using an internal model, I expected that the CPU usage was not impacted by that component. Does anyone know if it is the actual rendering of the display that is taking the time, or is it the math required to process the scene graph? Would using SSE/SSE2/AltiVec for the matrix operations make much of a difference? Jonathan Polley On Monday, February 24, 2003, at 03:04AM, Erik Hofman <[EMAIL PROTECTED]> wrote: >Jonathan Polley wrote: >> Hello all, >> >> I am asking this question from the standpoint of the benefits of a >> dual-processor computer in running FlightGear. Enabling threading will >> yield more stable frame rates, but how much work can be offloaded onto >> the second processor? Is it save to guess that if I were to move all >> non-display processing to its own processor that I wouldn't see much, if >> any, improvement in frame rate? That being said, What would it take to >> squeeze the last bit of FPS out of FlightGear? > >This is related to your graphics hardware. If the hardware is able to do >everything hardware accelerated, I don't see much speed improvement in >splitting up tasks between processors. > >One thing you could try is running JSBSim on the same machine in stand >alone mode and connect it to FlightGear using the network interface (is >this already possible)? > >Erik > > >___ >Flightgear-devel mailing list >[EMAIL PROTECTED] >http://mail.flightgear.org/mailman/listinfo/flightgear-devel > > Of COURSE they can do that. They're engineers! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Speed Bottlenecks in FlightGear
Jon Berndt writes: > > One thing you could try is running JSBSim on the same machine in stand > > alone mode and connect it to FlightGear using the network interface (is > > this already possible)? > > There is an experiment that is sort of in-work, but not fully "staffed". I think that's a wonderful idea for many reasons, but I'd be amazed if people saw any measurable speed-up; the FDM just uses too few cycles to matter. No one has profiled FlightGear for a while -- perhaps we should start there. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Speed Bottlenecks in FlightGear
> One thing you could try is running JSBSim on the same machine in stand > alone mode and connect it to FlightGear using the network interface (is > this already possible)? There is an experiment that is sort of in-work, but not fully "staffed". Jon smime.p7s Description: S/MIME cryptographic signature
RE: [Flightgear-devel] RE: [Flightgear-cvslogs] Base CVS update:FlightGear/FlightGear/Docs
Carsten, > Does this mean, the document is also part of cvs? Luckily, indeed. Plus, it certainly will become part of the next official release (if you don't object, of course). > Can anyone give me a hand on how to continue writing using cvs? > Where do I have to send or put new chapters? Instructions on how to get the CVS version of the base archive are at http://rockfish.net/fg/. The simplest way to submit changes would be to send them via mail to John Check, [EMAIL PROTECTED], who maintains the base archive. Usually, he reacts very quickly by adding the files. Regards, Michael -- Michael Basler, Jena, Germany [EMAIL PROTECTED] http://www.geocities.com/pmb.geo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DAFIFT navids
Rick Ansell <[EMAIL PROTECTED]> wrote: >> [...] Then merge in data from X-Plane adding any >>missing airports and any taxiway data ... taking care to avoid >>airports that might still be in the X-Plane data set but have since >>been plowed under by "progress". > It might be worth doing something other than avoiding these > airfields. In the UK there are a relatively large amount of > (mostly ex-WWII) disused airfields around, some of which still > have their operating surfaces extant. not only in the UK. I assume there are quite a few airfileds not listed in Robin's database (I know at least two for certain). We should be able to render these, too, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RE: [Flightgear-cvslogs] Base CVS update:FlightGear/FlightGear/Docs
Does this mean, the document is also part of cvs? Can anyone give me a hand on how to continue writing using cvs? Where do I have to send or put new chapters? Thanks, Carsten Michael Basler schrieb: > > > Log Message: > > Add Carsten Hoefer's excellent flight tutorial to help > system > > Thanks, John! > > I hope Carsten will find time to go on with it later. > > Michael > > -- > Michael Basler, Jena, Germany > [EMAIL PROTECTED] > http://www.geocities.com/pmb.geo/ > > > > ___ > 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
Re: [Flightgear-devel] Speed Bottlenecks in FlightGear
Jonathan Polley wrote: Hello all, I am asking this question from the standpoint of the benefits of a dual-processor computer in running FlightGear. Enabling threading will yield more stable frame rates, but how much work can be offloaded onto the second processor? Is it save to guess that if I were to move all non-display processing to its own processor that I wouldn't see much, if any, improvement in frame rate? That being said, What would it take to squeeze the last bit of FPS out of FlightGear? This is related to your graphics hardware. If the hardware is able to do everything hardware accelerated, I don't see much speed improvement in splitting up tasks between processors. One thing you could try is running JSBSim on the same machine in stand alone mode and connect it to FlightGear using the network interface (is this already possible)? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] RE: [Flightgear-cvslogs] Base CVS update:FlightGear/FlightGear/Docs
> Log Message: > Add Carsten Hoefer's excellent flight tutorial to help system Thanks, John! I hope Carsten will find time to go on with it later. Michael -- Michael Basler, Jena, Germany [EMAIL PROTECTED] http://www.geocities.com/pmb.geo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
