This is great information -- however, this is something that GS needs to look at; the built in timer functions should work. Has anyone reported this as a bug?
I have not as of yet reported this. It is definitely something that needs to be looked at inside of the main GS code, perhaps these basic optimizations can be made right at a code level and all timers could act like this, with the inclusion of "run to completion" type timers. I think the issue is that timers have existed in GS longer than the time attributes have, and the timer code is based on some old methods GS hasn't found the need to update.
As a sidenote, I can code in LUA quite proficiently, What do you have to do to get GS source access?
@uptimistik Aww! I know they are stripping out lua but that is pre-alpha and a ways out i'm sure. As a side note I can code in c++ and objective-c too. I'm sure issues like this will be rectified once GS is in objective-c, but who knows when that'll be ready. I know building anything in objective-c takes a lot of time and work, especially an entire engine. Until then all we can do is eagerly wait and hack ourselves out of the current FPS struggles.
@domenius You've been a big help! Especially as you explain it so clearly. I've been worried the amount of timers in my game would result in a wasted project but now there's hope!! I got to replacing all my timers straight away and saved the project so I can't provide anything helpful to show the performance improvements but I can say it was very evident just how inaccurate the GS timers are when viewing a simple back and forth movement on one of my actors.
Awesome! Over the last couple weeks building my game, I have been using many timers since each actor that spawns has a time limit. There are other timers also that speed things up. It's a progressive game that gets more difficult over time. Although it hurts my head to think about going through and re-working everything, I need to do it. With the more timers I add, and with each actor being animated, I have been noticing some delays and glitches.
I will apply these methods to timers and animations and see if it helps.
I'm going to use the every timer replacement stuff in my project, but just to check I understand.
mod1 being 0.5 means, GS has 0.5 seconds to do the action, and mod1 > self.time5 would mean every 5 seconds you have 0.5 seconds to complete the action?
And you can't use mod1 for multiple things, it must be a separate mod for each rule?
Actually that doesn't work for me either, I can have one rule using this fancy Every Timer workaround, but anymore in a single actor and my app seems to not start properly and the menu doesn't load in. This might just be because my app is too far along so I might have to save this awesome optimisation for something new.
I spent the last few days replacing all of my animates and timers. Big time improvement. On another note, removing my crazy gradient background also helped a lot. I guess keeping it simple is the key.
I'm going to use the every timer replacement stuff in my project, but just to check I understand.
mod1 being 0.5 means, GS has 0.5 seconds to do the action, and mod1 > self.time5 would mean every 5 seconds you have 0.5 seconds to complete the action?
And you can't use mod1 for multiple things, it must be a separate mod for each rule?
Actually that doesn't work for me either, I can have one rule using this fancy Every Timer workaround, but anymore in a single actor and my app seems to not start properly and the menu doesn't load in. This might just be because my app is too far along so I might have to save this awesome optimisation for something new.
No, mod1>self.time5 would fire once after 5 seconds
@MetzoPaino You can reuse a single mod for the entire project, I've done this many times with no issues. You are correct in saying that the length of the mod variable dictates the length of the loops execution. The 0.05 interval is presented because it is a good universal number for many calculations you can perform, you can always adjust this number to allow enough time for your particular use. If you use something with an interval of its own (interpolate, rotate to position, etc) you must allow enough time for these actions to perform, since they will be terminated prematurely after 0.05 seconds if using the concrete example above for the mod value. In some cases it is useful to have multiple mods in a single project to specify different intervals to allow actions to run fully. Experiment with the numbers and you'll find something that works for any application, then try and reuse your mods as much as possible to keep the variable count down. Even with individual mods at an actor level, the performance footprint is still smaller and more stable.
Thanks for the kind words everyone, I'm always happy to hear success stories! Who knows, maybe I should write a GameSalad book?
@laxking97 You would simply wrap two rules inside of each other, or add two conditions to your rule. A rule stating: if self.time [less than] 1 and if self.mod > self.time%0.05 [do actions]
that would run for 1 second from creation every 0.05 seconds. Your interval of 0.01 is too small to be accurately calculated, increase to at least 0.04 with a mod of 0.02 for best results.
To gain a "run to completion" type of behaviour (as long as the actor is not destroyed!), you can use a boolean to transmit the "state" of the every loop, then have a separate rule that runs the logic, then turns the boolean off. This sort of arrangement gives you good control over the execution of your rule as well as the speed enhancements of timer-less timers.
if self.mod>self.time%0.05 change attribute switch to true
if switch = true [do actions] change attribute switch to false
Make sense?
(on a sidenote, anyone know how to make the forum stop treating my psuedocode as html? Would be much appreciated!)
Thanks very much Domenius! I'd actually inadvertantly used self.time before, probably on the advice of some other genius on this forum, but didn't realise that it was so much better than the 'real' thing! Surprised there hasn't been a yellow post yet. Would be nice to hear the devs' thoughts on this?
Great post, thanks for that. I already knew how to do For and After substitutes but I've been looking for a nice flip-flop like your Every solution. I like your solution, clean and elegant. +1
gyroscopeI am here.Member, Sous Chef, PROPosts: 6,598
How did I miss this post?! Excellent stuff @domenius :-)
i need help, so i have this actor when touch after 5 seconds to destroy, with "run to competition" being checked, the actor is destroyed after 5 second with out keeping touching the actor, now if unchecked you know i have to press for 5 seconds to destroy this actor,
so now using your method, i have my rules like this when touch change "startime" to selftime when self time >startime+5 destroy this actors,
now the actor only gets destroyed if i press for 5 seconds, how i set like if run to completion were checked?
These types of timers do not create the "run to completion" type behavior. In your specific example, you could simply separate your events out. I'm guessing somewhere this code is wrapped in when touch is pressed or something to that nature. As soon as you let go, the code isn't run. Try this:
if touch is pressed change "pressed" to true change "starttime" to self.time
if pressed = true and if self.time>starttime+5 destroy
This is great - I'm going through my game right now and with every timer I remove I'm sure I can feel the performance getting that little bit better - thanks loads!
Comments
This is pretty awesome! I had no idea that timers in GameSalad were so defective. I'm switching all of my timers right now!
Thanks! ^:)^
Jack McGraw
Just a quick question... The self.Time attribute works in the GS test simulator, correct?
Thanks,
Jack McGraw
Yep, all those attribs definately work in the creator and viewer as well
As a sidenote, I can code in LUA quite proficiently, What do you have to do to get GS source access?
You've saved my bacon.
I will apply these methods to timers and animations and see if it helps.
Thanks Domenius!
Thank you domenius!
Shadows Peak is an atmospheric psychological horror that explores the dark side of a player.
mod1 being 0.5 means, GS has 0.5 seconds to do the action, and mod1 > self.time5 would mean every 5 seconds you have 0.5 seconds to complete the action?
And you can't use mod1 for multiple things, it must be a separate mod for each rule?
Actually that doesn't work for me either, I can have one rule using this fancy Every Timer workaround, but anymore in a single actor and my app seems to not start properly and the menu doesn't load in. This might just be because my app is too far along so I might have to save this awesome optimisation for something new.
Thanks again!
This should be sticky for sure!
You want mod1>self.time%5
if game.blahblahblah is true
for 1 second (run to completion)
every .01 seconds
change blahblah to blah
how would I do this?
@laxking97
You would simply wrap two rules inside of each other, or add two conditions to your rule. A rule stating:
if self.time [less than] 1 and
if self.mod > self.time%0.05
[do actions]
that would run for 1 second from creation every 0.05 seconds. Your interval of 0.01 is too small to be accurately calculated, increase to at least 0.04 with a mod of 0.02 for best results.
To gain a "run to completion" type of behaviour (as long as the actor is not destroyed!), you can use a boolean to transmit the "state" of the every loop, then have a separate rule that runs the logic, then turns the boolean off. This sort of arrangement gives you good control over the execution of your rule as well as the speed enhancements of timer-less timers.
if self.mod>self.time%0.05
change attribute switch to true
if switch = true
[do actions]
change attribute switch to false
Make sense?
(on a sidenote, anyone know how to make the forum stop treating my psuedocode as html? Would be much appreciated!)
Surprised there hasn't been a yellow post yet. Would be nice to hear the devs' thoughts on this?
How did I miss this post?! Excellent stuff @domenius :-)
""You are in a maze of twisty passages, all alike." - Zork temp domain http://spidergriffin.wix.com/alphaghostapps
so now using your method, i have my rules like this
when touch
change "startime" to selftime
when self time >startime+5
destroy this actors,
now the actor only gets destroyed if i press for 5 seconds, how i set like if run to completion were checked?
if touch is pressed
change "pressed" to true
change "starttime" to self.time
if pressed = true and
if self.time>starttime+5
destroy