How should I use every tick (performance)

Hi, ppl. I've got a noobie question about perfomance.

What is the difference (on performance) of using (1 event or 3 events):

Every tick{

rotate.sprite

scale.sprite

move.sprite}

and:

Every tick{

rotate.sprite

}

Every tick{

scale.sprite

}

Every tick{

move.sprite

}

Creating more events will slow down the app or do they all "catch the same train"?

I've got some trouble on organizing the groups and now and then I think "hmmm, the code needs another every tick", then I remember that I've got one everytick event running up there and so I search for it and add to it). Is that something I really should worry about?

Thanks in advance

I think c2/JS=Single-threaded

Every tick=laggggg

fongka2 - that's not true (about the lag - c2 is mostly single threaded though). There's an idea that's getting traction that every tick is performance intensive. It's not. At all. What other actions and conditions you do every tick can be performance intensive, but using every tick, by itself, is utterly negligible. Stuff like moving, rotating or scaling sprites are just fine to do each tick.

Technically though, scofano, as I understand it the first is best, but by such a small amount I doubt you could tell the difference even doing it a bunch of times over a project.

Technically though, scofano, as I understand it the first is best, but by such a small amount I doubt you could tell the difference even doing it a bunch of times over a project.

Thanks, Arima.

Everything that I test on browser (pc) runs fine. My problem is when I test it on my Ipad(new).

So I've started to read forums and ppl always blame the everytick (among other things, like number of objects) for performance.

What I think I should do (please tell me if I'm wrong):

I'm coding a top down shooter and there are 4 types of guns. So I coded every gun on their own group (inside each group there is an everytick for each gun) and I activate and de-activate the groups depending on the powerup(gun) I get.

I will be using 1 'everytick' call (go rotate, for example) instead of using them all in a single 'everytick' that is doing things on gun2, 3, and 4 (sprites) but only gun1 is on the scene. Waste of time putting them all on a single event if they are not on the scene, right? (or, is it ignored for the sprite not to be seen?)

Thanks

Groups that are not active will be ignored at runtime. Using a single "every tick" condition to check the active type of gun with 3 elseif conditions wouldn't make a significant difference.

On mobile, it's mainly collision/overlap checks, loops and physics that will quickly eat up your CPU power. Creating and destroying many objects as well, like bullets for example. If you haven't done so by the way, you will need to pool any type of object that's being created and destroyed often (that is to say create them only once, store them in an array for example and reuse them).

Good luck!

Groups that are not active will be ignored at runtime. Using a single "every tick" condition to check the active type of gun with 3 elseif conditions wouldn't make a significant difference.

Like I thought: deactivated group = 0 processing. That's nice to know.

On mobile, it's mainly collision/overlap checks, loops and physics that will quickly eat up your CPU power. Creating and destroying many objects as well, like bullets for example. If you haven't done so by the way, you will need to pool any type of object that's being created and destroyed often (that is to say create them only once, store them in an array for example and reuse them).

Good luck!

In a case of a shooter, are you saying that it is best for me to create, let's say 30 bullets (20 of main ship and 10 for the enemies) and just move them around (on and off the screen) instead of spawning and destroying them?

Yes, or toggle them visible/invisible. At least, if you're getting trouble because of your CPU usage. Creating and freeing objects into memory gives a lot of work to your garbage collector. Anyway, you're already setting the position of your active bullets all of the time in your code, aren't you? So by pooling your objects, you'll technically simply remove all of the object creation and destruction calls during gameplay sessions.

Good luck going forward, and don't hesitate to tell me if you need anything!

Yes, or toggle them visible/invisible. At least, if you're getting trouble because of your CPU usage. Creating and freeing objects into memory gives a lot of work to your garbage collector. Anyway, you're already setting the position of your active bullets all of the time in your code, aren't you? So by pooling your objects, you'll technically simply remove all of the object creation and destruction calls during gameplay sessions.

Good luck going forward, and don't hesitate to tell me if you need anything!

Great and inspiring works of yours, Nathan. Thanks for the response. I'm listening to your tunes, righ now.

I've doodled what I understood you told me about the bullets. Is that correct?

So I've got to define how many bullets I can have on my screen (by speed) and create them all at once on start of layout? Then, everytime it goes off the screen or get hit I move it back to the ship?

That's exactly it. You can just spawn like 25-30 bullets if you know for sure that you won't need more than that, or use a safe margin. Whenever the player fires a bullet, you then just have to go fetch any inactive bullet and fire it.

You don't need to take in account the precise number of bullets that your game need at a given time in the overall game progression: if this number grows as the player plays, the target device will still have to handle this object count. In other words, you can set a max number by hand.

Valerian - Actually, C2 already automatically recycles instances so you don't have to to do any of that manually or worry about garbage collection. From https://www.scirra.com/blog/52/construc ... javascript :

[quote:1k879041]Further, Javascript is a garbage-collected language. That means creating objects allocates memory, but the programmer doesn't say when it's released. Instead, the browser occasionally decides to search for the bits of memory which are no longer being used, and free them. That's called 'garbage collection'. Unfortunately garbage collection can take a lot of CPU time, and even cause your game to become noticeably jumpy, or even regularly freeze up momentarily! That's very annoying for action packed games. There are ways to work around this, but it can be difficult to factor this in to your own code. But don't worry! We've already optimised Construct 2's engine to create very little garbage. Even destroying and later creating a whole object doesn't leave the old object as garbage - it's recycled. So your games should very rarely have garbage collection pauses.

Thanks — I was coming back to the thread after reading an entry from the SDK manual, just learned that. That's pretty huge.

Sorry for those misconceptions about C2, this boils down to some prior experience with CJS which had big garbage collector issues, at least a couple of months ago.

Scofano, it seems like you won't need to bother with pooling !

Thanks, both of you.

What is the (performance) difference between:

everytick -> do something

• and -

if global variable = 1 -> do something

Would both of them use "everytick" speed?

Most of the performance questions in this thread are meaningless. Read the blog post Optimisation: don't waste your time

What is the (performance) difference between:

everytick -> do something

- and -

if global variable = 1 -> do something

Would both of them use "everytick" speed?

All of the event sheet (except triggers) conditions are checked every tick, you should not worry about every tick, just make sure you don't do useless actions or conditions (if you want something to happen, does it have to happen every tick, or only on particular cases? When you are checking for a condition, is it really nessecary, or can you filter down even more if that is intensive), there is no magic, no wizardry, just see what you event sheet does, and when it does it, if there are redundancy or things that should not be done in some particular cases, because it serves no purpose to do it, then don t let the system do it.