playMaker

Author Topic: Using Wait to run coroutines / loops  (Read 4216 times)

dasbin

  • Junior Playmaker
  • **
  • Posts: 92
Using Wait to run coroutines / loops
« on: June 08, 2012, 10:40:14 PM »
Is it advisable to use the Wait action to make coroutines in an FSM loop? In other words, if I want something to happen 3 or 4 times a second (rather than every frame) so that it frees up CPU cycles, is there any performance downside to using the Wait action in a loop? Is there any better way of doing coroutines in Playmaker?

To clarify, I've been using it and it works fine, I just want to make sure I'm getting all the performance I can out of it, because it's running on about a hundred GameObjects at the same time. I also offset the wait time by a random amount so that they're not all processing in the same frame.

jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 15500
  • Official Playmaker Support
Re: Using Wait to run coroutines / loops
« Reply #1 on: June 09, 2012, 01:48:32 AM »
Hi,

If you send an event with a delay, then you are fine, no performance hit or free cpu cycle to free.

Also, I am not sure it's actually necessary to implement randomness in your loop, since anyway gameObjects will be processed in turn, not all at the same time ( it's a loop, not a common call fired to all in one go).

but of course, it depends very much on your scene and what you are actually doing to them gameObjects during that loop.

Bye,

 Jean

dasbin

  • Junior Playmaker
  • **
  • Posts: 92
Re: Using Wait to run coroutines / loops
« Reply #2 on: June 09, 2012, 04:36:33 PM »
Hi Jean,

Is it better (performance) to use an event delay than the Wait action?

I've had some problems with using a delay on send event before, but that might have been fixed in newer versions, I haven't looked into it in a while.

jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 15500
  • Official Playmaker Support
Re: Using Wait to run coroutines / loops
« Reply #3 on: June 09, 2012, 10:36:24 PM »
Hi,

 I "think" it's the same. Now Alex will be able to better shade some light on which is more efficient, but I suspect they don't really make any difference for normal values ( read not 0.001 secs or something, which I am not sure how it behaves internall for these kind of values).

send event with the built delay never creates problem for me apart from when leaving the state, the event WILL be fired eventually, and that can have some impact on the Fsm process flow if used with global events and global transitions. I created a custom action to overcome this, but did not distributed it on this forum cause it's a bit hacky, and not sure if this was the kind of problem you had anyway.

bye,

 Jean