CCP Earworm
C C P
C C P Alliance
75
   |
Posted - 2013.07.05 05:49:00 -
[1] - Quote
5aEKUXeRJGJ27kCDnDVYak4 wrote:After extensive testing, I can confirm that CCP's DS3 aiming is broken.
It is not acceleration, it is not smoothing, it is not aim assist, it is PURE JITTER is being introduced into the aiming.
In the GIMX there is a calibration mode which simulates a set of inputs to test if the game is responding as predicted. It can repeat a series of sweeps of set distances (slowly turn left x amount, quickly turn right x amount) for observation so there is unmistakable that the issue is not in the player or DS3 controller. When I run the test, when in theory moving left X and moving right X (EXACTLY the same amount) should end in the same position, the game will turn the aim either not enough or too much.
This is not related to acceleration, sweeps with different speeds were mixed together and the aim do not solely overshoot/undershoot (which would indicate acceleration) but it jitters back and forth. This is done with aiming assist turned off.
....
There, CCP I've done the work for you. You don't have to mess with your sensitivities anymore, the problem is not there.
Wow, the GIMX looks really cool. We're gonna buy one to test with. Thanks for the heads up on this and your testing, this is very cool stuff.
I want to make this totally clear: The aiming issues on the KB/M are really high priority and we're working on totally overhauling the mouse input system. I've already fixed the core of the problem and it's pending a lot of tweaks and regression tests before it's considered complete. I'll probably post some more info on exactly what we did when we release it, for now all I can say is I think everyone will be really happy with it :)
Warning! Highly technical stuff follows!
Regarding the over/undershooting polling rate and acceleration are the only frame dependent parts of the pad movement. Think of it this way: when the pad input is above a certain threshold it will enter acceleration mode and ramp up to a set max speed. That speed accumulates over every frame discretely so changes in frame rate or when exactly you start ramping down the pad input would make a difference on your ending point.
The same discrete accumulation affects polling rate.
The best test is to sweep with small movements over a long time with steady values (IE keep the input constant). If you change input values the exact moment that change happens during the frame could affect the final result. Also, even with constant input values you should still see +/- a couple of frames because when you start and stop the input test it could fall in different parts of the frame.
To sum up, because we accumulate movement discretely, the GIMX has to be synced to the dust framerate (which of course is impossible for you and very tricky for us as devs) and not move fast enough to trigger acceleration to guarantee 100% repeatable values. Otherwise you'll be off by a couple of frames with constant value input or more if you are sweeping the input.
If you're hungry for more testing, you can take some of this into account and see if it matches your experiences. |