Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

1:1 translation #78

Open
matlo opened this issue Nov 27, 2013 · 20 comments
Open

1:1 translation #78

matlo opened this issue Nov 27, 2013 · 20 comments

Comments

@matlo
Copy link
Owner

@matlo matlo commented Nov 27, 2013

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.

See http://diy-machine.blogspot.com/2011/04/whats-next.html

Original issue: http://code.google.com/p/diyps3controller/issues/detail?id=76

@matlo
Copy link
Owner Author

@matlo matlo commented Nov 27, 2013

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

Labels: -Priority-Medium Priority-High

@matlo
Copy link
Owner Author

@matlo matlo commented Nov 27, 2013

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.

@matlo
Copy link
Owner Author

@matlo matlo commented Nov 27, 2013

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.

@matlo
Copy link
Owner Author

@matlo matlo commented Nov 27, 2013

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

Labels: -Priority-High Priority-Medium

@matlo
Copy link
Owner Author

@matlo matlo commented Nov 27, 2013

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

Labels: -Priority-Medium Priority-Low

@matlo matlo closed this Nov 27, 2013
@matlo matlo reopened this Nov 27, 2013
@Cybereu
Copy link

@Cybereu Cybereu commented Aug 23, 2016

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

@matlo
Copy link
Owner Author

@matlo matlo commented Aug 23, 2016

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

@Lucashsmello
Copy link

@Lucashsmello Lucashsmello commented Nov 24, 2016

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);

@brandons305
Copy link

@brandons305 brandons305 commented Nov 24, 2016

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
Copy link
Owner Author

@matlo matlo commented Nov 24, 2016

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

@brandons305
Copy link

@brandons305 brandons305 commented Nov 25, 2016

@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

@brandons305
Copy link

@brandons305 brandons305 commented Nov 25, 2016

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

@matlo
Copy link
Owner Author

@matlo matlo commented Nov 25, 2016

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

@Lucashsmello
Copy link

@Lucashsmello Lucashsmello commented Apr 17, 2018

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.

@matlo
Copy link
Owner Author

@matlo matlo commented Apr 18, 2018

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

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?

@Lucashsmello
Copy link

@Lucashsmello Lucashsmello commented Apr 21, 2018

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.

@matlo
Copy link
Owner Author

@matlo matlo commented Apr 21, 2018

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 😃

@matlo
Copy link
Owner Author

@matlo matlo commented Apr 30, 2018

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?

@matlo
Copy link
Owner Author

@matlo matlo commented May 23, 2018

Any feedback on this?

@Lucashsmello
Copy link

@Lucashsmello Lucashsmello commented May 24, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.