DirectInput is capable of reporting any range of motion for a joystick and translating it. Thus it's possible for 8 bit stick, (range 0 to 255), to report in a 16 bit format unsigned ( 0 to 65,535,) or signed format ( -32768 to 32,768)
http://msdn.microsof...v=vs.85%29.aspx
The way the system should work, is that each integer of joystick output should correspond to a position of the mech's torso. Thus, in a 16 bit unsigned reporting system, with a mech that is capable of rotating 90 degrees to each side. A joystick reporting a value 65,535, should cause the mech's torso to rotate 90 degrees. A report of 49151.34, should rotate the torso to 45 degrees. With a report of 32767.5 being center.
Each degree of rotation per joystick reporting number, is a function of the mech's total possible amount of rotation. Thus a mech which can move it's torso 180 degrees, would move more degrees per joystick reporting number than a mech which can only rotate 90 degrees
49151.34 = 45 degrees of mech rotation; for a mech capable of a total rotation of 90 degrees
49151.34 = 90 degrees of mech rotation; for a mech capable of a total rotation of 180 degrees
546.12 = 1 degree of rotation; for a mech capable of a total rotation of 90 degrees
273.06 = 1 degree of rotation; for a mech capable of a total rotation of 180 degrees
At a joystick report of 10,000:
180 degree rotation capable mech
36.62 degree rotation of the torso
90 degree rotation capable mech
18.31 degree rotation of the torso
The major problem with the system now is that, joystick outputs are not proportional to torso movements. A half deflection of the stick does not correspond to half the torso twist of the mech. Which is the true definition of absolute input control. This is a function of Cryengine reading the reporting position as very large numbers and not handling them well or scaling them proportionally.
What happens is cryengine is setup to read a number as max input. It's probably very low. Thus any report over the max is read as maximum. Which is a problem if sticks are reporting in a 16 bit format via Directinput. As a one third deflection of the stick reports a position of 43,580.11 or 21,953.88 (depending on a left or right defelection) Which from my cursory testing is over the max input in cryengine, thus resulting in a full rotation of the mech's torso.
Even with the large deadzone, that seem to be implemented now, movements from full deflection to half are not possible due to the discrepancy between what cryengine reads as max and what the stick reports as max.
Changing the sensitivity doesn't make the system more useable because it simply caps the max output. The sensitivity setting simply applies a transformation which multiplies the output by a decimal to reduce the reporting position, f(x)=(x*.a), where a is the sensitivity setting.
Thus a sensitivity setting of .02 transforms a joystick output of 65,535 to 1,310.7 and one third deflection of the stick, which reports 43,580.77, is transformed 871.61. So it gives the appearance of increase control-ability, but in fact just mitigates the cryengine position reporting discrepancy by reducing the reported postion to an interger which is within the cryengine reporting range. The same behavior is exhibited by the mouse too, increasing the DPI of the mouse and changing the sensitivity results in the same behavior.
The problem seems fixable though. You would have to get into the C of the CryInput though and maybe tweak the input listener too, in order to adjust the reporting range. Or find away to bypass cryInput and work through DirectInput.
Though, even with a working absolute system, you will need more than a "sensitivity" setting to make absolute inputs work well. The first and probably most important would be what's called a non linearity setting. This would transform the output of stick to a more non linear response by means of a power law. Thus one would have a finer control around the center of the stick, while position reports toward the edge of the joystick would result in greater movement of the mech torso. This function works well f(x) = a*x^3 + (1-a)*x . Where a is the power of the curve set by the player. A works best when is less than 0, and 0 results a normal linear response.
Another input adjustment that will allow players to tweak an absolute control to their own liking would be an axis saturation control. Which is a transformation that functions to alter the min and max input outputs of a the stick. It differs from a sensitivity setting which limits the output to a fixed number.
For example, a mech which can turn 180 degrees. With a sensitivity setting of .5, if the joystick is fully deflected, say to a reporting position of 256, The mech will only turn 90 degrees, as the sensitivity adjustment caps the output to 128. A saturation setting of 2, means that at 128 reporting position of the stick turns the mech 180 degrees. As the 128 is transformed to 256. It's a simple multiplicative transformation. f(x)=(x*a) where a is the saturation setting chosen by the player.
This can be helpful because it means one doesn't full deflect the stick to rotate the mech. Which would be uncomfortable for running a light mech that's either constantly turning it's torso or has the torso constantly fully rotated.
Also be forewarned about testing with a xbox 360 controller as it use XInput which differs from DirectInput and is really only used with 360 Controller. You may need to check how cryinput is interfacing the joysticks too. If it's using Xinput than pretty much everything other than a 360 contronller won't work. Though you can use both API's simultaneously.
http://msdn.microsof...v=vs.85%29.aspx
Hope this helpful I was going to get into how to handel traverse speeds but this is getting long, (hint, use f(x) = a*x^3 + (1-a)*x; where f(x)=Rotation speed and a is derived on the diffrence in the joystick postion between 2 reports. )
EDITED: to correct signed 16 bit integers.
Edited by Grits N Gravy, 18 July 2014 - 02:48 PM.
4
This topic is locked
evilC, on 16 July 2014 - 11:46 AM, said:
