Julian Foad <[EMAIL PROTECTED]> said:
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).
It is possible, but I can't think of any examples. I wouldn't want the trim wheel to run slowly when my computer is heavily loaded. That would just be a nuisance. After all, any computer since the 1980s has enough power to operate these controls with plenty of speed AND smoothness if the software is written appropriately.
One way to increase resolution without sacrificing speed is to use "acceleration": when you press the key, the control moves slowly to begin with and then speeds up. This is very appropriate for knobs on the instrument panel, because a real-life knob can be turned both slowly-and-accurately and fast.
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).
We could, but do you really want to use fixed steps at a variable rate for your trim control or for anything else, given alternatives?
As I mentioned earlier...controlling the update frequency doesn't seem necessary to me right now.
I agree.
So the proposals are:
1. Specified step size; undetermined step time. This is what we have now and isn't good enough.
2. Specified step size; fixed step time (e.g. 0.01 second). This actually means that the step size implies the rate of change.
3. Specified rate of change. As far as the binding is concerned, the specified <rate> in bananas per second is equivalent to the <step> value in (2) but a factor of 100 bigger; or it could be specified in "bananas per centisecond" so that the specified value is exactly the same as the <step> value in (2). As far as the implementation is concerned, we have the freedom to implement it as a fixed-frequency update, or a variable-frequency update.
The only differences between (2) and (3) as far as the user is concerned are a possible factor of 100 difference in the value specified in the binding (no big deal) and the fact that <step> always guarantees that the control moves in whole multiples of the specified step. Is this latter point important? I think it might be relied upon by the radio tuning controls, for example. Therefore (2) is a "safer" method.
Other enhancements like acceleration are independent of this choice and can be added later.
Choice of update frequency:
A. Fast enough to capture the duration of the button press fairly accurately. About 20 to 40 Hz corresponds to human accuracy in my opinion.
B. Smooth enough for control purposes. If a flight control position is updated less frequently than the FDM calculations at running, then the aircraft will shake. Should update at the FDM rate or a multiple of it.
C. Smooth enough for visual feedback (where the control being moved is directly visible). Should update at the frame rate or a multiple of it.
In order to match the update rate to the FDM rate and/or frame rate, if those can vary, then proposal (3) would be required.
For the time being, I am in favour of Melchior's patch, with a fixed update frequency of (say) 100 Hz, or perhaps 120 Hz if the FDMs are fixed at that frequency.
- Julian
_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
