Game Input MultipleXer

I am coding my own USBXLATER thingy, and the stick "acceleration" in BF4 is very noticable

I just want to know, where in the project SVN can I see the math formula that eliminates the acceleration?

I am looking for something like "thumbstick_x = function(mouse_move_x)", I need to know what the "function" is.

Thanks

you know what, never mind, I came up with my own solution

I took my device, set it to manually output specific X axis movement values, and took video recording of the game. For different X speeds, I calculate the in-game rotation speed using the video recording.

Once I had all the data points, I did a cubic curve of best fit calculation, and calculated the adjustment required to achieve a straight line instead of a curve

Applying the adjustments to X to form a series of Y, I get a curve that resembles a quadratic, so I can easily get y = a * x ^ 2 + b * x + c

Edit: Hmm... something is screwy with the equation once it's implemented into C, so I generated a lookup table instead.

This is the actual GIMX implementation:

• cumulate the mouse motion vectors over a period (and store the value in a circular buffer)
• apply some smoothing as detailed at http://www.flipcode.com/archives/Smooth ... ring.shtml
• process the resulting mouse motion event (void cfg_process_event(GE_Event* event) in core/config.c)
• the final calculation is done in the static double mouse2axis(...) function (which I need to refactor... the list of arguments is way too long)
  It does something like value = dead zone + sensitivity * val ^ acceleration.
  It returns the motion residue so as to add it the next period (this residue is discarded when the motion stops).

frank26080115 wrote:For different X speeds, I calculate the in-game rotation speed using the video recording.

Did you manage to automate this process?

EDIT: I forgot to mention that the dead zone has to be altered for diagonal movements (most games use a circular dead zone shape).

Thanks

So I should be doing all calculations in polar coordinates first, and then only translating to cartesian coordinates in the last step? (your code shows that the curves are applied in cartesian, but deadzone is calculated in polar, very confusing, is this how games actually work?)

I'm usually hesitant on adding floating point calculations into embedded projects, even more reluctant about trigonometry

I'll try filtering the mouse values.

I don't think I can automate the video recording thing, but I'm only taking 12 different samples. It doesn't take long to do it by hand. Automating it would probably involve either some form of video capture or a high frame rate camera, plus a lot of image processing.

The dead zone is calculated in cartesian coordinates.
For a circular dead zone (x!=0 and y!=0):

• dzx = dz*cos(atan(fabs(y/x)));
• dzy = dz*sin(atan(fabs(y/x)));

wow filtering and the anti-acceleration makes an unbelievable difference. I'm still using a look-up table instead of live calculations.

The STM32F2 has an entire megabyte of flash so it's not a problem at all to store a 128 byte table.

Headshots are soooo easy now

A high-end mouse that has a high DPI (5700 or more) capability (and 16bit reports) help a lot to keep movement smooth at slow speeds (without any smoothing).

My mouse uses 12 bits, two axis packed into 3 bytes, very annoying to decode

Battlefield 4's vehicle controls have a different curve so I made my ALT key give my mouse a gain of x16 or else it is unplayable.