Some dashboard animations for some input sources do not update smoothly

[MarkROR]

It's as if their update rate is very low, or it only updates once the value changes a certain amount (around 0.2) - it's a problem with scale, translate and when you represent the value as text. They also can get stuck and show the wrong value to the nearest 0.2.

Not a problem with integers, but for input sources that use floats (accelerator, brake, etc), it's just not usable.

Animations for rotate and lamp seem to work smoothly (rotate is still a bit choppy but fully acceptable)

Included is a video of the issue. All the bars use the accelerator input source.

input-sources-lag.mp4

Also included is a test vehicle, it'll show up as # GUI TEST - DEBUG DASH 2 in the vehicle selector.

0. GUI TEST - DEBUG DASH 2.zip

You will need some sort of analog input device to test - using throttle modifier keys does not provide any detail to show the issue.

[ohlidalp]

I whipped up a test script by modifying a demo of inputs.setEventSimulatedValue() script function. Unzip it into Documents\My Games\Rigs of Rods\scripts and use loadscript setEventSimulatedValue_accelTest.as in ingame console.

setEventSimulatedValue_accelTest.zip

The culprit are these intentionally inserted update skips: https://github.com/RigsOfRods/rigs-of-rods/blame/0.4.7.0/source/main/gui/DashBoardManager.cpp#L260 - I looked into history but they've been there from the beginning (11 years). Beats me why, but it's simple to change.

[MarkROR]

That is so cool, being able to do analog input with the script, works great, shows the issue

It makes me wonder if those update skips are there for a reason, perhaps updating too often resulted in a drop in performance?

Something doesn't seem right, though - if these skips have been present for 11 years, then how was the old dashboard (0.37-ish) able to move the "pedals" smoothly? (as opposed to the 4-5 steps we get) did it use a different input source, or?

[ohlidalp]

The old truck dash used OGRE overlays :)

[MarkROR]

Ah, right, yeah

Yeah, now I see that we perform these "has this value changed enough that it's worth updating what's on screen" checks for evey animation type, and I see that for rotate it's 0.02f, but for series, scale and translate and textformat it's 0.2f

I guess we could try, I don't know enough to be able to tell whether it'll have any negative performance impact though, I also don't know how to measure something like that reliably

[ohlidalp]

Poke me over weekend to do a draft PR with them removed or made tweakable via cvar. I'm curious and if the reason is performance, I will start looking for an alternative solution.