Curtis L. Olson writes: > > Norman Vine writes: > > > > This method should also be *considerably* faster then the current > > Panel code in that the actual updating of the instruments can be > > done on a round robin basis reducing the work done per pass as > > all but the instrument texture being reconstructed on this pass > > will just be a single texture layer probably rendered as a quad ! > > > > An individual instruments updating could perhaps be delayed a > > bit more further improving performance if the actual instrument > > being modeled had a 'real' sampling rate we wanted to simulate > > > > lazy-evaluation-yields-fast-programs'ly yr's > > One of the knocks against programs like Fly and MSFS is their horribly > slow instrument update rate. That's one thing poeple really like > about programs like X-Plane and FlightGear. You can actually fly off > the instruments because they move very smoothly ... because they are > updated every frame. And we would also need to be careful of texture > space since this sort of scheme is going to increase texture ram > usage.
Good point .....but ..... If we can half the frame rate hit of the Panel using this kind of scheme, and I expect even a better boost, then we could render half the instruments one frame and the other half the next and still have the ~same instrument update rate as we currently have and an overall ~25% boost in framerate when the Panel is displayed (1) This is assuming that the Panel rendering hit is approx half of the overall cost of a complete frame Norman _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
