> 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
To get both fine step and constant rate modes, could it be implemented something like the standard PC keyboard interface? That is you get a single "click" if you press the button for less than 0.2 second or so, and only after that does it go into "bananas per second" mode. Richard _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
