leee wrote:
> I'm not really thinking in terms of 'threading' at all, which I > think is a very limited and half-house sort of technique. But > neither though do I think it needs to be thought of as a pure real > time system. Rather, I'm thinking in terms of the external FDM > mechanism already present in FG. Running the FDM on it's own > hardware system doesn't need to be any more real time than the FDM > running within FG on the same system but because it's not going to > be limited by the frame rate it could safely be run much faster and > with proportionately more consistency than with FG. If you're > running it at say 100Hz within FG I would expect to be able to run > it several times faster, if not tens of times faster if the system > it was running on wasn't spending most of its time rendering. > You'll still get a variation in the rate that the FDM runs at but I > suspect that the variation would be about the same in absolute > terms. Let's say that if we get a variation of +/- 10 iteration > difference per second running within FG it would probably be about > the same running on its own system, but as we're running at a > higher rate the difference is proprotionally smaller, perhaps down > from 10% to 1%. I agree here, putting the FDM in it's own process would be a good idea. Erik ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
