It will probably be an on/off thing, i.e. either you get a fixed performance hit to the project, or you don't (I don't think it will get worse if you keep adding families, but maybe we should benchmark that too).

I already tested that. Adding more families didn't have any impact. If the sprite was a member of 1, or 20 families I noticed no significant difference at the moment. It only seemed to scale off how many instances that were in any family.

Is there any other features that you can think of that might suffer from this polymorphism issue, I'd be happy to run some tests, and see what kind of performance hit they have.

Thanks for the detailed explanation Ashley

Sounds very promising that the new runtime is showing some nice improvements in this area. Very reassuring... Can't wait to see what else will get better with the new runtime

What the hell?

So Families are pretty much unusable if I'm developing for mobile? That's awful.

But a big thank you to you guys for not just giving in and testing and insisting that there's something wrong with Families. Really good to know. Makes you wonder if there really aren't even more things not working quite right hindering performance.

I wouldn't say unusable, but it seems to be wise to keep an eye on how many instances that are members of a family, as it does seem to impact performance a bit. If the object count is low it doesn't have much impact, but if many of your sprites are in families there was a performance drop.

Mostly noticeable on lower end devices or larger projects with a lot of sprites.

damn,

pretty much every sprite in my game, bar the bullets and hud, are in a single family. Can be 100s at a time

I will have a look tonight.

Yeah i checked on of my projects as well, and got quite a nice performance boost by removing families. Every single Level sprite that was going to be Z-Ordered was in a family called Z-Order. 100's of instances.

On my mid/low-end windows phone framerate jumped from 45-50 to constant 60fps now, and seemed to help a little bit with stuttering as well.

I bundled all Level objects in the same sprite using animations and frames instead of using multiple objects and a family. I always wondered why my game was getting slower and slower as I added more static level sprites. Turns out it was because they were in families.

I'm going to do the same for all my pickups, and other things as well that has a fairly high instance count.

I remembered this mentioned in one of the blog posts, and found this to be one of the most interesting future plans.

https://www.scirra.com/blog/204/the-fut ... -3-runtime

I'm just curious and want to know more about what's planned for this and what we can do with it. One of my main problems is that I really suck at coding but have several plugin ideas i wanna make, but don't know how to do them in javascript. I can do them with events but this modular idea sounds really good.

Is there any design specifics about this that you can share at this point? Or at least a little bit more info about it, and how it's planned to work?

I'm wondering if you can basically select a set of events, bundle it in some way, and add parameters for reuse in other projects, or shared with others? It seems like a really awesome feature that I want to know more about.

Ashley

Just out of curiosity i ran the C3 performance test quad issue with and without Families as well.

Without family I was getting about 185000 sprites.

https://www.dropbox.com/s/q8ethv0ibpm0s ... y.png?dl=0

With families i was getting 118000 sprites.

https://www.dropbox.com/s/kr8s8h3nd4abr ... y.png?dl=0

If most or all of your ingame sprites are included in one or several families, you could be looking at a quite significant performance drop. Resources that could be used to make the game better or have more fancy effects and gameplay mechanics, or just running smoother and better on less powerful devices.

Show's quite a big decrease in performance when using a large number of instances in families. Families is such a nice and frequently used feature in most projects so I think it definitely deserves a bit of attention as it can be a major resource hog. Even for C2, and not as a C3 runtime exclusive update.

Due to these recent findings I did some quick tests on an old mobile project:

*Removed all static level objects from families. Instead bundled different objects in the same sprite by using Animations, and frames, and got a quite significant reduction to CPU time (Engine). (Mostly noticeable on mobile)

Conclusion:

* Don't place sprites with high object count in Families, as it will impact CPU usage.

* Families most suitable for low object count sprites, like enemies and pickups, etc.

* Reducing the amount of instances in a family will reduce CPU usage under "Engine".

Maybe that would help some people with performance in large projects, and mobile projects on lower-mid range devices, until it has been looked at in a future update.

Thanks for looking in to it.

Yeah 100.000 static objects, is not that bad. But games are far from static, so losing a big portion of CPU time on something that isn't doing anything, or and is even invisible isn't really optimal just to use the family feature. Hopefully you can find and optimize this in future runtime updates.

And as he said. As CPU time goes up Framerate drops.

On a side note there seems to be no difference if you use 1 familiy or 15 families in the project. The increased CPU usage seems to depend on whether you're using any families at all. 0 families no CPU time increase.

Edit: Or rather. 0 objects in families. No increase. the more instances that are in any family the CPU time increases. Anywhay, this is quite good to know, it's better to use families for low count objects like monsters etc, and not so much for building blocks and level sprites, that can get high numbers quickly.

I just tested this as well. If the sprite is member of No families the CPU is 0% (Engine) even if there is 50000 in the layout. As soon as you start adding them to families The CPU usage goes up.

I'm just guessing that somewhere in the background, there is something updating every tick with what family a sprite belong to. Maybe some SOL list or something? I have no other explanation for this. Something in the runtime that keeps track of what families a sprite belongs to?

As you can't change members of family in runtime, I'm not sure why this is something that needs to be updated every time though (if it's that)?

For large projects i think this can be critical, or even some mobile games, as you have a lot less CPU power to play with.

Edit: Or if you take his project file. Run the debugger with the families. It shows for me 10% CPU usage.

When you delete all the families. Run debugger again without any families in project, the CPU usage is 0.5% for the same amount of sprites in layout.

This kind of boggles me, as I'm a heavy user of families in many of my projects.

I play around with C3 once in a while, and it seems like most critical bugs are dealt with at the moment. Seems fairly stable, and not much new coming in to the bug tracker. It has cooled down. I had no problem moving over some of my projects to C3 as I don't really rely much on 3rd party plugins, and I really like that I can just fiddle around at work when I have time over, so having C3 on the web, seems like very nice thing for me at least.

More payment options, standalone etc I guess will come sooner or later, but seems like they have more important stuff in the pipeline first.

I see one big problem with translating system expressions. If you're asking for help on the forum (which is english only) providing screenshots, or expression snippets, nobody could help out unless they knew the language.

And besides that Translating basic expressions are not going to help non-english speakers in their future endeavors of developing games as I don't know of any language that translates their syntax commands to local language. So not really a good idea...

Keeping it english would probably be a good things even for the young ones as they learn a few english words along the way.

Thanks for the info. Yeah I doubt many people would actually spend months to develop those kind of plugins, unless there was an economic incentive to do so (selling the plugins), or if a particular studio was using Construct for their development, and need those kind of tools for own inhouse use.

It's nice to see that some if is being considered, and in the plans though.

Although in C2 trying out the Q3D plugin earlier i did notice that this particular plugin was able to draw things on the layout. I think it was a 3D box, representing the camera, or a lightsource (can't remember exactly). Was this one of those special cases or is this functionality somewhere in the SDK? Ashley

Nice to see that bug reports are getting less frequent now so hopefully you can focus more on adding more features, goodies, and other awesome stuff.