Input.GetTouch(0).position LAG x 2

Unity Engine
,
1

(SEE ATTACHED PHOTO)

I’ve had a gut feeling (along with others on this forum) that Unity Touch Input (Android and iOS) is around twice as unresponsive as natively programmed apps when dragging or swiping, and for games especially, this is a serious issue. User responsiveness should be the core upon which audio fidelity and graphical glitz is built, not a hobbled afterthought.

I recently noticed my Android Tab3 Tablet had a setting for ‘Show Touches’.

Settings->Developer Options->ShowTouches

I managed to get an actual photo mid swipe which clearly shows that Unity Input exhibits lag TWICE that of the OS / other apps. The OS generated dot assumedly shows lag due to hardware issues. A cube in Unity shows itself WAY behind the OS dot, exactly twice the lag.

It is as if our C# scripts are being fed stale (or interpolated?) data rather than poling the device for fresh raw input, even when using Input.GetTouch(0).position rather then Input.touches[0].position.

My questions are…

Is there a way round this within Unity without complicating matters with Android native code or plugins? (I use Unity precisely to avoid custom Android / iOS code!)

If not, is there a solid, unavoidable technical reason why Unity developers are handicapped in this way?

If direct polling is possible, but just not implemented, surely this a serious bug or feature request issue do you think?

Thanks Experts!

1906911--122986--AndroidLag_001.jpg
1906911--122986--AndroidLag_001.jpg2354×1410 103 KB

2

I’ve just completed a detailed study into why Unity 4.x on iOS can sometimes suffer severe touch input sampling issues. I know your situation is for Android (and this is the Android platform forum) but it may be of interest to you.

Back on Unity 3.5.7 the input sampling on iOS was great. Unfortunately we can’t advance our game to Unity 4.x due to the problems I describe in my blog post. The post goes into (much!) more detail, but on iOS, Unity can definitely be fed stale data.

I don’t know whether the Unity Android add-on uses the same technique as the iOS add-on but I would wager they’re similar.

Be warned the post is very long but if you can make it through it should give you an understanding of why we experience the problem on iOS. It would be really interesting to see if you’re experiencing a similar situation on Android … it would certainly add more weight to our attempt to get this bug fixed.

http://www.yaku.to/blog/2015/01/08/Unity-iOS-Touch-Input-Is-Broken-But-They-Say-Its-To-Be-Expected/

3

Hi cgJames,

I’m actually making apps for iOS too, so your reply is very welcome!

I took a good long look at your impressive blog, and I’m C# Unity based only so the details went way over my head, but it made a fascinating read. I’d hope at the very least Unity would struggle to argue with your logic and results.

My own general issue of lag whilst dragging appears equally bad to me on Android and iOS, and doesn’t seem to kick in at a particular point, it seems consistently bad right from app launch. Games like Fruit Ninja seem to have superb drag response with almost zero lag, and I find it very frustrating that any game relying on fast reactions when dragging are pretty much ruled out on Unity! Interestingly Construction Simulator 14 (another Unity game) has terrible lag on the joysticks too, as they rely on stale dragging position data.

Android 4.4.2 has a developer option to showTouches, but iOS seems to lack this feature. I found it very useful for showing the Android lag as seen in the photo. I’m C# Unity based only, but does this link give a clue to show touches on iOS8?..

Might it help debug your touch issues with visual feedback?

Does altering the Edit-ProjectSettings-Quality Vsync settings in the editor help / alter your thread wait issue I wonder?

I’ve read posts about forcing Application.targetFrameRate to 60 helps with lag, but it does not! It merely partially masks the lag, BUT the Unity cube still drags twice as far behind the finger!

Basically I want Unity to place the cube on Update call exactly where the OS dots appear (on Android). The OS dots are drawn over (after?) the Unity graphics, so surely this should be possible right?

Whether the lag would show up the same on iOS devices I have no way to tell, but the lag seems as bad across both plugins. I’m still running tests for my simple touch app, and will let you know if I find anything that helps, but I’m assuming this needs fixing at a Unity Editor / iOS / Android Plugin level, and has remained unaddressed for years.

Thanks for your help so far :slight_smile:

Richard

4

Hi @GallopingGmaes (Richard)

Don’t lose heart just yet - I’m sure you’ll be able to get your touch responding. There’s a few things to consider.

I know you’re having problems right now but fast reaction time games are definitely possible with Unity. Our game requires the player to keep their finger in constant contact with the screen and relies on very fast reaction time … and it’s built with Unity (3.5.7). That’s why we’re so screwed by the problems I documented in my blog post.

The first thing to consider is (and it may sound patronising!) are you certain your touches are aligning with the pivot of the cube you’re moving? Working at different resolutions and aspect ratios can prove tricky to ensure touch coordinates convert to the correct world coordinates. When you stop dragging your finger and leave it touching the screen, does your cube catch up to its intended position? If it doesn’t then that could be part/all of your problem. If it does rest in the correct position and you’re updating your cube’s position each frame then the problem likely lies with Unity/Android.

The Unity docs for Android reference the UnityPlayerNativeActivity and this may be of interest to you (sorry no page anchor so scrolling required):

This sounds promising and would be worth an investigation.

If the problem I outlined in my blog post occurs on Android too then it could certainly affect your input processing. I don’t know how the Android add-on syncs with the display so maybe not, but the Unity guys are starting to look at the problem so hopefully we’ll find out soon.

The link you sent looks useful for recording touches in screen demos but I would advise against it for diagnosing issues in Unity because, from experience, adding UI elements over the EAGLView (which is what it appears to do) can have some nasty consequences. I’ve personally missed occasional touch events in the past - if it’s touch you’re debugging then that can lead to false conclusions. Also, I found that using a UILabel for my debugging of the iOS touch issue affected the results I saw.

The OS dots are drawn above the content, but being an OS feature I suspect they aren’t subject to the event propagation required for the messages to reach Unity. For example, on iOS the touch events are sent to the Unity thread so that their handler can be called by the run loop when it’s next free. But because Unity can be blocking the thread and be interfering with input sampling it can take longer for them to be processed - and that introduces lag. That’s the problem we face on iOS but should definitely be fixable by Unity.

I hope some of this helps!

James

5

Hi cgJames,

Thanks for the reply. I’m sure the problem is not pivot related as the tracking for the cube centre point is spot on to the finger (and OS dot), just woefully delayed on fast swiping. (The photo shows a very fast swipe and took several tries to capture the lag clearly.

I do have a particularly old iPad, so will test more when an iPad Air 2 arrives. My Android Tab3 (used for the photo) is pretty recent, but still exhibits the same double lag issue. I really hope Unity fix your issue soon as the iPhone 5s is the most used apple device according to the Unity usage stat graphs, so is very worrying that they haven’t fixed the ‘jitterbug’ yet.

The iOS 64Bit build rule changeover is a scary deadline, I hope they get Unity stable for 64bit iOS in time just in general. 32bit to 64bit swap over seems a recipe for yet more bugs all the way up the OS / xCode / Middleware chain. I wonder if that had anything to do with iOS 8 being so bug ridden?

Thanks for taking the time to help, I’ll carry on testing and report back if I get anywhere. :slight_smile:

Richard