How to defeat latency on touches?

Hi,

my ipad game runs a solid 60fps, however I can tell there is a fairly-visible delay in latency between touches. What I would like to know is what schemes do you use to get the quickest response-time for touches? It's a multi touch game.

There's two different methods I can find: GetTouch which does not allocate variables, and touches, which does allocate. Which of these is best for response times?

Do you have any code or tips for increasing response time of touches? My old (xcode / C++) iphone game didn't suffer these issues and I'm a bit confused how to speed up the response times in unity.

Thanks!

 

GetTouch is what you need to do if you want to query what's going on in the current frame, not the last one. I just use Rect.Contains or Raycast, whichever it needs to be. TouchPhase my be the source of your latency; I have found it unreliable in the past, and have manually tracked the status of all the fingers on the screen in a loop, using GetTouch, when necessary. I'm not sure if it has gotten better (or I have, and was doing stupid things before) recently.

 

Do you have USE_DISPLAY_LINK_IF_AVAILABLE turned on in your app controller? I found with one of my games that having this active caused severe input latency problems on older devices.

 

If you're doing any input processing before using a touch on a game object then update order could be effecting you. You could write an update manager or find the one available on the forums or the wiki to ensure that input processing gets done first so the rest of your game objects can see the result on the same frame.

 

...or, shortly, use Unity 3.4.

http://blogs.unity3d.com/2011/06/16/unity-roadmap-2011/

 

Hi guys, thank you for your input. I tried the following:

- disabled displaylink
- wrote an updatemanager
- using GetTouch

And it seems perfectly responsive BUT.... a big BUT.... it isn't responsive on the first press. It only seems responsive once I've grabbed it. I have several sliders and ui things. They are all updated just after the input stuff. They're just quads - not physics, so should update right away.

I also have it move a little light whenever I press a box to discern the lag for taps.

The problem now seems mostly the first touch takes a little while to register, but dragging seems up to date (within the margin of 60fps). I wonder what could be causing the delay for the first tap? It may be an optical illusion, but it is doubtful given that dragging things is fine.

The first tap+drag will cause it to jump to where I am then smoothly slide keeping up fine. So its stuff like that indicating the first tap is delayed, or lagged.

Tried it with a variety of code now on ipad. Need to dig deeper for this...

 

I'm not sure exactly what you're doing, but this sounds like you're not accounting for the lag in deltaPosition that is inherent to the device. I discovered it when working on a first person camera look script. When a touch is first moving around, the hardware doesn't know how to track it. Only after a certain delta has been obtained can you get smooth updating. I dealt with it by only moving the camera after a magnitude I set had been covered.

You can see Apple doing this, too. Just slide your finger horizontally on the home screen, very slowly. You won't start sliding to another page immediately, but after you cross a threshold, you can continue moving as slow as you want, with perfect response. I've got no idea how this stuff works under the hood. Regardless, nobody notices it. The delta is too small for anyone to care under "normal" circumstances. If your game needs tiny movements to register well, when a touch begins, you've basically got no choice, as far as I know, than to wait for technology to get better, to make said game.

 

@Jessy, the home screen is a UIScrollView which delays content touches purposely to detect touches on subviews. Raw touches to the EAGLView shouldn't display any lag at all. I use the standard touch phases for everything touch related and besides Unity missing a touchesEnded on occasion (it has gotten much better in 3.3) it works quite well.

 

If you have an package displaying a lack of jerkiness with a touch.deltaPosition, without waiting for a number of pixels to be covered beforehand, I'd love to see it! (I'll provide an example of the problem here if necessary.)

 

@Jessy, have a look at the UIToolkit library (here). The KitchenSink demo scene has a couple sliders and a knob that all respond to touches sliding around. I'm not sure if that's exactly what you mean but it can't hurt to give it a look.

 

That's a lot of stuff to dig through. Here's a very simple illustration of the problem. I wasn't quite right about it; dragging slowly does work okay, but dragging more quickly (I'd consider this a "normal" speed) will initially yield a jump in rotation, followed by smooth movement. Have a look and give me your thoughts on that, anybody, if you have time.

 

Tried procreate, an art package, because I figured it would be evident if anything, on it. Observations:

Initial press seems to have a 0.25 sec delay.
While drawing, there seems to be no delay.
Using slider bars on the side have the exact same behaviour as my app: that is, a small delay then a jump to catch up.

It could be Jessy is right here.

 

Useful info

 

sry for OT, but I saw in the press release that Unity 3.5 will support RNMs. Hooray! <3

 

RNMs really speed up touch response don't they

 

What was the point of that in this thread?

 

Hippocoder: Just to be clear, because I think I'm having the same problem you are, *every* touch down has a 0.25 delay between finger hitting the screen and Input.touches reporting it, correct?

Jessy: When you say "manually track" you mean you are simply caching touch ids when you find them in the touches array and using that information to figure out the phase of a particular touch, correct? Because even if I ignore the phase of a touch entirely and just try to play a sound whenever there are touches present, I still experience about a 0.25sec delay between touching the screen and hearing the sound.

 

To answer my own question:

I put a printf in the touchesBegan function in AppController.mm, there is no latency between touching and seeing that print. I put a print in my input handling script and it shows up right below the one from code with no noticable latency. As for me, since I was triggering audio based on a touch, it turns out I just had to change the Audio Latency in the Project Settings to Best Latency.

Also, this was all on an iPad.

 

Input.touches has a delay of time.deltaTime because it's from the last frame. I haven't found a use for Input.touches.

 

Well then how are you getting the touch information at all?

 

Input.GetTouch(x) for example, though that should have the delay too, shouldn't it Jessy? as anything coming from the outside has the 1 frame behind latency as unity does not process input midframe

 

I have noticed two things.


1. the initial touch IS NOT DELAYED

2. if you touch AND drag, there is a "pop" delay - movement doesn't start tracking till after this delay. I suspect it is because unity or xcode is set up to listen for taps first. And after a bit of movement, it is obvious there won't be a tap.

Is it possible to disable taps in xcode and check if this is the cause?

It's the drag which shows a delay, not the initial touch which doesn't actually have any delay.

 

you can unhook the touch detection in the AppController but then you won't get much anymore

 

Not sure what you mean.

 

The event handler that detects touches and forwards them into unity is present in the AppController.mm file in the xcode project. If you want to remove it you can do it there (> disable taps)

 

I looked at where unity gets that, but it still doesn't show anything to do with taps. What I am talking about is the xcode/ios messaging system.

 

What are you looking for in detail?
The only thing you have is the part there, the rest is inside the engine and outside your reach.

 

maybe this is usefull http://technology.blurst.com/iphone-multi-touch/

 

On iOS there is a way to speed up touch response that I found. That is to stop Unity touch at native side and replace with our own `UIGestureRecognizer`. After that all Unity touch would stop, but the custom recognizer should call a static method at managed side. I found that this way the response time is similar to logging directly in Xcode. Suggesting that there are many things out of our reach in Unity's touch handling code. Unfortunately we can't check them.

I made iOS Native Touch just for this purpose. You can check it out :
https://www.assetstore.unity3d.com/#!/content/107065
http://exceed7.com/ios-native-touch/

 

Apologies for the necro, I believe this thread is still relevant.

I am also running into the issue mentioned above where there's a freeze on every new touch until a certain delta has been covered. I also think this is due to the native side of things that tries to figure out if some gesture is happening before returning a value.

Honestly, if it's a native issue, I wouldn't even know where to start. I'm asking, hoping that it is not and that one of you has found a fix at some point over the years

 

Anyone fix this issue?