Timer vs Loop
NNterprises
Member, PRO Posts: 387
Sorry for my lack of programming knowledge, but can you explain to me what the difference between using a "loop-while per frame" and a "timer-every x sec"?
Is loop just using frames as the unit while timer uses seconds? Is one better than the other?
Thanks!
Comments
the frames allows you to set how many times the loop can run per frame.
The loop will stay on as long as the condition is valid , then it will stop
Timer will keep going without conditions unless you wrap it inside a rule with a condition
Yea that's what I have, All (every .05 sec) timers with rules right now so it's doing the same thing.
But I didn't know if my performance would go up at all if I changed it all to Loops instead.
You performance probably would go up if you shifted to loops, but it'll depend on exactly what you're using where and how.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
Ok that's what I was wondering. I'm using the timer currently to spawn enemies throughout the entire game.
For example,
Every 0.1 seconds (timer)
If there aren't any enemies near you and you are not dead
Spawn enemy
And I've been stacking new actors and images and it seems to be getting a bit slower as I put more things in, so loops might help...
This timer will run throughout your game regardless of whether there are any enemies near you or not or whether you are dead or not.
If you change the positions of the conditions the timer will only run when needed, like this:
If you are not dead
--If there aren't any enemies near you
----Every 0.1 seconds
------Spawn enemy
The fastest a timer will run (0.0 seconds) is 30fps/once every two code cycles, a loop can run at 60fps/once every code cycle.
Funny enough I was asking Armelline about a similar thing just yesterday, comparing Loops to Constrain (both which fire once every code cycle / 60fps).
@Socks Hmm ok very good to know. So loop is definitely faster. Thanks for all the background with it, I think loop would be better for my application. Hopefully makes it less glitchy. I'll compare it with your other timer suggestion
@Socks @Icebox @Armelline
Sorry, another thing. When using the loops do you NEED a while constrain?
If I want this loop to run forever and always can I just have the attribute/constraint part blank and fill out the DO part?
Kind of like how I have the Timer always running above, or like the constrain attribute too I guess.
((((
Example for this one - Random Enemy Spawning:
Every 0.1 Second
Change style, size, and type to a different random number
Could I just do
Loop x per frames
Change style, size, and type to a different random number
and would this be more efficient you think?
))))
Oh well I guess I could do:
Constrain style to random
Constrain size to random
and constrain type to random
and I would get the same result as an unconstrained loop...
If it's something you want to run forever, and you're spawning at a set frequency (i.e. 0.1s), then timers are better for your purpose. If you wanted to spawn 1000 enemies as fast as possible, then you'd be better with a loop. What you've said so far makes me think you're probably best off with the timers, with some changes @Socks has suggested.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
I'm curious about this, is there a performance advantage to using either or, or is it just loops are more flexible and that's it?
Follow us: Twitter - Website
Thanks @Armelline it clears it up for me
I doubt there is a performance advantage to using either, my suspicion is that often these similar functions are a kind of reformatting of each other to add flexibility (or to extend possible applications).
For example the following two rules should be functionally equivalent . . . .
Rule: while x position < 1,000
--Constrain self.pos.x to self.pos.x +1
Loop: while x position < 1,000
--Change self.pos.x to self.pos.x +1
. . . both move an actor left to right across a scene at 60ppi.
Of course testing which is more efficient (if there are any differences) is straightforward enough as it's not difficult to overwhelm something like an iPhone or iPad, just generate a project that has an actor that contains both options, and spawns a few hundred instances all executing the behaviour at once, and switch between them (upping the spawn count as needed) to see which is first to drag the frame rate below 60fps).
I doubt there is a performance advantage to using either, my suspicion is that often these similar functions are a kind of reformatting of each other to add flexibility (or to extend possible applications).
For example the following two rules should be functionally equivalent . . . .
Rule: while x position < 1,000
--Constrain self.pos.x to self.pos.x +1
Loop: while x position < 1,000
--Change self.pos.x to self.pos.x +1
. . . both move an actor left to right across a scene at 60ppi. In that respect Loop is a Constrain behaviour with a different (more flexible/useful) interface.
Of course testing which is more efficient (if there are any differences) is straightforward enough as it's not difficult to overwhelm something like an iPhone or iPad, just generate a project that has an actor that contains both options, and spawns a few hundred instances all executing the behaviour at once, and switch between them (upping the spawn count as needed) to see which is first to drag the frame rate below 60fps).
We have to look at this from a LUA code perspective. Remeber all behaviors in creator are ultimately they are all converted to LUA code. So code wise a loop is the proper code method one would use doing straight hand coding. I would use a loop instead of a rule and a timer. The loop does now allow you to jump the cycle so that can be very handy for the restrictions of layer order in creator.
Guru Video Channel | Lost Oasis Games | FRYING BACON STUDIOS
When it comes to a constrain vs a loop, it's more of a usage difference than a performance one. Loops have many uses that constrains do not.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
@AlchimiaStudios
Before everyone elaborated answering my question, I was playing around comparing all of my options, and I noticed when I used more constrains and (unrestrained) loops, I had more glitches and lower performance than using timers.
Based off of the info above, I think that it probably ran slower with the constraints and unrestrained loops because they are ALWAYS running, and they are sampling at a much faster rate (at least double the speed of the fastest timer). Therefore that means double the processing is going on in the background, slowing the performance.
So yes ensure the usage is necessary for it, otherwise you may see performance degradation
I wouldn't say this was the case, whether you are running a timer, a constrain or a loop, there is no distinction between them when it comes to whether they are always running or not . . . if you can limit the running of a timer, you can limit the running of a loop or a constrain using the same method.
For example all these (timer/constrain/loop) will count up to 1,000 and stop . . . .
Rule: When count < 1000
--Timer: Every 0 seconds
---Change count to count +1
Rule: When count < 1000
--Constrain count to count +1
Loop: When count < 1000
--Change count to count +1
I suspect this is not the case either, I think when the animate behaviour is encountered GS still needs to calculate the current frame, even if the current frame doesn't change it's still part of the 60fps code cycle.
@Socks
Yea you probably know more than me, so just ignore all that I said up there lol.
But just as reference my unrelated to the game analysis and testing above was all without using ANY limiting of running the timer.
So just know that when I tested a 0.0 sec timer vs constraint attribute (always running) vs Loop while (no conditions), the timer had the least problems and best performance.
I suppose each project will have its own idiosyncrasies depending on how it's set up, so whereas a time might be ideal for one situation a loop might be the right choice for another.
I just spent half a day resolving a small issue, in the end the solution was to mix constrains and a loop in an actor, all constrains caused one issue, all loops caused a separate issue, after lots and lots of testing the solution was for two constrains to control a value that swings between -5 and 5 and a loop to return the value to 0 when it's not in use ! So . . . good that we've got a range of tools for these issues.