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 on YASim properties are > special in that those can change several times per frame, and > one may indeed want the listener triggered every time. But this > should be a deliberate decision, not an accident.) >
This touches on the area that became a show-stopper for me and while it's good news to see some of the problems being chased down and cleared imho there are still some vital things that need to be addressed. The problem, as I see it, is that there are two different timing regimes in FG: the fixed rate FDM timing and the variable frame-rate timing. That is, 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. This means that if I'm trying to use Nasal (and the A/P PID controllers and filters) in a FBW framework not only do I need them to run at a specified fixed and non-varying rate but ideally I'd want them to run at the FDM fixed rate and in lock-step with it because if I just run these subsystems at the FDM fixed rate, but not locked to the FDM clock, they are likely to drift and I'd end up getting an effective rate that varied between the FDM rate and the FDM rate/2 as they drift into and out of synchronisation. Because 120 Hz isn't really that high, in the context of GHz processing speeds, I would have thought Nasal would be ok for this purpose but am I expecting too much of it? Perhaps the real problem is that nearly every other subsystem, apart from the FDM, get their turn on the CPU within the frame-rate loop and although this would seem to make obvious sense, because the graphics sub-system is by far the greatest user of resources, I'd suggest that if the other subsystems use so little of the available resources, giving them priority over the graphics would have a negligible impact on the frame rate, which is variable according to graphics load anyway. For example, if the graphics subsystem uses 95% of resources to produce 40 fps it's still likely to return > 35 fps if it's only given 90% of resources (and anything much over 25-30 fps is wasted on human eyes anyway). Perhaps I'm just using the wrong approach but like I said, expecting 100-200 Hz rates doesn't seem too ambitious in the context of GHz processors. If, however, there are good reasons why Nasal can't run at these rates (and the A/P PID controllers and filters, being time based _need_ to run at fixed rates in any case), what would be the best solution? LeeE ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
