Camera rotation speed affected by framerate using New Input System

I did one more test moving my mouse all along my mousepad's length and confirm the rotation amount is the same regardless of the framerate or the input system. The issue remains the same for the controller, it is as you can see in the video. I still haven't got the other controller back, I'll let you know when I'll have run a test with it.
 
Finally got my other controller, but forgot it was an xbox controller a well. The results were the same. I can only wait for someone to test with a controller on their end :/
 
By any chance do you have Rewired? Can you test with that? And just to confirm:

Cheo said:
I did one more test moving my mouse all along my mousepad's length and confirm the rotation amount is the same regardless of the framerate or the input system.
Click to expand...
So the mouse works correctly, but the controller doesn't?
 
No I don't have Rewired. And as odd as it sounds, I do maintain the mouse works correctly regardless of the framerate, while the controller is heavily affected by the framerate.
 
Cheo said:
Finally got my other controller, but forgot it was an xbox controller a well. The results were the same. I can only wait for someone to test with a controller on their end :/
Click to expand...
Hi Cheo sorry I have not had a chance to test yet, but in saying that, I have had some input issues with the helicopter controller, but I managed to fix it with some custom smoothing. This could of been fixed with a preset but would of been hard to get right on any and all machines. My isssue was getting too much input in comparison with the character in this case. But maybe just maybe you can find the function useful, dm me and I will give you the code to try, you can use the function dependent on the received input speed :)
 
After a new test, it seems the root of the issue lies in the look vector smoothing, and more specifically in the accumulation values. In the Update void from PlayerInput the horizontal and vertical input values are added to accumulation values, but if the input values are used as they are then the framerate issue may disappear. When using a manual vector like this :

C#: 
            manualLookVector.x = GetAxis(m_HorizontalLookInputName);
            manualLookVector.y = GetAxis(m_VerticalLookInputName);

The camera rotates simply with no smoothing but consistently regardless of the framerate, and AdjustForFramerate is not necessary.

When using raw vector or Unity smoothed and removing the plus symbols in update, the AdjustForFramerate bool does exactly what it is supposed to do.

C#: 
            m_RawLookVectorAccumulation.x = GetAxisRaw(m_HorizontalLookInputName);
            m_RawLookVectorAccumulation.y = GetAxisRaw(m_VerticalLookInputName);
            m_UnitySmoothLookVectorAccumulation.x = GetAxis(m_HorizontalLookInputName);
            m_UnitySmoothLookVectorAccumulation.y = GetAxis(m_VerticalLookInputName);

I haven't managed to use FastSkillTeam's code yet, but I'd first like to focus on trying to solve this issue. I'll resume the test tomorrow and try to get some results. And please, once again, it would really help if somebody could just take five minutes and try with a controller on their end, whether this issue happens on somebody else's side would be a huge piece of info !

Edit : Forgot to add, I'm still testing on UCC 2.4.8 and bought UCC 3 as soon as I could, but the framerate issue with the controller is still present in it as well.
 
This code is input agnostic so we really should be seeing the same results with a mouse vs controller. If you don't do the += on the accumulation then you will miss some input if the framerate is low. If I send you some code over PM can we work together to get a solution that works on your end?
 
I shared a build this morning and a guy told me had the same issue : no problem with the mouse, but both Xbox One and Playstation 4 controllers were heavily affected by framerate. This can't be just on my side, I know I'm repeating myself here but someone in your staff must have a controller to test this with ! I'm open to any suggestion or additional code you may have, but if this issue does prove to be from ucc then an actual fix has to be made, otherwise I fear your asset would be unrecommandable for any game based on or even allowing the use of controllers ! I should also add that I created 2 blank projects to test this issue, and a third one for UCC 3, so this framerate issue can't come from me messing with your code or anything like that.
 
I have been working with Santiago and have a change that works with controller input at different framerates. It ended up being a pretty significant change so will require new integrations. It will be in the next release (which will likely be soon as I want to get at least a few integrations out).
 
Great news, I'll be sure to test it as soon as it gets released ! But then does that mean you saw the framerate issue with a controller on your end as well ?
 

This is a quick test with the old input system, the sensitivity issue seems solved ! The camera gets jittery at 30 fps though, but that's another topic. Right now I have one last question to close this thread : after updating to 3.0.1 and importing the Input System integrations, the Controller X and Y bindings don't seem to be working. It's possible to move Atlas in the CharacterControllerSampleScene with a controller, but not to have the camera move around. I noticed the text binding <Gamepad>/rightStick/x doesn't match anything in the list (which is weird if it is meant to exist), am I the only one not able to move the camera in that demo scene with a controller right off the bat ?
 
Glad that worked! It was probably a mistake on the input mapping. I'll take a look.
 
Just updated UCC and the Player Input integration, aaaaand it's all good ! The camera can be moved at a constant speed with the new input system no matter the framerate. Thank you for fixing this issue !
 
You must log in or register to reply here.
Top