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.

The aiming issues on the KB/M are really high priority

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.

I'll take that bet

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..

That scratched my nerdy itch... but really needs a GRAPH

Warning! Highly technical stuff follows!
[...]
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.

Wat?!

Are you sure the input processing is frame-rate-dependent? I think I misunderstood you, but are you saying that the input behavior is different when looking at someone standing in front of flaming wreckage than it is when looking the other way?

Please, be a nice dev and tell me that all input handling regardless of input device is done at 100 Hz outside the graphics thread based on the best timer the PS3 has available. Please.

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.

By the way there's a universal quarter a second of input lag, unless you run the game at 480p (where it's still there but minimized), that effects aiming as much if not more than this randomness problem. You guys do realize the Dualshock is affected as well right?



Aiming issues with KB/M have top priority in a console game where your target audience is going to primarily be using a controller with analog sticks? Where the aiming is just as bad if not worse? Sigh...

Again, input lag the main culprit here. It's almost certainly a performance issue that could be fixed...

I use a mouse exclusively and I'm gonna be honest, I had no idea aiming was still messed up.

Unless it was re broken in 1.2

I swear I can't figure out what you guys are talking about. Not about the jargen I mean I don't feel my aiming is off. At best I can say there have been a few sniper rounds that made me think, "I swear that should have hit that guy" but nothing to suggest aiming is broken altogether. I can still turn and shoot a dude in the face. What is the problen?

I use a mouse exclusively and I'm gonna be honest, I had no idea aiming was still messed up.

Unless it was re broken in 1.2

I use a mouse exclusively and I'm gonna be honest, I had no idea aiming was still messed up.

Unless it was re broken in 1.2

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.

Read mechanics section for aim assist improvements

I've read this article about how they are going to improve aim assist, which will most likely benefit the DS3 only. I initially thought this was a horrible idea, but if they are implementing it the way it sounds it may really help DS3 people. I've been promoting better controls for all input systems, it seems like this will help with the DS3 fine aiming and tracking, which I can agree needs some work as well.

You're trying to have an advantage over the already advantage of KB/M over DS3.

-XOXO