An Empty Object would be fantastic.

Post reply
0 favourites
From the Asset Store
Building Hidden Object Browser Games
$9.99 USD
This is a single chapter from the "Construct Starter Kit Collection". It is the Student Workbook for its Workshop.
PBMCube's avatar
PBMCube

  • So the conclusion is: it's not possible to fully disable object at runtime, which does not interact with other objects and runtime does not check it every tick? Instead having tiny impact, user has just memory increase to keep the object alive, just like an array and can access or update it, if needed.

    That sounds like being destroyed.

    What is the use case anyway? The only thing it has is position and angle, and those can be saved in a data object.

  • Well if we naively add a "disabled" flag, the engine would probably still have to check if that flag is set in a number of places, which still involves a tiny amount of work, which you can probably still measure if you went and made a million disabled sprites. It's difficult to eliminate these types of overhead in a general-purpose engine. So you may as well have a sprite, which also has a tiny amount of overhead, but is most likely negligible for all reasonable uses.

    We strive to make Construct as efficient as possible in general, and results like the recent post comparing performance across different engines show we've actually done really well with a super fast engine that can even beat some compilers. However striving to achieve exactly zero performance overhead even in obscure cases is likely impossible and very likely not worth the trouble as it would make no measurable impact to virtually all real-world games.

  • So in my case the empty object would not be a few off-screen to track variables. Each image sprite would have an empty object parent. So there would be a LOT of empty objects moving around using behaviors and other plugins. I think that was the whole basis of requesting an empty object, to use as parents for a great number of sprites, not to use a few off-screen to tracks variables, etc.

    The parent use for thousands of sprites lends credence to creating an empty object plugin for sure. Also, what SnipG said about the impact is interesting. With sprite invisible and collisions disabled, sounds like they are still in the render and collision lists and being checked against to a certain degree?

    Reading everything again, I don't know if there are many projects (if any) that would be impacted by having a lot of invisible/collision-disabled sprites being used as an empty parent object. It doesn't impact my project at all BTW.

  • Did few test with different settings and combination of them. Setting layer to invisible removes the check of other instances, only if they don't have behaviors and nothing on that layer moves. So it's possible to fully disable empty objects or group them by layer.

    Ashley if disabling "initally visible" layer option and it removes CPU work of layer1 100 000 object affecting layer2 100 000 objects. This settings should essentially remove GPU impact, but why it removes CPU to. So potentially, it should be possible to enable it when object are visible and layer is visible. So 100 000 object don't affect 100 000 object on other layer. Or something like that.

    By core it could be, if layer is invisible don't check objects on that layer. If it's visible, engine check each object on it's layer for some settings.

    Possible layer settings:

    Skip check

    Skip redraw

    ....

    win win

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • An invisible object does not render anything. The engine merely checks the "is visible" flag, and then skips it. This is a tiny, tiny amount of CPU work. But if you make hundreds of thousands of sprites, you can measure it. It should not be meaningful to any real-world game. I am open to being persuaded otherwise by an example Construct project.

    There's also the render cells and collision cells optimisations in Construct which have been around for a long time. Using these, providing you don't have events or behaviors that are CPU intensive, and that everything is spread out across a large layout, far away instances should have exactly zero CPU performance overhead, as the engine won't need to consider them for anything at all. So assuming you do that, it's already possible, and so again there is no need for a further optimised object to achieve that.

  • What is the use case anyway?

    I think it's overall. What has best performance, what is causing performance loss. When doing something you doing it corretly and don't have to redo it.

Post reply
Return to board index
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)