2 performance questions - timers and spawning

SquareHeart

Hi there,
I've been working on a 2 player iPad tank game, has been going well and has been challenging my GS knowledge a bit, but a few questions have arisen.

firstly -
Common knowledge says that too many timers are a performance hog -
with this in the back of my mind and needing better fidelity for the timing of things - I've been doing this:
creating an attribute called self.delta (not really a delta I know) that captures the self.time at the creation of the actor.
I then use a rule that is something like -
when self.time = self.delta+ then ..... do stuff

now.. is this better than using a timer for performance? or is this rule slower than using a timer?

secondly -
Spawning actors, each tank on screen has 15 bullets to fire - so theoretically that 30 bullets onscreen at once (less in reality, more like 15-20).
Will I get better performance by recycling these 30 bullets rather than spawning?
If I converted to recycled bullets I'd assume that because there were always 30 bullets in the scene at all times the frame rate would be more consistent - rather than spawning which seems to give frame drops and stutters depending on amount spawned.

thanks!

Clouds

I've got 148 timers in my current scene, that's 148 timers triggering all over the place (mostly 'after' and 'for' with change image commands inside) . . . it chugs along quite happily . . . . hold on let me do a quick test . . .

Clouds

getting around 60.74 fps and that's on a first generation iPad (ie: not the faster iPad2)

SquareHeart

really using the rule above was to get precise timing for destroying/hiding actors - I wanted to recycle an actor on the last frame of an animation. I had always felt timers were a little bit...er...weird sometimes (weird meaning imprecise)- so wanted to try something else and was wondering if this was better or worse than a timer.

Clouds

"I wanted to recycle an actor on the last frame of an animation"

I am also using the timers to trigger animations (PNG sequences) - as for precision it's hard to say, but I have been pretty brutal in testing, literally smashing my four control buttons on the iPad as fast as I could . . . and I have a camera controller that follows the actors with the timers on . . . and they refuse to fall out of sync with each other.

SquareHeart

hmm maybe things have changed in the newer GS versions but I'd found previously 0.1 being the lowest value the timer would handle successfully.

MotherHoose

@freerby … please remember that @Tynan lives on a higher-math plane … that soars above us all!

given that there are 3 types of built-in Timers in each GS game … gameTime, sceneTime, actorTime
each of these can be accessed and used to time the firing of Rules/Behaviors
using them will be much better for performance than adding timerBehaviors

one can always use an actorAttribute changes to trigger events … rather than a Timer
EX: and invisible off-screen actor that just interpolates X or Y …
Rule: when
Event:
self.Position.X = 0
--changeAttribute: game.??? To: game.??? +1

recycle is faster and more efficient …
except at the start of scene … as TSB pointed out … when an actor has a large number of rules
then you may want to load a dummySpawner
Rule: when
Attribute: self.Time ≥ 0.01
--Spawn that actor
--Destroy

@};- MH

The_Gamesalad_Guru

No people forget that the most recent processors have gotten faster. All this talk about limiting this and that really comes from working with the old armv6 stuff.

MotherHoose

ah @Fry … yes to that!

but, I am looking at retina display on iPad3 … and I want to save as many resources as I can for those big imageFiles!

@};- MH

SquareHeart

thanks so much for the feedback - I'd just stumbled on using offscreen actors to trigger events just the other day.... I'll dive into trying out recycling this weekend.