Godot: Input lag on android while dragging

Created on 20 Dec 2019  路  19Comments  路  Source: godotengine/godot

Godot version: 3.1.2

OS/device including version: Arch Linux for dev, Samsung Galaxy S8 for testing, Android 9

Issue description: I want to create casual games like board games or where you have to connect dots with lines and so on. When you drag a piece or draw a line using touch, this is usually very immediate, you can drag pieces around as fast as you want and there is no noticeable lag (at least on my phone).

With Godot, the best I could achieve with a minimal example looks like this: https://imgur.com/a/dMmsktx

I tried all of the following:

  • Using _input with InputEventScreenDrag where the event.position is used: https://github.com/kaiec/punkte/blob/input-only-minimal/scripts/game.gd
  • Using _input with InputEventScreenTouch, but this fires only once when the screen is touched, so not usable for dragging
  • Pulling in _process and _physics_process: Here I used the mouse emulation, as I could not figure out a way to get the current touch position natively. I tried binding drag or touch events to an action, but this did not work either, I could not use is_action_pressed to determine the touch state and get a position (maybe I am missing something here).

Steps to reproduce: One of the minimal examples is as follows:

extends Node2D
var icon = preload("res://assets/icon.png")

func _draw():
        draw_texture(icon, get_local_mouse_position()-Vector2(32,32))   

func _process(delta):
    update()

I also used draw_circle, but got the recommendation to try it with a texture, this all did not change the result.

Minimal reproduction project: https://github.com/kaiec/punkte/tree/input-only-pull

What I would expect to work best is pulling the current state of the touch screen plus the touch position(s), similar to how the mouse position and state of the buttons can be checked.

bug confirmed android porting

All 19 comments

I'll restate what I said on IRC for reference:

  • Latest iOS and Android versions make it possible to disable V-Sync. However, if I recall correctly, this is only advised for drawing applications, not games. I don't know how difficult it would be to implement as a project setting in Godot, but it'd help lower input lag significantly.

  • As a stop-gap solution, extrapolating touch input should help decrease perceived latency, at the cost of input being more jittery as a result. This could likely be achieved using a script, and could also be applied to other kinds of input (e.g. mouse input in a FPS).

I just wonder how other Android or iOS games do it, as there is no noticeable lag and that's neither extrapolated (at least I can't imagine that this is the case) and also not a very recent thing. As I also said on IRC, I would think that there is a straight-forward way to get the current touch position. I am glad if I can help, but unfortunately I have no low level Android experience and also only very limited C++ experience.

@kaiec Does it improve if you call Input.set_use_accumulated_input(false) in _ready()? This was enabled by default in 3.1 to solve issues with _input() being called too often (such as low performance when lots of code is being run in that function).

i have the same problem.
i have tried everything.. but lag on screen drag.while no frame drag other objects. but only screendrage.
while screen drag work smooth on pc

@Calinou: Just checked both with pulling using mouse emulation and with pushing using _input, unfortunately I could not see a difference. Test code in above links is updated.

hello... i am new to github..i dont know what is happening about issue.. pls tell me when this issue will be solved.... my android game is depend on this... this issue is only with android

@dahiyabunty1 We don't know when this will be solved, as nobody is currently working on it.

cc @m4gr3d, as he might have knowledge about this.

I鈥檓 trying to track down where the delay comes from and what it is exactly.

There is no lag between gotTouchEvent, queueEvent, GodotLib.touch and receiving the event in _input. Also I wasn't able to see a delay between received the first event and the last event and when I start the move and stop the move. Currently it looks like the lag or the wrong touch position comes from Android, I'm trying to debug more and look up how android does there pointer tracking.

Also I capture a better video of the issue with some debug logs:
https://i.imgur.com/ZyMXw3k.gifv

thnks NoFr1ends...
my game is depend on this...
player.global_position = get_global_mouse_position()

According to my further research, this is indeed not Godot specific. My guess is that this is the issue:

https://stackoverflow.com/questions/20981947/what-are-the-causes-of-input-touch-display-lag-in-android

Nevertheless it should be solvable.

Edit1: I wonder if this helps: https://developer.android.com/games/sdk/frame-pacing

Edit2: Ha, Unity had the same issue, probably solved this way: https://forum.unity.com/threads/whats-the-optimized-frame-pacing-feature.636847/

yes.... but i see most android game... player dont lag... they are very quick like stick with finger...so they have solution and much of them are unity games

I'm looking into Android Frame Pacing, but i think it won't get implemented before 4.0.

i beleiive you... i think so... one day godot will turn into best by improving and bug fixing

I am not so sure anymore, that the frame pacing does the trick. I updated both code branches so that according to my understanding, there should be only a redraw every tenth second, which seems to work. However, it still feels like the dot is lagging behind. And with this artificially reduced rendering rate, it should not have anything to do with frame stuffing. Very confusing...

@NoFr1ends Were you able to give a try at implementing Android Frame Pacing library since last December? The team behind the Android Frame Pacing library would be interested to support its integration into Godot, to help solve these input lags on Android.

Let me know if there is a way to help you or anybody that would have been trying this. :)

@4ian AFAIK, there hasn't been further development on this issue, so support would be appreciated.
That said, master currently doesn't build for Android, so the work may need to be started on the latest stable version (3.2) and then ported to 4.0 once it's farther along.

@4ian As @m4gr3d already stated the master isn't buildable on Android currently, also many changes to the Android version is planned because of the deprecation of GLES3 in favor of Vulkan. That's why I didn't continued with testing Android Frame Pacing library.

But after that is done I definitely appreciate help with implementing Android Frame Pacing.

Thanks both for your super fast answers! :)
We'll surely then wait for getting a stable Android build, after the planned changes are done - or give a try at 3.2 later.

@NoFr1ends Feel free to ping me if you take a new look at this later.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Spooner picture Spooner  路  3Comments

gonzo191 picture gonzo191  路  3Comments

nunodonato picture nunodonato  路  3Comments

kirilledelman picture kirilledelman  路  3Comments

mefihl picture mefihl  路  3Comments