From mathieu....@gmail.com on May 02, 2011 23:59:42

Labels: -Priority-Medium Priority-High

From mathieu....@gmail.com on May 19, 2011 15:05:54

To perform a 1:1 translation:

First, adjust the multipliers with exponents = 1.

1- set the exponents to something lower than 1 (for ex, subtract 0.05)
2- increase the multipliers so that the speed is correct

Repeat 1 & 2 until it gives a 1:1 movement feeling: the same distance covered by the mouse (whatever the speed) = the same distance covered by the crosshair.

This works well for COD:BO. For this game, the calculated value for the exponent is 0.39.

Note: this is probably false for some games as each game has its own movement rules.

From mathieu....@gmail.com on May 19, 2011 15:14:43

Something prevents such values to work with the current sixaxis emulator:

with high multiplier values, the first position (mouse x or y = +/-1) is too far from the dead zone. This generates some glitches for slow movements, and makes crappy movements along horizontal and vertical axes.

This can be solved by subtracting the first position value to the dead zone. Doing so, the first position is just after the dead zone.

From mathieu....@gmail.com on December 08, 2011 14:58:05

Labels: -Priority-High Priority-Medium

From mathieu....@gmail.com on March 01, 2012 00:24:18

Labels: -Priority-Medium Priority-Low

How much is high multiplier ?
I figure out that i was calibrating that way after a lot trial and error.

This was related to low-DPI mice (below 2000 DPI).

This can be solved by subtracting the first position value to the dead zone. Doing so, the first position is just after the dead zone.

When playing Overwatch, I found that this was actually making low-intensity movements on mouse too much heavy on the target game, whereas high-intensity movements on mouse does a very strong movement.
I removed the code responsible for this and mouse pc-feel was greatly improved (a lot!).

Here the best configuration we've found in the current release (without mine modification): http://pastebin.com/2r8pPdnf.
Note that dead zone is set to 23, and sensibility=11.60, but we actually believe that the deadzone is 14, a much smaller value. The high value for deadzone is to compesate the high value of sensibility. With the modification we changed the deadzone to 14 (and other parameters too).

my-mouse-dpi~=4000
game=Overwatch
Overwatch-ingame-sensibility=100 on both axes.

The line code iam refering to is found in core/config.c: function mouse2axis.
/*
* Subtract the first position to the dead zone (useful for high multipliers).
*/
dz = dz - multiplier;// * pow(1, exp);

how did you go about removing the code responsible for this and having the change apply while utilizing gimx? would like to investigate for myself how this works

Thanks for the tests and suggestions. I'll make it possible to have negative dead zones so that users can compensate high multiplier themselves.

@Lucashsmello how did you go about removing the code responsible for this and having the change apply while utilizing gimx? would like to investigate for myself how this works

@matlo will this change take effect in the most recent version of gimx?

This will take effect in GIMX 6.3. See #414.

First of all, i would like thank matlo for providing us with GIMX.

I've been working deeply on 1:1 mouse to controller axis translation, in special, on Overwatch mechanics. Analyzing Overwatch controller mechanics, i found 3 interesting mechanics that i recently incorporated into GIMX:

• Conservation of x/y ratio: When the game translates the controller input to its corresponding angular speeds, the x/y ratio is preserved.
• Translation is applied on the vector norm: The game has 3 aim types: linear ramp, dual zone and exponential ramp (which it is actually an cubic polynomial). The aim type function is applied on the radius of the input vector. For example: Let (x,y) be the controller input on horizontal and vertical axis respectively, and (x',y') the outputted in-game angular speed. If linear ramp is selected, the norm of (x',y') is a linear function of the norm of (x,y), that is: sqrt(x'²+y'²)=a*sqrt(x²+y²)+b, for some constant a,b.
• Asymmetric compensation of axis: In ds4, for example, the values of an axis are in range -128 to 127. Therefore, there are more negative values than positive values. To compensate this issue, the game makes x produces the same angular speed of -(x+1), for any x>=0, but on the opposite direction.

This 3 mechanics are partially implemented on the current GIMX version. Therefore, i implemented them in a fork of the project: https://github.com/Lucashsmello/GIMX. Currently, i am testing it.

Some day i will publish all the details. It is too much to write in a comment section.

Hi Lucas,

Thanks a lot for the comment! Been a long time I did not work on the mouse translation algorithm.

This makes sense. Preserving x/y equals preserving y/x which is the tangent of the angle. In the end this means preserving the angle = the movement direction.

I made a graph (spreadsheet attached) showing the effect with the simplified equation t(z)=mul*pow(z,exp).

translation.zip

Did you try this on any other game?

Your implementation seems to do more than that. Are you applying compensations for rounding errors?

Did you try this on any other game?

No. Today or tomorrow i will test on two others fps games.

Your implementation seems to do more than that. Are you applying compensations for rounding errors?

I return motion_residue in a similar way to the original code. There is a method named fixRoundingError that i use to find the closest possible move to the desired one. For example, if for a specific mouse input i have calculated that the corresponding controller movement should be (27.7, 83.8), i test the integers around it that minimizes the motion_residue, which may be (27,84) or (28,84) depending on the parameters (exp and dead zone). I'am currently writing a document that will make all clear.

I pushed another translation algorithm here: https://github.com/matlo/GIMX/tree/dev-mouse

I tested it with KillZone on PS4, it is a game changing improvement 😃

The input motion residue was incorrect in the dev-mouse branch. I fixed it using the following approximation:

theta = gamma * alpha / beta

with:

alpha: input motion angle
beta: desired output motion angle
gamma: truncated output motion angle
theta: truncated input motion angle

Also, I tried your mouse2axis_enhancement branch, but it did not work (I get no output motion). Is there anything you forgot to push?

Any feedback on this?

I'm sorry for being so late. I fixed some issues in my last commits. I pushed them today. I tested it with Overwatch and Horizon on PS4 and it is working fine.