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.


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

Reply via email to