Search Unity

  1. Unity 6 Preview is now available. To find out what's new, have a look at our Unity 6 Preview blog post.
    Dismiss Notice
  2. Unity is excited to announce that we will be collaborating with TheXPlace for a summer game jam from June 13 - June 19. Learn more.
    Dismiss Notice

I think slow Android Touch Input ...

Discussion in 'Editor & General Support' started by mungtion, Apr 14, 2016.

  1. mungtion

    mungtion

    Joined:
    Apr 18, 2015
    Posts:
    13
    Hi ~

    i tried 'touch & fast drag' test in android device.

    I have a problem about touch input sensitivity.

    i made simple script, just getting touch position in Monobehaviour update function.

    And apply to position of some image.

    like next picture.

    joystick.jpg

    if quickly moved follow red line after touch screen. i could see image slowly follow 'touch position'.
    it like spring.

    joy2.jpg

    i moved too fast 'blue start position' to 'red stop position' follow drag line.
    when i stoped at 'red stop position', i could see keep moving white image to 'red stop position'.

    Is it just Android IO speed problem ? Or Problem of unity ?

    Sensitivity is very important thing for me.


    who know anybody ?

    thank you.



    P.S
    -- Sadly i not good at english .... i hope you understand what i saying. :)
    bye~
     
    Last edited: Apr 15, 2016
  2. artplayer

    artplayer

    Joined:
    Apr 16, 2016
    Posts:
    18
    Hello, I know the post is old but I'm exactly with the same problem. If you were able to solve, can you share the solution?

    Thanks
     
  3. 5argon

    5argon

    Joined:
    Jun 10, 2013
    Posts:
    1,556
    This problem is the drawback touch interpretation of Unity's polling-based Input API. In native Android, we receive touches via callbacks (may happen much more often than 60FPS frame rate) but in Unity, we ask the touch to use in-frame by
    Input.GetTouches


    What is in the
    Input.GetTouches
    right now is an interpretation of all native callbacks that happened before this frame. And so what you get from Unity is not necessary a present data. (Usually 1 frame late from the actual callback)

    Moreover, some data are lost because callbacks can be more than once per finger per frame. But Unity has to present exactly 1 data per frame (per finger). Some processing is required to conform with data polling based API. And it is different on iOS and Android.

    Look at this log comparing native callbacks with what you can check from Unity's API every frame. 9 callbacks became 3 data and the other 6 are lost with no relationship to what you get from Unity. (The circled with arrow ones became exactly what you get from Unity, with delta delta-ed to the previous ones skipping the rest, which I marked X)

    androidvs2.png

    Of course, you still can only update you white box in-frame. But with native callbacks you would have more data Unity discarded to work on. (You can do your own bezier interpolation from them, etc.)

    (If you would like to receive native callbacks then you might be interested in Native Touch )

    (Also if you just want to know how Unity interpret native callbacks into
    Input
    API on both iOS and Android you can read my own deduction here : http://exceed7.com/native-touch/callback-details.html)