Input delay / Sluggish mouse movement

[vega]

I've been trying to make a rather simple player controller in the last couple of hours.
It feels like there's a lot of input delay / it feels sluggish / jittery in general even though I have a couple thousands of FPS.
This issue also exists in the FPS shooter example.
I've tried multiple ways of getting the mouse input (Window::GetMouseAxis with different DPI values, Cursor position difference, etc.), but all of them seem to have the same issue.

I'm not even sure where the bug is in this case. Could be the input gathering itself, or the way it's rendered.
This is a rather big issue for me since I'm making a multiplayer FPS that needs to feel really responsive in order to be properly playable.

Am I doing something wrong or have I missed something?
I've attached the output of vulkanCapsViewer to make sure it's not my system being the issue.
Thanks in advance!

AMD Radeon RX 7900 XTX.json

[vega]

Also, since this happens in the default FPS example aswell, I figured you wouldn't need my project to check this out. But in case you do need it, just tell me

[vega]

I just managed to find the cause right after posting this. I figured the Update function would get called once every frame, but it appears to be once per physics tick. I need to get and process mouse events once per frame in order to make it feel responsive, but I cannot seem to find a way to do that.

[Josh]

The rendering loop and the update loop operate at different frequencies if VSync is disabled. You'll get the best results with VSync on. By default the update loop operates at 60 hz, regardless of what the framerate is doing. Motion is interpolated in the rendering thread to smooth it out.

There is an optional parameter in the world Update method that lets you specify a frequency, but it is not something that gets tested very often:

https://www.leadwerks.com/learn/World_Update

[vega]

And there is no way to run code on the render thread, like mouse movement?

[Josh]

No, it is running asynchronously and would interefere with the win32 code running in the main thread.

[Josh]

I have considered the idea of having a built-in mouse look option that runs in the rendering thread, for this purpose.

[vega]

I appreciate you taking the time to explain how this works. The performance benefits of keeping them separate definitely make sense from an architectural standpoint.

I'm wondering if there might be room for some flexibility here though, especially for latency-critical applications like what I'm building right now. The current interpolation system works well for most use cases, but for games where every millisecond of input latency matters, having some level of control over the interpolation or even experimental access to the render thread would be incredibly valuable.

Would you consider adding this as an advanced/experimental feature? Even if it came with warnings about potential issues or required careful implementation, it would really help those of us working on fast paced games. I'm really enjoying working with the engine overall, as it's super accessible and feels like a very modern version of the source engine which i really like, but this particular limitation is a significant challenge for the type of project I'm developing.

I'd be happy to help test any experimental implementations if that would be useful!

[Josh]

Well, what sort of latency do you worry about? Is it just the camera looking? I don't think keyboard movement is as critical, because there is alread some smoothing applied in acceleration / deceleration.

What sort of application are you creating?

Each thread has a secret API and set of classes for objects that are used in that thread. Entities do not exist in the rendering thread. Instead there is a RenderNode object, with its own set of methods. These APIs are undocumented and change frequently, so I am not that keen on trying to document them.

[vega]

The latency I worry about is mostly camera rotation with the mouse.
I'm creating a multiplayer first-person shooter akin to Counter-Strike: Source.

Since I want to implement server-authoritative movement, I need granular control over the interpolation and so on to guarantee accurate hit registration. I had chosen ultra engine for this, because I love the Hammer-like level editing and the extreme performance it offers.

[Josh]

The camera rotation issue could be solved with the approach I suggested. You're just the first person to ask about this. The rotation of VR headsets works in a sort of similar way.

[vega]

Quote

The camera rotation issue could be solved with the approach I suggested.

Yes, that would certainly work. I'm not entirely sure if this is the most comprehensive approach or more of a temporary "band-aid" solution, but you have much deeper expertise in this area than I do, so I trust your judgment on the best way forward.

 

Quote

You're just the first person to ask about this. The rotation of VR headsets works in a sort of similar way.

I'm actually very surprised by this.