Julian Foad <[EMAIL PROTECTED]> said: > I think what you are proposing is better than the way it is now. However, it should be easy to make it perfect. In your proposal, each binding specifies an amount of change per "step", and you fix the number of steps per second (which previously was varying, being faster on faster machines). The objections are that the smoothness of control operation is limited by this fixed step rate. Instead of that, have the binding specify the amount of change PER SECOND (i.e. the rate of change), and allow the number of steps per second to vary with machine power and load. At each step, the new value is calculated so that the control is moving at the specified rate: value += rate * delta_t. > > That would make the rate of change well defined, but the smoothness would be better on faster machines. I f Jim wants to control the update frequency he can then do so very easily. But the important thing to do first is to define the rate of change rather than the amount per undefined time "step".
This is a sounds good. But it is possible that some controls might be better off sacrificing speed for higher resolution step sizes on certain systems (e.g. trim controls). Then again we could pick and chose which controls use the per second method and which use the fixed steps (in other words, support both). As I mentioned earlier...controlling the update frequency doesn't seem necessary to me right now. Best, Jim _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
