C-like in many ways. Probably the biggest barrier for most people is
going to be getting their development system setup properly so they can
compile their new code additions or changes.
I sort of disagree here. Setting up a development system is not a big deal
(even I managed to do it, so
* Torsten Dreyer -- Thursday 25 October 2007:
To make things easier for developers, can we think of a plug-in
system for callbacks so a potential developer write a library
that is linked in dynamically by the flightgear core?
No.
That would mean to add and maintain plug-in loader code for all
Sent: 25 October 2007 14:10
To: flightgear-devel@lists.sourceforge.net
Subject: Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
* Torsten Dreyer -- Thursday 25 October 2007:
To make things easier for developers, can we think of a
plug-in system
for callbacks so
On Wednesday 24 October 2007 00:15, Vivian Meazza wrote:
Not here, I'm afraid. Very good frame rates using the Buccaneer (70+) but
there are still noticeable pauses over land. None over the ocean tiles. The
pauses, or hesitations do not seem to be associated with any Subsystem
Timing Alert,
Georg Vollnhals
Sent: 23 October 2007 23:34
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
Vivian Meazza schrieb:
Not here, I'm afraid. Very good frame rates using the
Buccaneer (70+)
but there are still noticeable
Durk
Sent: 24 October 2007 07:22
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
On Wednesday 24 October 2007 00:15, Vivian Meazza wrote:
Not here, I'm afraid. Very good frame rates using the
Buccaneer (70
Heiko Schulz
Sent: 23 October 2007 23:55
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
Hi,
Couldn't test it, waiting that someones will do a
precompiled binary for windows.
But it sounds good, very good though at least
The Seneca is special in that it attaches listeners to YASim
internal properties, which are updated multiple times per
frame, unlike most other listeners, which run *at most* once
per frame, but actually very rarely.
Oh - wasn't it using JSBSim as fdm!?
I hope that the stuttering is fixed
* Torsten Dreyer -- Wednesday 24 October 2007:
The Seneca is special in that it attaches listeners to YASim
internal properties, which are updated multiple times per
frame, unlike most other listeners, [...]
Oh - wasn't it using JSBSim as fdm!?
Indeed. I remembered that wrongly because
Heiko,
I applied the patches to plib branch (I get runtime errors with FG link
against OSG 2.2 that I haven't figured out):
http://www.rato.us/flightgear/builds/plib/20071024plibexe.zip
-Reagan
On 10/23/07, Heiko Schulz [EMAIL PROTECTED] wrote:
Hi,
Couldn't test it, waiting that someones
On Wednesday 24 October 2007 11:21, Melchior FRANZ wrote:
[snip...]
Listeners should be used on properties to get notice about
occasional changes. In cases where we *know* when the property
changes -- once per loop or more often -- we can have the same
result cheaper with a loop. (Listeners
This is starting to enter the realm of my own opinions so please keep that
in mind.
Nasal was never intended to do work at this low level. However, the fact
that it can be used to successfully model an advanced flight control system
[mostly successfully] says a lot about the capabilities of
* leee -- Wednesday 24 October 2007:
the FDM operates at a fixed rate (I believe the default is 120 Hz)
but nearly everything else, afaikt, operates at the frame rate,
which varies.
Yes, but most Nasal code does things that influence visuals/sound
(like instrument stuff, view handling, etc.),
On Wednesday 24 October 2007 18:30, Melchior FRANZ wrote:
* leee -- Wednesday 24 October 2007:
the FDM operates at a fixed rate (I believe the default is 120 Hz)
but nearly everything else, afaikt, operates at the frame rate,
which varies.
Yes, but most Nasal code does things that
* leee -- Wednesday 24 October 2007:
the A/P controllers and filters, which were the real problem, are
independent of Nasal and would remain a problem until they could
guarantee a fixed rate regardless of the frame rate.
The FDM doesn't run at a fixed rate, either, AFAIK. Yes, it runs
120
FYI: this bug is now fixed in CVS, albeit in a different
way, so it's a good idea to revert that last patch in your
local copies.
m.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find
On Wednesday 24 October 2007 19:15, Melchior FRANZ wrote:
* leee -- Wednesday 24 October 2007:
the A/P controllers and filters, which were the real problem, are
independent of Nasal and would remain a problem until they could
guarantee a fixed rate regardless of the frame rate.
The FDM
On 10/24/07, leee wrote:
Hmm... I always thought that it ran asynchronously from the rest of FG,
at a steady rate. Surely this can't be a good thing?
It really seems to me that the only subsystem in FG where variable
timing won't cause a problem is the display, where it doesn't matter if
On Wednesday 24 October 2007 19:41, Curtis Olson wrote:
On 10/24/07, leee wrote:
Hmm... I always thought that it ran asynchronously from the rest of
FG, at a steady rate. Surely this can't be a good thing?
It really seems to me that the only subsystem in FG where variable
timing won't
* Csaba Halász -- Tuesday 23 October 2007:
In FGNasalListener::call the arguments are set up for the call. [...]
These end up in naNewGhost, and finally [...]
Umm, but the steady increase of refcounters also happens with simple
Nasal bindings, where listeners aren't anywhere close. There's only
On Sunday 21 October 2021:52, Melchior FRANZ wrote:
Yes, but I think that the randomly appearing subsystems are only
victims of other processes -- maybe the stuttering source (which
would then have to be in another thread), but probably just other
processes on the system, that just pull the
* Csaba Halász -- Tuesday 23 October 2007:
Attached patches to sg and fg seem to fix it if tested with
Melchior's gctest.nas.
BTW: In this script I used /input/joysticks/js/axis[3]/binding
as an example for a binding that calls a Nasal function using
cmdarg(). But if your axis[3] doesn't do
Hi Casaba,
On Tuesday 23 October 2007 04:53, Csaba Halász wrote:
I am not familiar with the nasal system, so this might be completely wrong.
Also, I am not sure this has anything to do with the stuttering. But
it seems to be a memory leak, though.
I just applied the two patches to my local
* Durk Talsma -- Tuesday 23 October 2007:
The important thing is that we've touched the very heart of
the problem.
No, the important thing is that the bug was not in the listener
code, as I said from the beginning. ;-)
The Seneca is special in that it attaches listeners to YASim
internal
Csaba Halász schrieb:
...
I am not familiar with the nasal system, so this might be completely wrong.
Also, I am not sure this has anything to do with the stuttering. But
it seems to be a memory leak, though.
Hi
Vivian Meazza schrieb:
Not here, I'm afraid. Very good frame rates using the Buccaneer (70+) but
there are still noticeable pauses over land. None over the ocean tiles. The
pauses, or hesitations do not seem to be associated with any Subsystem
Timing Alert, of which there are almost none.
Hi,
Couldn't test it, waiting that someones will do a
precompiled binary for windows.
But it sounds good, very good though at least there
are still some perfomance issues. I think of AI and
the loading of the scenery tiles.
What Vivian is writing sounds for me like the stutters
of loading of
* Melchior FRANZ -- Sunday 21 October 2007:
Nasal's garbage collector (GC). It *has* a bug.
That's not quite right. The GC might be OK, but it seems
that it isn't invoked on cmdarg() nodes. I'll discuss that
with Andy once he shows up on IRC again.
m.
On 10/22/07, Melchior FRANZ [EMAIL PROTECTED] wrote:
That's not quite right. The GC might be OK, but it seems
that it isn't invoked on cmdarg() nodes. I'll discuss that
with Andy once he shows up on IRC again.
Don't know if Melchior and Andy have arrived at anything while I was
away, but here
* Melchior FRANZ -- Thursday 18 October 2007:
The good news: I have a Nasal binding/script cache almost finished.
I don't know yet if it makes a huge difference, [...]
That's now finished and, as expected, makes firing of bindings between
20% and 90% faster. But I doubt that it will improve any
Hmmm
That's now finished and, as expected, makes firing
of bindings between
20% and 90% faster. But I doubt that it will improve
any stuttering
problem that some people have. (I still don't have
*any* such problem.
I had in the past, and I've only changed the kernel
version, libc, and
* Heiko Schulz -- Sunday 21 October 2007:
So your FGFS runs totally smooth?
Basically, yes. Both branches. But of course, I get irregular
stutters when some new object is to be loaded, because an
MP-player joins in, or I approach KSFO and the Golden Gate
bridge has to be loaded etc. But there's
Melchior FRANZ wrote:
* Melchior FRANZ -- Thursday 18 October 2007:
The good news: I have a Nasal binding/script cache almost finished.
I don't know yet if it makes a huge difference, [...]
..and the nvidia driver since then. Same old crappy hardware.)
Just curious,
* Laurence Vanek -- Sunday 21 October 2007:
Just curious, what does old crappy hardware consist of?
2.4GHz P4, FX5500, 768 MB (I'd accept donations! ;-)
m.
-
This SF.net email is sponsored by: Splunk Inc.
Still
On Sunday 21 October 2007 11:10, Melchior FRANZ wrote:
* Melchior FRANZ -- Thursday 18 October 2007:
The good news: I have a Nasal binding/script cache almost finished.
I don't know yet if it makes a huge difference, [...]
That's now finished and, as expected, makes firing of bindings
On Sunday 21 October 2007 13:37, Melchior FRANZ wrote:
* Heiko Schulz -- Sunday 21 October 2007:
So your FGFS runs totally smooth?
Basically, yes. Both branches. But of course, I get irregular
stutters when some new object is to be loaded, because an
MP-player joins in, or I approach KSFO
* Durk Talsma -- Sunday 21 October 2007:
Well, the idea was indeed to demote the alerts to a lower priority once we
get
the hang of what's going on. Once a few people can confirm that the growing
interval pauses are gone, I believe we're ready for that.
I think they are now useless because
* Durk Talsma -- Sunday 21 October 2007:
Considering that we have many, many shared models, it might be an idea to add
a similar model cache for non aircraft models.
We have that for shared models in plib: simgear/scene/models/modellib.cxx
Those are never freed, though, so we don't do it for
On Sunday 21 October 2007 21:15, Melchior FRANZ wrote:
I think they are now useless because they don't point anywhere that's
related to the stuttering. They demonstrated that the replay system
was slow. It's still slow, but better. And that firing bindings might
have been slow. But I'm not
On Sunday 21 October 2007 21:21, Melchior FRANZ wrote:
* Durk Talsma -- Sunday 21 October 2007:
Considering that we have many, many shared models, it might be an idea to
add a similar model cache for non aircraft models.
We have that for shared models in plib:
* Durk Talsma -- Sunday 21 October 2007:
On Sunday 21 October 2007 21:15, Melchior FRANZ wrote:
And the other subsystems get random appearances on the
list, and it doesn't look like there's a pattern.
FWIW, the new statistics based function is a bit more adaptive in that it
only
* Melchior FRANZ -- Sunday 21 October 2007:
Try the attached Nasal script.
But before you do, change refcount to references. I just committed
that to CVS to confuse everybody. :-)
props.globals.getNode(/sim/aircraft).getAttribute(references)
does now return the reference counter -- the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Durk Talsma wrote:
On Sunday 21 October 2007 13:37, Melchior FRANZ wrote:
...
The OSG branch doesn't have a caching mechanism, and if I understood Mathias
correctly, that would also not be necessary. I've been experimenting with
that a bit
* Durk Talsma -- Sunday 30 September 2007:
Secondly, there are a selected number of processes that take
disproportionally long to execute. The most significant one I
found sofar is a call in src/Input/input.cxx (around line 911).
I have surrounded this statement by debug timestamp information:
Hi Olaf,
On Tuesday 02 October 2007 21:52, Olaf Flebbe wrote:
Hi Durk,
There are a few interesting observations to make in this respect. I do
believe there is a memory leak in FlightGear. Probably a major one in the
scenery tile loader. As reported previously, I routinely let FlightGear
On Monday 01 October 2007 22:20, Durk Talsma wrote:
I will probably try running a valgrind session sometime this week (yohoo, 1
hour to just get past initialization, and 1 frame every 20 seconds. :-) ).
And also try running vmstat
FWIW, I did run a short valgrind session. Execution time
Hi,
It is in in OSG too - my first report was for OSG!
Greetings
HHS
--- Olaf Flebbe [EMAIL PROTECTED] schrieb:
Hi Durk,
There are a few interesting observations to make
in this respect. I do believe
there is a memory leak in FlightGear. Probably a
major one in the scenery
tile
On Sunday 30 September 2007 22:15, Tim Moore wrote:
The majority of calls behave nicely finish executing
within 10 ms. A few can actually take more than a second.
This sounds like a page fault / thrashing problem, perhaps caused by memory
bloat elsewhere. Can you get some system statistics
* Durk Talsma -- Monday 01 October 2007:
I think we had some reports on stutter showing up on fgfs devel
late last year. Probably around December. I'd say that around
October last year everything was still reasonably smooth.
I wrote this on 2006/2/25 to fgfs-devel with subject
Re: AI problems
Hi,
It looks like I'm beginning to get a bit of a handle on the periodic hang-ups
appearing in FlightGear/Plib.
All tests ran on an AMD Athlon XP 2400+, 1024 MB ram, with a GeForce FX 5700
(256 mb texture ram IIRC) video card (AGP based). Suse Linux 10.2 is
installed, and FlightGear,
* Durk Talsma -- Sunday 30 September 2007:
Thirdly, there is a relation between execution time and listeners,
Err ... Nasal listeners trigger Nasal code when the listened-to property
is written to. Executed code costs cpu cycles. Anyone surprised?
If listeners are used badly and trigger bad
* Melchior FRANZ -- Sunday 30 September 2007:
If listeners are used badly and trigger bad code, then this will, of
course, hurt the framerate. But that's not because listeners are bad.
I have to add, though, that the listener code in hsi.nas doesn't look
particularly slow, so it shouldn't cause
Hi Durk,
Firstly, yesterday I managed to speed-up the replay system, by using
dynamic allocation instead of pushing copies of rather large objects into
the STL lists. Using the timestamping code I mentioned yesterday, and
committed to CVS earler today, I found that memory allocation was very
On Sunday 30 September 2007 17:14, Melchior FRANZ wrote:
* Durk Talsma -- Sunday 30 September 2007:
Thirdly, there is a relation between execution time and listeners,
Err ... Nasal listeners trigger Nasal code when the listened-to property
is written to. Executed code costs cpu cycles.
On Sunday 30 September 2007 18:43, Manuel Massing wrote:
Concerning the replay subsystem, I also found what appears to be a c'n'p
error in FGReplay::init(), which results in the long term queue not being
cleared. Probably not significant in this case, though...
Hi Manuel,
Yes, I saw that
* Durk Talsma -- Sunday 30 September 2007:
Although most people will have a global idea as to what listeners
are, I don't think that *that* many people are aware of the fact
that the actual setValue function is the very same code that calls
these Nasal functions.
Ah, ok. Indeed, things can
56 matches
Mail list logo
