4.4.1
I have a very input dependant but 0 physics game. For performance, i tried to decrease Physics ticks per second to 30 and it caused less input updates (maybe placebo) , ios seems unchanged but android seems to be affected by it.
I don’t believe it is (I took a look in the docs and it does not say it isn’t, but it also didn’t say or imply anywhere that it was). However, it is dependent on the device issuing the input, ie your hardware.
Where exactly are you checking for inputs? Are you using the input manager? If you are checking, say, in your physics process then it might have an impact. You may find it better if you are to check inputs in _input or _unhandled_input, however the entire input process is still quite a complex process.
I realized this in _unhandled_input . I am doing lots of line2D and _draw operations. I always get_viewport.set input as handled t hough at the end
So the answer is no, to whether inputs are dependent on physics ticks.
However I believe _input is dealt with earlier than _unhandled_input, however I would find it difficult to believe this has any measurable impact on performance. These are events after all.
In fact I believe it is recommended to use _unhandled_input for gameplay, so UI interactions can handle them first in _input, so a UI button click is not interpreted as a ‘move my player here’ input for instance. At least that is my understanding.
I have read in a couple of places that v-sync can introduce input lag if performance is an issue. Have you got v-sync enabled? I don’t really understand why but there are several references to it around if you search for it.
Also if you have a low FPS, that can cause input lag of course as you would expect. My own game (which I am struggling to optimise - my fault not godots fault) is currently running on Android at about 30 fps and I don’t really notice any input lag. However when it drops to 15 FPS (as it will do at certain critical points) I certainly do notice it.
v-sync are enabled automatically in mobiles i think. I will check the rest. My game is very input based, not my fps but my feel for it seems off for android. Maybe it is an issue with my device, it is not new but not old either. I will check with other devices
Hmm, I had that with my mobile game, thinking it was my device. It wasn’t.
In the docs there is a VSYNC_MAILBOX mode where it talks about decreasing input lag.
Although not guaranteed, the images can be rendered as fast as possible, which may reduce input lag …
However I am a bit out of my depth here with all this. And I was surprised to see that VSYNCH can be enabled again if your device does not support it as disabled. I suppose this is a good thing but it does make me wonder about my device again!
Anyway, I hope you get your lag fixed.
And high end Android devices can go from 60hz to 120hz screen refresh rate (or more, or less) as the kernel schedules more cores at varying higher speeds!
The latter can affect all android devices and depending how the kernel is configured by the OEM (or you with ADB or rooted phone), you get widely different performance from the exact same phone.
Maybe try disabling Input.accumulated_input
i didn’t understand where i will set this. In project settings, couldn’t find it, in code shouldn’t it be global?
I had never seen that before (thank you @mrcdk ) but I imagine if it were global there might be a total flood of input events being fired. So it is node based and to disable it:
func _ready():
set_use_accumulated_input(false)
Although I don’t understand how one node can accumulate while others don’t. However Input is complicated and game engines are, or so it seems, extremely complicated. Quite honestly to a caveman like me they sometimes do look very much like magic!
@mrcdk 492 solutions! Wow. That is amazing!
It’s a global setting. You could set it inside an autoload for example.
Quote from document: Increasing the number of physics iterations per second can also reduce physics-induced input latency. This is especially noticeable when using physics interpolation (which improves smoothness but increases latency). To do so, set Physics > Common > Physics Ticks Per Second to a value higher than the default 60, or set Engine.physics_ticks_per_second at runtime in a script. Values that are a multiple of the monitor refresh rate (typically 60) work best when physics interpolation is disabled, as they will avoid jitter. This means values such as 120, 180 and 240 are good starting points. As a bonus, higher physics FPSes make tunneling and physics instability issues less likely to occur.
Is touch operation a physics-induced input?
I still believe the answer is no. In the jitter, stutter and input lag document you linked to it cearly states that:
Input lag is unrelated to jitter and stutter, but is sometimes discussed alongside.
I believe when it refers to this:
physics-induced input latency
it is referring to either that physics can induce input latency by heavy physics just slowing down the engine, or if you are collecting input in your physics process. This is a bit like saying hardware-induced input lag, or process-induced input lag, or network-induced input lag etc.
At least that is my reading of it. Will happily stand corrected if someone with the engines internal workings knowledge has a better insight.
I increased Physics ticks per second to 120 and everything felt better in android.
I also had a old code set_physics_process(false) and removed it.
To verify it is not placebo, i asked other two people. I dunno why it is like that but i will stick with it now. Input.set_use_accumulated_input(false) changed nothing. Thanks everyone.