That is what I was thinking. Some would spend countless hours getting rid of families to find no performance change. Some things you can't do easily without families.

Although this doesn't take hours to test. For families it's as simple as editing the family and removing or replacing the family members with a low count sprite. If you don't notice any significant performance increase, no need to worry.

NetOne

Looks like you'll be in for a treat when the c3 runtime drops. I'm not using nearly that many families but most of my sprites are in a family or two. I'm actually thinking of waiting until then instead of wasting too much time on further optimizations.

I can correct it a bit, but the point of the Tutorial and the thread is to identify possible slowdowns, if there is any, and how to deal with them in the case these features are actually the cause. But i still think it's good to inform people of the impact of using some of the features if used extensively. The tutorial is not aimed towards beginners anyway.

I for one suffered big performance hits because of this on my own projects which I now need to completely restructure to reach my target performance. It could have saved me a lot of work trying to identify what was causing the bad performance if I knew about these issues beforehand, and design my game accordingly. As I'm developing for mobile and is also targeting lower-mid range phones this made huge difference for me. I've spent countless of hours trying to squeeze every time bit of performance out of the game in the wrong areas when it was just a matter of removing Families. I even payed plugin developers to make custom plugins for me just to squeeze out a few % better performance. About every single sprite in my game was a member of a Z-order family and a that big of performance hit to use the family feature is just not acceptable for my goals. Simple tests showed clear improvements in my games performance by removing most families all together.

At the current state of families in C2 wouldn't recommend anyone to use it for large projects, or mobile projects targeting lower-mid range phones due to these new findings. (Project depending of course)

I agree if you don't have any issues don't bother, but if people are experience performance issues it's good to at least let them know, what might be the cause. It's pretty easy to test, but can be a lot of work to redo if you're far in to the project. I've been taking long development breaks from my main projects doing other stuff, because I simply couldn't reach my performance goal... Families turns out was the issue. I wanted to use animated tree canopy, and grass etc in my project as well, but scrapped that because my game was already at the limit of what a low-mid range phone could handle. Now i can finally implement that and other things because I know how to get those extra resources available.

I'll do some editing to the tutorial, as I don't want to promote any bad practices. And make it more clear that IF they have issues. This might or might not be causing it.

https://www.scirra.com/tutorials/9608/p ... animations

Just posted a small little tutorial here on these issues, and how to deal with some of them. Now I can't wait for the new runtime to drop.. <img src="{SMILIES_PATH}/icon_e_biggrin.gif" alt=":D" title="Very Happy">

great work finding all these things, I especially love the conclusion summary part.

Thank the original poster who pointed it out. I simply tried to dig a little deeper, as I have been noticing similar issues myself.

With these new findings I'm gonna try do a small tutorial with performance tips to combat these issues.

Families, Behaviours and Animations are so widely used in most projects. So now that we know a little bit more about how the C2 runtime handles these things it's good to inform people so they can make changes in case they experience performance issues, where any of these things possibly could be the cause.

I'll be referencing this thread with Ashley's explanations so that people can get a deeper understanding on what's going on under the hood.

I wouldn't say these are issues that would break projects, but it's good to know what might cause a bit of a slowdown if you're using any of those features extensively.

https://www.scirra.com/construct2/releases/r232

In c2 this bug was fixed in this release. I don't know if it was properly fixed for the c3 version as you just stumbled upon it, or if it only happens to imported c2 projects.

I think that's easy to test, so you could probably file a bug for it if it happens again.

Just make sure that everything you are Z sorting is on the right layer you should be fine.

To make sure, test your layers by setting visable and invisable then you can find if there is any sprites on the wrong layer.

You can also add this to the start of layout.

On start of layout > Move Sprite(or falily) to layer.... to make sure all sprites you are sorting is on the correct layer.

Or you can add a condition to your Z sort.

"is on layer" that way you will make sure you only z sort thing on that particular layer.

Could it be that you are trying to Z sort something that is on the wrong layer?

Yeah i agree, some might not be that critical, but I tested this because I was thinging if you have a layout with a lot of grass turfs with animations blowing in the wind it would be good if you can properly stop them from ticking especially if they are off screen. A lot of small things add up, even small thing like grass turf animations, water animation sprites, canopy etc etc.

Edit: tried another setup of this as well, and off screen animations seems to tick as well. So if you have a good ammount of animated scenery, it could potentially animate (tick) off screen even though you don't see it.

So being able to completely stop ticking for sprites would be good. As the stop animation action doesn't stop animations. Only freezes the frame, is that correct?

Hopefully I'll be able to post more news about the state of the C3 runtime by early next year. I just don't want to commit to too much yet. It'll be our main priority after the full launch of the C3 editor, though.

Thanks. While we're on the topic I found another little quirk now. Using the same example "Quad issue".

Adding another frame to the "sprite" object seems to have a performance impact as well (about 25%) But it only happens if you set the speed to anything else than 0.

Repeat count is set to 1, so the animation should stop after the first loop. But somehow even if the animation stopped playing after the first loop, it not actually stops unless you specifically set speed to 0 at start of layout.

Adding an event to to set speed to 0 or "stop animation" action with a mouse click didn't seem to stop the animation or reduce the load either, and decrease the CPU load. It's still using more CPU if an animation has been run. It never really stops. And if you use a lot of sprites with animations you will notice this performance drop.

Attached a modified c3p here

https://www.dropbox.com/s/kfy9zew4bxlkh ... f.c3p?dl=0

Click should stop the animation completely.

Try setting animation speed to 0 and the performance is back to normal.

Conclusion:

Sprites with animations stopped or not will never really stop once started, even with events stopping the animation, and will cause an increased CPU usage as long as they persist in the layout.

Thanks for the explanations ASHLEY. Seems like we're looking for quite a bit of performance improvements with the new runtime.

Is there any rough estimate on when the runtime will ready for beta or the masses? I'm mainly thinking if I should spend time now to optimize my projects with the new found knowledge of polymorphism (family) issue, or keep going and plan release when the new runtime is ready?

Seems like many of these issues affecting performance will be non-issues with the new runtime.

Now get back to work and stop crawling the forums so we can have those improvements sooner rather than later.

Exciting times indeed!

Ashley

Just out of curiosity I ran the same tests "Quad Issue" with a solid behaviour on the sprite.

There's no collision checks going on and I noticed a hit of around 40%, even when the solid behaviour was set to disabled.

So it seems like behaviours are also suffering from this polymorphism issue?

EDIT: Using two behaviours on the sprite (Anchor and solid) gave me about a 60% drop.

EDIT2: Adding the effect grayscale on the sprite game me 32000 max sprites, where as original was 180.000

But adding the same effect to the Layer instead of the sprite showed now significant drop.

EDIT3: Adding solid behaviour to either the family or the sprite gave another hit of about 10%. from 180.000 to 95.000

This is quite good to know now for performance issues. Families, behaviours, effects, all seem suffer from this polymorphism so it's wise to use them sparsely, but it's a bit sad that we're missing out on that much performance, due to this. On the good side..... it's being worked on.

It completely changes the way I will design my games and levels knowing this, until the new runtime drops.

Conclusion

So would it be safe to assume that behaviours also suffer from this polymorphism issue? Having a lot of sprites with solid behaviour will suffer this issue? And disabling or enable behaviors didn't have any effect on this polymorphism.