PlayMaker Help & Tips > Android Help

Touch input lag

<< < (2/3) > >>

Broken Stylus:
There are days when things decide to act in a wonky fashion, so much that you have doubts about procedures you took for granted, and you end wondering if you need U+ to have access to the Profiler (a reminder of the old days I guess) because all logic has flown through the window for 24 hours and the computer is just being a nuisance. :D
That wretched Profiler wouldn't start (regardless of how much I'd configure the settings and even go grab adb's data and so on) and then poof! it wen't on after launching the app like half a dozen times. Oh and the building process decided it was time to make my phone crash, just for the sake of it, by producing a flawed apk. Because otherwise things would be too easy, right? :/

So, I got my hands on several Android devices and the issue was found on all of them. Definitely, the final latency was clearly the result of the native latency being multiplied by some unknown factor when going through the Unity grinder.

Anyhow, now things work.
I made a few modifications. Most notably, I pushed all touch data into a normalized state, so I then had to multiply the fingers' x and y by the screen's resolution.
Now the latency is very tolerable, all is extremely responsive (touches and swipes) and the gizmos drawn by Unity almost stick in real time to the traces drawn by the Android system on the phone.
:)

I'd say, by all means, use normalized data when collecting info from your touch inputs, it seems to cut the latency for some odd reason.

I'm weary of saying the problem is solved but if I don't post anything else in the coming days then it will be safe to say it's not a problem anymore.

PS : djaydino, I hesitated using Easy Touch 5 but the documentation is terrible, the  add-on weighs more than 11 mb and my project is already getting too fat (and I have to add advertising SDKs), plus I don't need all the special controllers and couldn't be bothered to check what I could keep and remove form the assets.

Broken Stylus:
Another problem of separating major activities into separate FSMs (check the order I described in my first post) is that if they depend on each other to some degree, I don't know how to have them operate in order, within the same frame.

Having the gathering of inputs' information be managed in its own FSM could also explain that "Get touch info" actually happens too soon in the frame, meaning it's collecting the data from the former frame (n-1).
And to make matters worse, it's quite possible that the graphics (the gizmos that represent the fingers' respective positions, coded in Playmaker) may even display data from the frame n-2 (haven't found a way to force them in a late update).

All of these actions run with the "every frame" tag on. I wish I knew how to solve that issue without having to put ALL the actions back into not only one FSM, but actually one single, cramped state.

Otherwise, I would have to first test touch phases (began, ended, etc.) in one state, then move on to another state that gets the data, then again another state that does the gizmo update, and finish all that with a Next frame event action to make all of this loop. All of this without the "every frame" tag for any of the actions.
But I'm a bit afraid of missing some inputs this way.

However, this may reduce the latency on Unity's side even more, although I must say, some Android devices that look good actually have pretty crappy response times!

Why is the native input latency not a parameter taken into account for phone specs? It's very important and makes the use of a device more confortable when it responds quickly.

To get back to the topic, I noticed a "manual update" option in the PM Inspector's FSM tab.
It's said that one can even call this manual update through "PlayMakerFSM.Fsm.Update"

I suppose that this could allow me to order the execution of FSMs within a frame, right?

Looks a bit more advanced than the usual PlayMaker way of doing things. Is it possible or even wise to try to use that through an action, like "Invoke" or "Call static method" or something? What would be the proper syntax to use this function?

jeanfabre:
Hi,

 I think you are over complicating things. Instead let's do it another way.

 Can you explain what is the feature you are trying to achieve? and what is it that you are splitting across different fsm, yet with common data that need to be processed sequentially.

also, I think you are likely misunderstanding from where touch latency comes from, again, without profiling ( it's hard I give you that...), it's impossible to say what's responsible for this kind of behaviour.

manual update would not solve your issue.


Your issues are typical, so I think it's important to find the right solution for this. Once you will pick up how to do this, you'll be set.


Bye,

 Jean

Broken Stylus:
A request... OK.

If there is one thing I could need and that's why I was looking at a FSM's manual update, although I admit it's more of a curiosity, it is a way to force any kind of action into a Late Update.
However, actions not created with that feature don't provide that option so I'm wondering if there's a way around that.

This is why I went looking into the FSM's option and spotted the "manual update" thing. I thought ah ah! Maybe I could tell my "graphics" FSM to wait and get active at the end of the frame, just to be sure that the data it's going to use to place the gizmo(s) will be fresh and not one frame late.

As a reminder, typically, in my 3-FSMs structure, the third one is dedicated to graphics and it would be nice to force it to be dealt with at the end of a frame, because when putting "Get Touch Info" in every frame mode, in one FSM, and putting gizmo management (display + position) in another (every frame mode too), I simply cannot know which FSM is actually doing its code first.

When I first got into Playmaker I quickly figured that it would be a good thing to have FSMs run parallelal to each other when possible, some sort of coroutine simulation I guess.
But without knowing when each piece of visual scripting gets managed first, there are times when it is actually better to put all your eggs in the same basket... or FSM.
Sidenote: would there be a way to actually know that kind of things with the FSM Timeline? That said, the info would only be useful if the user could control the order in which FSMs run their codes during a frame.

This is why I fusioned my last two FSMs into one (data + graphics), following the logic described two posts earlier: 1. grab data, 2. do displayed stuff, 3. wait for next frame (using Next Frame event action).
This works very well.

I consider the problem I experienced largely solved, especially since there are incompressible things such as the device's native tactile latency which is just plain bad sometimes; and again, some crapfones gave me better results than quite expensive ones.

So yes, really, the one thing I'm curious about now is how to use the Manual Update thing, because to me it sounds like a way to decide when to run a FSM's code during a frame, but maybe I'm wrong?
What I read here (http://hutonggames.com/playmakerforum/index.php?topic=15182.0) looks very interesting. I went looking on Ecosystem but didn't find an action that can manage and control the update moment of another FSM.
Especially that interesting "FSM Update" action Alex Chouls talked about, perhaps one with the capacity to precisely aim for uGUI related Updates : the action would let one chose the type of update, that is, when the FSM will be read and its code executed. The drop down menu would include the list of all official Unity types of updates, including those dedicated to specific types of game objects or components.
Perhaps with a number (integer) for the order too, in case this is used for several FSMs ? This would be optional, because one way to "order" several FSMs' updates would simply be to duplicate the same action inside one state and be super strict by using the "action sequence" option.
Or the action could ask how many FSMs we want to manage (something similar to the action "Build string" that asks how many elements the action is going to glue together), with a "strict order" option?

Broken Stylus:
Also, on the topic of performance and manual updates:
https://forum.unity.com/threads/efficient-updating-take-control-of-update-functions.479509


--- Quote ---In this tutorial we will cover how to bypass the Unity Update() functions to be less resource-intensive and perform faster. Studies show that handling Updates yourself is 4X or more faster than letting Unity handle them.
--- End quote ---

Four times faster or more? Could this have an effect on the latency inside Unity's player?

Navigation

[0] Message Index

[#] Next page

[*] Previous page