There’s a very drastic error in your code, and I’ll outline that error at the bottom of my post.
But even without that error you’d still have lag issues with the input system, because you’re caching the Vector2 (i.e. storing the value, and then reading from it at a later point). Usually this would be fine for most cases, and in the old input system that worked just fine IIRC. But in the new input system this seems to desync what you want the result to be, so one way around this is to only read immediately when you’re using the input values.
Meaning: don’t use the cached vector.
My code was basically the same as yours (except for the Update() function), but if you instead of caching stickInput, you read directly from it when you need it, that will give you more responsiveness.
So in your code, if you’d do this (and make the appropriate changes to your Move() function) it should perform better:
//Movement
InputM controls;
private void Awake()
{
controls = new InputM();
}
private void FixedUpdate()
{
Move(controls.Player.Movement.ReadValue<Vector2>());
}
I have a somewhat similar setup, and I’ve connected it to a gamepad visualizer to actually see the inputs appear on-screen. Check the first GIF I’m uploading — just spinning the control stick counter-clockwise. It seems to consistently skip a bunch of frames, even when spinning the stick slowly. Then check the second GIF — I’m using the code I posted above, and you can clearly see the difference in frame consistency between them.
Cached vector:
Reading vector when needed:
################################################################
As for your “very drastic error”, here’s what’s going on in your code:
Inside your Update() function, you’re not reading anything into stickInput. You’re simply telling your script to listen to the input system’s events (“performed” and “canceled”), and perform your Move() function whenever that happens. What you’re doing, though, is telling your script to register this multiple times. So unless there’s a safeguard somewhere that prevents assigning the same function to an event several times, you’re actually assigning the Move() function to those events several times, meaning that the next time you perform any inputs, you’ll perform Move() multiple times. This will flux for every frame you play, and will inevitably overload your program. So don’t do that.
Instead, you should either cache the input inside the Update() / FixedUpdate() function, as opposed to from the input system like how you’re currently doing things. Or in this case like I explained earlier, you can read from it directly only when you need it for that extra responsiveness.
################################################################
Small addendum since you’re new to Unity:
Registering the functions to read the values is definitely the way to go when it comes to buttons and such, so doing the whole controls.Player.Movement.performed += ctx => stickInput = ctx.ReadValue<Vector2>(); wouldn’t be bad form in most cases. Except that you’d probably want to do this inside OnEnable(). And you have to also unregister these functions by swapping out the += with a -= operation inside OnDisable(). Otherwise you’re at risk of trying to run functions that no longer exist when your object is destroyed.