Norman Vine writes: > True -- but then again I have sped the program up ~15% even more if > you consider the model view, within the last month. Heck I > replaced five matrix multiplies with one for every moving part in > the model display code alone :-))
Norm -- I am very grateful for your contributions. Most noticably, they reduced the stutter at the start of the model animation for some audio hardware and made the model code cleaner. How did you arrive at the 15% figure, though? My framerate hasn't changed at all for a long time. Perhaps it has something to do with the combination of graphics hardware and CPU people are using -- I have a relatively fast CPU (c.a. 900MHZ) but only a slow-to-middle-range GPU (GeForce2), so I may be more GPU- than CPU-limited. Perhaps someone running with, say, a GeForce3 and a 400MHZ CPU will see the framerate changes I'm missing. > So I think we can afford to use one here, > where there actually is a reason for it ! We're not worried about the processing cost of a matrix multiply. I would be shocked if adding an extra 100 matrix multiplies changed the frame rate by more than a fraction of a frame per second. We're worried about the simplicity and consistency of the interface and the maintainability of the code. > The Viewer ( please lets come up with a better name > code should > only be concerned with the orientations ect that are 'inherent' in the > world 'situation' and the GUI module should handle user interactions > or am I missing something 'obvious' :-) The user input (GUI or otherwise) tells the viewer *what* it wants, and the viewer figures out *how* to do it. I shouldn't have to add quats or matrices into the network, keyboard or joystick handling code, and by analogy, they don't belong in the mouse code either. All the best, David -- David Megginson [EMAIL PROTECTED] _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
