No - the sampling of VR controllers is decoupled from ProcessInput.
Relying on this quirk of the engine is probably a lot more common than you would think. I can think of, off the top of my head, a number of FPS games I’ve worked on with code that assumes input is processed first thing in the frame loop (image that @colbert2677 linked)
Primarily my justification for relying on this order of processing was A) that image, and B) the fact that RunService:BindToRenderStep()
lists Input
as a distinct category with a low processing priority.
All this being said, I don’t know if this will cause any breaking changes or undefined behavior, or even off-by-one-frame errors in games I’ve worked on, but it’s also out of my hands to test it. A lot of previous projects I don’t have access to, or the time to look into as I’ve moved onto other projects professionally. So I wish it could have maybe been introduced as an opt-in workspace property similar to a number of changes in the past.
We still do process input first thing in the frame loop. The difference is that we process input again later in the frame. I hope the pattern that you describe is not disrupted by this change.
I’ve been getting reports of mouse locking issues for a couple of days now. When was this feature enabled? I’d like to check if the timeframe matches.
In response to your earlier question, while I’ve had several reports of potentially related issues, I have not been able to replicate this myself in an affected device.
This feature has been active on Mac for 8 days. It is not yet active on Windows.
This is cool, and we are all appreciative of Roblox for giving us the tools we need to keep up to date with the latest developments in gamedev, but is this the correct and future proof way to keep parity with Valve’s new CS2 tickless inputs? It feels like decoupling the input rate from the frame rate will cause more issues than it is worth, making it harder to onboard new developers and falling short of the high fidelity input times experienced developers want.
Especially given that most games get their processing done in several milliseconds, these two input events will be fired right next to each other, before waiting for the next frame to begin, or if FPS unlocked, waiting for the GPU to finish rendering.
Giving the os.clock time of input would give much higher fidelity, and give us more control over how to use the inputs we’re given, preferably through
-- mock up
UserInputService.InputBegan(function(inputObject, inputProcessed, inputTime)
Simulation:stepToTime(inputTime)
Simulation:giveInput(inputObject)
end)
What sort of improvement are you seeing internally? Does it feel nicer?
I agree on the value of timestamps. I believe this is being discussed.
The frame rate improvement is very noticeable on certain experience/device combinations. I don’t have overall stats yet though.
What events can I listen to to ensure I’m getting all user inputs, particularly if I’m looking to handle inputs across multiple input types easily?
If you are using UserInputService then the InputBegan, InputChanged, and InputEnded events cover the user inputs.
I expect this change to be activated for PC in the next 24 hours.
I know it doesn’t affect windows but, recently I have been experiencing serious input lag after the new update and I’m not alone, my other friends do too, it makes the game unplayable, please fix!
Is this lag on Windows? How long have you experienced this problem?
I can chime in and say that I am also experiencing very heavy input latency in most games now. Mouse movement, moving the camera (right click and drag), character movement, and interacting with UI is sluggish. This has been going on for a little over a week and is happening on games I’ve never experienced issues with before.
My desktop is on Windows 11 and my laptop is on Windows 10, and they both experience this issue. I’d be happy to provide more information if requested.
Thanks for the info. This update was delayed for PC so isn’t the problem here, but it’s good to know there may be another problem.
Yes, sometimes the character just moves by itself, it’s really weird.
As of recent, every game I go into I get these extraordinary brief frame freezes due to the heavy lifting of PreRender->ProcessInput->updateControllers in the Microprofiler. Since users posted similar posts above, I am posting this out of being concerned if this is related to this update? Please see below and let me know if you need me to follow up on this with a bug report or other.
This is 194 ms which is extremely bad, and it appears to happen only to my client, as my friends do not get this issue. I am on Windows 10. I will try uninstalling the client with a fresh install.
This update is not active on PC. I see you have created a bug report - we’ll take a look at that.
Any ETA when this will be enabled on PC?