Questions about analog stick values

[hiraken]

I was observing the device monitor and noticed something.
I connected a DualShock 4 or XB1 controller to the Titan two and observed the device monitor without using a script.
When you defeat the analog stick from the neutral state little by little, and look at the value, there is something like a dead zone, and the value represents 0 until you defeat the stick to some extent.
And beyond that dead zone, the value suddenly starts at 20.
When this behavior is represented by a graph, the graph is as follows.

Graph A : Observed value

StickValue_A.png (10.64 KiB) Viewed 839 times

I am wondering about this behavior.
Is this behavior a controller specification? Or is it a Titan two specification?
If this is a Titan two specification, is this specification really correct?

I connected these controllers directly to windows and observed the values in the windows control panel to make sure these controllers I used were not broken.
However, the dead zone did not exist in the value indicated by windows, and it was displayed as a linear value.
From this, I infer that this behavior is not a controller specification, but a titan two specification.

Since the dead zone is originally managed by the game program, I guess that the controller (Titan two) must always output a linear value starting from 0.
Otherwise, the value of 20 or less of the analog stick cannot be detected, so fine adjustments such as making the analog stick sensitive using scripts etc. will not be possible.

Graph B : My guess (Pattern A)

StickValue_B.png (10.86 KiB) Viewed 839 times

Also, even if the dead zone is determined by the controller specifications, it may be wrong that the value starts at 20 immediately after the dead zone is exceeded.
In other words, if the dead zone is a controller specification, isn't it correct to look like the graph below?

Graph C : My guess (Pattern B)

StickValue_C.png (15.31 KiB) Viewed 839 times

Or is there a function or setting item for setting these behaviors that I just missed?
In my memory, GPC1 such as Titan one had a function called deadzone(), but Titan two could not find such a function.

[J2Kbr]

The behavior you noticed and described above is intentional and required for correct merge the inputs of multiple controllers into a single output. It works like this:

1. The input values from the controller on INPUT-A are always registered from 0% to 100% (no "deadzone").

2. A input value from the controller on INPUT-B is registered if:
- (1) the current value (from Input-A) is within the resting range (-20 to 20); AND
- (2) the new value (from Input-B) is outside the resting range.

Also note this does not apply for mouse movement input. With mouse, the values are always registered without "deadzone".

[Buffy]

To add to what J2Kbr said, always plug the controller you want to use into Input-A, and the authentication controller into B.

[bonefisher]

Told you Buffy!

[hiraken]

The behavior you noticed and described above is intentional and required for correct merge the inputs of multiple controllers into a single output. It works like this:

1. The input values from the controller on INPUT-A are always registered from 0% to 100% (no "deadzone").

2. A input value from the controller on INPUT-B is registered if:
- (1) the current value (from Input-A) is within the resting range (-20 to 20); AND
- (2) the new value (from Input-B) is outside the resting range.

Also note this does not apply for mouse movement input. With mouse, the values are always registered without "deadzone".

Sorry for late reply.

I see. I understand.
I confirmed, but surely Titan two behaved as you said.

In addition, I confirmed the following:
For example, when no device is connected to INPUT-A, the analog stick of the INPUT-B controller seems to output all numbers correctly.

> 1. The input values from the controller on INPUT-A are always registered from 0% to 100% (no "deadzone").

In other words, it is not limited to "INPUT-A", but it seems that the port with the higher priority, first detected device, outputs all numbers.
This also seems to be the same for BT connections.

This Titan two specification is quite reasonable, but I have a suggestion to make it more convenient.
I want to be able to specify a preferred port from the GPC program.
Furthermore, I think it would be ideal if the GPC program could specify ports that gave priority to the left stick, right stick, L2, and R2, respectively.

For example,
If the mouse is connected to INPUT-A regardless of which signal the mouse is mapped to, all analog values for INPUT-B will start at 20.
These suggestions don't bother me in most cases by devising the order in which I connect the devices.
However, I use devices in various combinations depending on the game title that I play.
For example, using a mouse and keyboard, using only a controller, using a controller and a mouse, and so on.
I think it is troublesome to change the port to connect the device to change the preferred analog input device for each game title.

[J2Kbr]

In other words, it is not limited to "INPUT-A", but it seems that the port with the higher priority, first detected device, outputs all numbers. This also seems to be the same for BT connections.

You are absolutely correct. This is directly related with priority order:

Code: Select all

USB-A > BT-A > USB-B > BT-B > USB-C > USB-D

I want to be able to specify a preferred port from the GPC program.
Furthermore, I think it would be ideal if the GPC program could specify ports that gave priority to the left stick, right stick, L2, and R2, respectively.

I think this will be possible to implement. I annotated you suggestion in my to do list .

Thank you.