PlayMaker Help & Tips > Android Help

Touch input lag

<< < (3/3)

jeanfabre:
Hi,

 I think you are overthinking this. I'd to be able to repro this before we go down some crazy setup, I never used the manual update. Let me play around with it and I'll get back to you on this.

Can you explain the feature you a retrying to do and I'll see if I can do this and provide the right easiest way to go about this.

have you experimented with running fsm as templates inside your state? then theay would be ran in order they are defined.

 Bye,

 Jean

Broken Stylus:
Hi,

Yes, I have experimented with running FSMs.
Unless I get it wrong, "Run FSM" is creating and destroying FSM "objects" on the fly, thus polluting the memory quicker and forcing more garbage collections if used repeatedly, right?

Pooling FSMs also seems redundant instead of simply creating my "display" FSM as a component on the gizmo.
At best, I'd be switching this FSM on and off with "Enable FSM" from another FSM (I already used that on/off methodology multiple times and it's okay).

The only problem with this action (and "Run FSM" too) is that it does not allow the user to tell when to run the code of the FSM by exploiting the inbuilt update phases of Unity.

Now, thinking of it, would it be possible to actually have an option in the FSM that simply forces the whole FSM to be ran during a specific update phase?

What I mean is that instead of, or next to "manual update", one could tick or select an option from a drop down menu to force the entire FSM and ALL of its contents to run at the selected time (update phase), using Unity player's native cycles.
Late Update, Fixed Update, etc.

That way, all actions would see their update time aligned to that of their parent FSM and allow the user to create very specific FSMs.
Now I don't know if that's doable, to force an action to run at "late update" for example when it's actually typed with voidUpdate...
 
At the moment, without using the very few actions that have the "late update" option, it's impossible (I think) to create a very late updatish FSM.

As said earlier, I can control when a FSM will be run, but it will run during the normal "update" phase nonetheless; unless it contains an action with a "late update" method or option selected but that's most like an exception and anyways, as I said, such actions are a rarity.

I don't think it's possible yet to create a whole FSM with "normal" actions and then sort of convert the entire FSM to have it run at "late update".
Like errr... some kind of mod, a "wrapper", see?
That would be neat for example if making a (large) FSM completely devoted to graphics.

Of course it removes the flexibility of the action described in a former post, because once this FSM is defined as to update outside of the normal update phase, it will be that way forever.
But is that flexibility needed?
Typically, when you create your FSM, you do know when you expect it to run anyways, you're not going to change its execution time on the fly to move it up or down the overall execution cycle, like from "update" to "late update", during your game. That would be silly.

So yes, I think setting the mode on the FSM itself would be a good thing.
Again, I create the FSM and then select "late update" and poof, it will be forced to run during said "late update" phase, regardless of the actions' complaints. >:)
It's magic!

jeanfabre:
Hi,

 Being able to define the order of execution of individual fsm would be cool indeed. but again, I am pretty sure you can get away without this in 99% of the cases, which is why I think it would be good that you explain exactly what you want to achieve so that I can bump into the same problem and find a solution.

 Bye,

 Jean

Broken Stylus:

--- Quote from: jeanfabre on May 11, 2018, 02:07:26 AM ---Hi,

 Being able to define the order of execution of individual fsm would be cool indeed. but again, I am pretty sure you can get away without this in 99% of the cases, which is why I think it would be good that you explain exactly what you want to achieve so that I can bump into the same problem and find a solution.

 Bye,

 Jean

--- End quote ---

Yes indeed, it's kinda very technical but I find myself easily turning into a frame rate nazi.  ;D

I may have noticed a slight difference in speed between using PlayMaker uGUI proxy components (onClick or others) and directly using Unity's "Trigger Event" component + PlayMakerFSM.SendEvent.
Both types of components were placed on the same object, a uGUI button, and then their events sent to the same FSM, each event triggering its own respective state.
I noticed that the FSM had time to be triggered by the events sent by Unity's "Trigger Event" component just before the events sent by the PlayMaker proxies would trigger their own respective states.
So Trigger Event seems faster.

Other than that, I consider the problem solved because what I suggested in the final moments of that thread could only be achieved through real coding today, and I've reached a point I'm okay with the performances I obtain.
The rest is up to Unity's own latency in receiving data from the smartphone and said device's own native latency.

The thread drifted towards a discussion about a general idea that came to me realizing what would be cool, i.e., pushing entire FSMs into specific update phases so I don't have to build extremely contrived systems where, for example, a FSM dedicated to graphics would have to wait for events sent by a whole lot of other FSMs telling it that they've finished doing their technical stuff and now visuals can be updated.

Navigation

[0] Message Index

[*] Previous page