Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
From mathieu....@gmail.com on May 03, 2011 08:59:31
A 1:1 translation means that if you double your mouse speed, your rotation speed will double. This aims to produce a better PC-feel.
Original issue: http://code.google.com/p/diyps3controller/issues/detail?id=76
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)
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.
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.
Here the best configuration we've found in the current release (without mine modification): http://pastebin.com/2r8pPdnf.
The line code iam refering to is found in core/config.c: function mouse2axis.
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:
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.
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).
Did you try this on any other game?
Your implementation seems to do more than that. Are you applying compensations for rounding errors?
No. Today or tomorrow i will test on two others fps games.
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.
The input motion residue was incorrect in the dev-mouse branch. I fixed it using the following approximation:
Also, I tried your mouse2axis_enhancement branch, but it did not work (I get no output motion). Is there anything you forgot to push?