> Yes. You have produced a very nice piece of work which gives variable
> results in different systems. We need to at least understand the cause
> and try to fix it
GC according to what I can test.
> Pity you didn't use standard scenery. I don't think custom scenery and
> the ufo will produce representative results.
The ufo minimizes other interfering Nasal and gives me the highest framerate,
so it's a good test case to see problems which show up for high framerate.
Custom scenery is because I fly that most of the time, so just bad habit.
> Loading and unloading scenery tiles every few seconds? Any evidence for
> that?
With high visibility and the ufo at 500 kt? You bet there's tiles loading every
few seconds...
> Yes it probably does. And we should be trying to eliminating these
> wherever feasible. And don't forget that there's Nasal everywhere which is
> doing
> its Garbage Collection.
GC is not relevant here, since there are no visible framerate delayes when I
remain static, but they are there when I move - Nasal or GC shouldn't depend on
my state of motion.
> No that is not what I'm talking about. Altering the view changes the
> frame
> rate here, shaders or not, just try looking at KSFO from the air and then
> away from it.
> The issue I was on about is uneven framerates with big differences
> between
> the worst and average framerate. Are you seeing shaders causing that?
As I explained before, yes, I'm seeing precisely that in turns and my
interpretation is that I'm seeing stuff being loaded into the scene and
unloaded from the scene. Shaders have a substantial impact there - turning into
ocean-dominated scenery causes uneven framerate here till I end my turn.
> As I said - here it never gets back to normal, but ThorstenB explained
> that we are not unloading object when disabling, and that a restart is
> needed.
As far as I can measure it gets back to normal here. Might have to do with the
lack of Nasal in the ufo.
> They are inherently problematic, the only question is how much of a
> problem,
> but sometimes they're unavoidable.
>
> What's with this one?
>
> setsize(terrain_n,40);
> for(var j=0;j<40;j=j+1){terrain_n[j]=0;}
>
> can't this be:
>
> setsize(terrain_n=[],40);
This runs only once at startup, not inside any of the continuous loops. But it
could be changed.
> Do we need setsize() at all? I don't see it much used outside Advanced
> Weather.
It allows to cut elements out of a vector, which is very neat. No idea if there
is another way of doing that in Nasal.
> Concorde has of the order of 6000 lines of active code, and yes, it
> displays
> exactly the same discontinuities as Advanced Weather (approx. 10,000
> lines
> of code). So far, I have not found any other examples.
Vostok seems to have around 5000, MiG-15bis has 7000+ lines, the Garmin GPS
comes with ~4000 lines of Nasal; there's the bombable air combat package (since
as far as I know air combat features wouldn't get committed, anyone without the
infrastructure to generate binaries for various system is practically forced to
use Nasal since the number of users who would use air-combat feature patches
and then compile is very limited, whereas distributing Nasal files one can
reach at least some users),...
...as I said, it's here to stay.
> What an odd metaphor - you very definitely do the first , while waiting
> for the second. If the fuse box cannot be fixed, then you are stuck with the
> first, and that's where we are right now. Let's hope there is a solution.
Then why don't you simply try running Advanced Weather 'lightl? After all, it's
a modular system all along.
Testing for 5 minutes and 500 km, it seems to run fine here with
dynamics-loop-flag=0
timing-loop-flag=0
effect-loop-flag=0
buffer-loop-flag=0
effect-loop-flag=0
which leaves you all the visuals and takes out the harder-to-spot details (2d
clouds no longer move, no evolution of convective clouds, no working thermals,
weather doesn't drift with the wind, only clouds do, so weather doesn't change
if you wait at a location, no rain (isn't working anyway right now...),...
According to your table, that takes care of a fair share of problems. Edit
'set_tile()' in Nasal/local_weather/local_weather.nas to start the loops you'd
like to have. We might even have a checkbox in the menu for the purpose.
But as I said, I think really the GC needs to be addressed. There's only so
much hacking around the actual problem one can do.
I am at the moment throwing unused code out - no idea if it will help much, but
it will reduce the line count somewhat.
I see that it'd be possible to port weather effects to C++ if anyone would want
to work on that - this is stable code from my side, I haven't touched it for
ages, it would be useful in more applications (think of localized turbulence
behind starting AI aircraft for instance) and it is very modular - so I'm all
for doing that.
> Yes, I was around when Nasal was introduced to Flightgear. Up to now it's
> been a few 100s of lines, not many 1000s. We have long been aware that GC
> could cause problems, but haven't fixed it because the effects weren't
> too
> bad while Nasal was small and framerates were low, and we had no obvious
> solution. Now Advanced Weather and Concorde have exposed the problem.
Right, a problem is that I've possibly studied all Nasal documentation I could
get without finding any reference of the GC problem - that was only transmitted
to me much later. I think you'll find that most Nasal users are not aware of
any such problems, because it's not documented anywhere. It doesn't help so
much if you are aware of it.
> I reiterate:
>
> Nasal is bad. Big Nasal is worse, small Nasal is not so bad.
No, the current GC is bad, and big Nasal shows this while small Nasal doesn't.
> Execution of loops at other than main loop rate is bad. If the
> deferred loop does a lot then this will show up as a stutter, if they do
> not do much, then they aren't needed.
A decision to build a weather tile or not doesn't do much, but is definitely
needed. Most slow loops are admin loops which monitor the situation to see if
some action should be taken.
> I also suspect that deferred loops
> can interact unpredictably with other deferred loops (a bit like waves in
> the ocean) to produce a rogue stutter. I tried this in C++ during my
> development of AI stuff, I even tried starting at random intervals, but I
> discovered that letting Fg do its own thing was better.
They probably can in theory, but at least I have never been able to measure
that effect in the background of normal framerate fluctuations.
* Thorsten
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Flightgear-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
