Re: [Flightgear-devel] Re: how to fix joystick config files
All you need to do is specify: interval-sec0.05/interval-sec for the binding in question and you will get a 20 per second repeat rate. Makes sense to me. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: how to fix joystick config files
Jim Wilson wrote: Julian Foad [EMAIL PROTECTED] said: I wouldn't want the trim wheel to run slowly when my computer is heavily loaded. You would if you were unable to trim because the step sizes were to big and you wanted to trim from the joystick. Yes, OK, but we're going to avoid that by making sure that the update rate is high enough when a slow computer is heavily loaded, and perhaps faster otherwise. I'll re-phrase my objection as: I wouldn't want the trim wheel to spin much faster when looking at the sky than when looking at complex scenery. 1. Specified step size; undetermined step time. This is what we have now and isn't good enough. Only not good enough if you insist that the joystick configs work the same and on all systems without adjustment. Yes, but I think that is a reasonable thing to request if it can be done without breaking your requirement for ultimate smoothness, and it can. 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. That was Erik's patch. Sorry for the misattribution, Eric. What I'd like to do, if this is what everyone wants, I'm having difficulty understanding this part; please bear with me trying to clarify what you mean. is to add a property to the joystick binding structure called interval-sec That defines the repetition interval for a repeating step action? (to be used on the bindings that have low/high defined--axis emulation). If it is defined then use it (or default it to zero). If it is defined then update the specified axis and its two virtual buttons at the specified interval. If it is not defined, then default to the standard system-wide value that we are talking about elsewhere: something like 0.01 s. Yes? That way only the bindings that require such timing (e.g. rudder controls) will be affected. You mean that you would specify interval-sec0.01/interval-sec for the rudder because you want it to move at a fixed rate, but you would leave some other controls to move at a rate that varies with CPU speed and load? If this is because of the insufficient resolution problem, I think we can solve the resolution problem. If we have a problem of the resolution being insufficient because we need to specify a large step size because updates are too slow, then I think we can solve that by making the update rate fast; no longer equal to the frame rate, but fixed at say 100 Hz or the FDM rate. If this is acceptable then I'll work on adding this to the patch. I can see that virtual buttons at the end of an axis have been left out of this patch so far. I would say they should behave in the same way as real buttons, so something needs to be done. But let's see if we can find a common solution. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: how to fix joystick config files
Jim Wilson wrote: Melchior FRANZ [EMAIL PROTECTED] said: That would be =all= repeatable bindings then. The change of view direction/elevation simulates head movement. Braking simulates feet movement on pedals. Mixture ... you get the point. Every set of repeatable buttons emulates (analog) human-machine interaction. I cannot imagine why head movement should be ten times as fast on a faster machine. It's still the same pilot. Not all pilots are the same. Some heads are faster than others. That's a completely separate issue. And even though some like to use the mouse for trim wheels, I like the joystick hat. And I like it speedy and high resolution for accurate trimming. Lets just do it with the bindings that are presenting real problems, and stop worrying about slowing down the fast machines so they match the slower machines. I don't agree. I've completed the patch (took less time than writing these last two emails on the subject). All you need to do is specify: interval-sec0.05/interval-sec for the binding in question and you will get a 20 per second repeat rate. It works. If this makes sense to anyone besides myself, I'll submit the patch. It only makes sense to me as a temporary improvement over the status quo. I don't think it makes sense for any repeatable bindings NOT to have a known rate of change (either fixed step size and fixed update frequency, or fixed rate of change with a variable update frequency). But I haven't written code to implement what I'm saying. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: how to fix joystick config files
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
Re: [Flightgear-devel] Re: how to fix joystick config files
Melchior FRANZ [EMAIL PROTECTED] said: But again: all this won't be a problem for =me=. I know how to fix it for my computer, and it'll be a while until I can afford a faster one, anyway. So, in fact, I don't really care. (Maybe the thousand users are what matters ...) Ummm...then that means it would be ok with you to adopt Julian's idea? ::: duck ::: :-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: how to fix joystick config files
Jim Wilson writes: Actually after thinking about it, it seems to me that we don't need to have an update frequency setting for joytsicks (fixed or adjustable). Users can adjust the step sizes on individual buttons or axes in the xml file for the joystick. Adjusting step sizes without locking in an update frequency (even if adjustable) gives the most flexibility. Currently, the actual update frequency depends on the framerate. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: how to fix joystick config files
Jim Wilson wrote: 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
Re: [Flightgear-devel] Re: how to fix joystick config files
Melchior FRANZ wrote: What are repeatable buttons used for? - to let a digital input device (regular button, or digital hat switch) emulate an analog device What about keyboard buttons (keys)? Are they not going to work in the same way? Or are they already handled properly (FGFS implementing a fixed repeat rate while a key is held down)? I looked through all joystick config files and here is what repeatable buttons are used for: - set the view direction elevation via hat switch - set rudder elevator aileron trim - set engine boost mixture propeller pitch - set rudder (only in my own joystick file :-) (and brakes, you added) That's a useful list to look at. For instance, none of those things require to move in exact multiples of a specified step size, unlike the radio tuning which might. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: how to fix joystick config files
Julian Foad [EMAIL PROTECTED] said: 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. You would if you were unable to trim because the step sizes were to big and you wanted to trim from the joystick. 1. Specified step size; undetermined step time. This is what we have now and isn't good enough. Only not good enough if you insist that the joystick configs work the same and on all systems without adjustment. 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. That was Erik's patch. What I'd like to do, if this is what everyone wants, is to add a property to the joystick binding structure called interval-sec (to be used on the bindings that have low/high defined--axis emulation). If it is defined then use it (or default it to zero). That way only the bindings that require such timing (e.g. rudder controls) will be affected. If this is acceptable then I'll work on adding this to the patch. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: how to fix joystick config files
Melchior FRANZ [EMAIL PROTECTED] said: That would be =all= repeatable bindings then. The change of view direction/elevation simulates head movement. Braking simulates feet movement on pedals. Mixture ... you get the point. Every set of repeatable buttons emulates (analog) human-machine interaction. I cannot imagine why head movement should be ten times as fast on a faster machine. It's still the same pilot. Not all pilots are the same. Some heads are faster than others. And even though some like to use the mouse for trim wheels, I like the joystick hat. And I like it speedy and high resolution for accurate trimming. Lets just do it with the bindings that are presenting real problems, and stop worrying about slowing down the fast machines so they match the slower machines. I've completed the patch (took less time than writing these last two emails on the subject). All you need to do is specify: interval-sec0.05/interval-sec for the binding in question and you will get a 20 per second repeat rate. It works. If this makes sense to anyone besides myself, I'll submit the patch. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: how to fix joystick config files
* Jim Wilson -- Saturday 28 June 2003 23:02: If I remember this patch correctly, the repeat frequency was hard coded. It should be defined in a property, and eventually adjustable in a gui dialog for controllers. Ideally at some point we could adjust sensitivity/repeat per control (individual buttons or axes). But at a minimum that single value should be a property. Melchior FRANZ wrote: So, in a joystick definition like the following ... what do you want the step size (-0.02) be set for? For a 2.8GHz CPU, or for a 266MHz CPU? It will be too small for a slow one, but too much for a fast one. This has to be a cpu clock independent value. I think Jim is assuming that the binding is going to specify a rate of change of value with time (bananas per second) rather than a step amount. This would be sensible, but is NOT what we have at present, and not the way Melchior is thinking about it, hence the misunderstanding. Then (I think) Jim is saying that the frequency at which these values are updated should not be fixed, but should be adjustable by the user, so the user can get better _smoothness_ (but the same rate of change) when the platform is capable of it. Is that right, Jim? But I'm really tired of this topic now and won't ever mention it again (except if people ask, why the joystick definition files that come with fgfs don't work on their computers, of course.) People aren't being deliberately obstructive. It's quite common for a misunderstanding like that to arise on a mailing list. 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. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: how to fix joystick config files
My apologies, I started to reply to Melchior's message earlier and lost it with a toddler induced crash of the xserver. Actually after thinking about it, it seems to me that we don't need to have an update frequency setting for joytsicks (fixed or adjustable). Users can adjust the step sizes on individual buttons or axes in the xml file for the joystick. Adjusting step sizes without locking in an update frequency (even if adjustable) gives the most flexibility. If there is a further solution required it probably ought to be coming up with a way for end users to easily adjust the joystick configurations for their systems. Maybe a gui dialog with a save option would do the trick. Best, Jim Julian Foad [EMAIL PROTECTED] said: * Jim Wilson -- Saturday 28 June 2003 23:02: If I remember this patch correctly, the repeat frequency was hard coded. It should be defined in a property, and eventually adjustable in a gui dialog for controllers. Ideally at some point we could adjust sensitivity/repeat per control (individual buttons or axes). But at a minimum that single value should be a property. Melchior FRANZ wrote: So, in a joystick definition like the following ... what do you want the step size (-0.02) be set for? For a 2.8GHz CPU, or for a 266MHz CPU? It will be too small for a slow one, but too much for a fast one. This has to be a cpu clock independent value. I think Jim is assuming that the binding is going to specify a rate of change of value with time (bananas per second) rather than a step amount. This would be sensible, but is NOT what we have at present, and not the way Melchior is thinking about it, hence the misunderstanding. Then (I think) Jim is saying that the frequency at which these values are updated should not be fixed, but should be adjustable by the user, so the user can get better _smoothness_ (but the same rate of change) when the platform is capable of it. Is that right, Jim? But I'm really tired of this topic now and won't ever mention it again (except if people ask, why the joystick definition files that come with fgfs don't work on their computers, of course.) People aren't being deliberately obstructive. It's quite common for a misunderstanding like that to arise on a mailing list. 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. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: how to fix joystick config files
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
