An Empty Object would be fantastic.

0 favourites
From the Asset Store
This is a single chapter from the "Construct Starter Kit Collection". It is the Student Workbook for its Workshop.
  • An empty object that has instance variables and behaviors would be a godsend. Just like unity has an empty object which is great for using as the parent object. It would add so much more functionality and options. This would kick C3 up a notch. Please consider adding this to a beta.

    Yes you could use a sprite and hide it but a dedicated Empty Object would be better performance wise especially on older mobile phones.

    Basically you could take the official Sprite Addon and rip out the rendering and animation and any other unnecessary things and wala!

  • Just set the sprite to invisible so it won't be rendered.

  • Just set the sprite to invisible so it won't be rendered.

    Already addressed that. :)

    Yes you could use a sprite and hide it but a dedicated Empty Object would be better performance wise especially on older mobile phones.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Yes you could use a sprite and hide it but a dedicated Empty Object would be better performance wise especially on older mobile phones.

    Prove it.

    construct.net/en/make-games/manuals/addon-sdk

  • Don't mean to be negative... But i'll indulge myself.

    This suggestion was already made in the suggestions platform, and it was declined.

    construct3.ideas.aha.io/ideas/C3-I-1463

    Mainly because the task can already be achieved and the performance impact (if any) is negligible.

    At the end of the day, the only real benefit of this feature would be having a specialised object type with it's accompanying special icon in the project bar and event sheets.

    While aesthetically pleasing, it's not worth it from a development stand point. From the user perspective, it would just be a little extra thing that beginner's would be left scratching their heads at. There are already plenty of those as it is.

  • Thanks for the reply Diego. If there's no chance for an empty object and a hidden sprite is negligible then that works for me. You know what's under the hood of C3 after all.

    No offense newt, but I can see why you have over 10K posts... ;)

  • Impact of the sprite that is invisible, 0x0 and collision disabled is not completely nothing.

    I made feature suggestion to handle cases like this, it was discarded.

    When you make for example 1 000 000 sprites, 0x0, invisible and collision disabled sprite. The CPU spikes 4-8% and GPU is 0.3%. Which makes it look like you don't need some special blank object.

    But when any other object on any other layer moves or rotates somewhere. Cpu will go into 80%+.

    So possible on mobile they do impact and you cannot disable/stop it to save power.

    Number is large, but if you make some sort of datasets, generate huge object maps and don't want them to impact overall game, then they still do, because engine does not offer ways to separate/disable object, layer... from rest of them

    Thing: "we don't want to add this or that because some users might be confused", has come up multiple times. I agree, it can be confusing on already developed plugin, but new plugins can be easily added to C3 addon exchange 'Addons & Extensions', every plugin or behavior does not have to come with editor to confuse users. They can install them when they want them and find plugin helpful.

  • Number is large, but if you make some sort of datasets, generate huge object maps and don't want them to impact overall game, then they still do, because engine does not offer ways to separate/disable object, layer... from rest of them

    And a data type object that's not a world object wouldn't work better?

    You do know that they can have instances right?

    I mean you can make the argument that the system has better features for dealing with world objects,(pick closest, compare xy, etc.) but the argument then becomes one for features to better deal with data in data type objects. Don't get me wrong I'll be the first to tout the benefits of using world objects as a way to deal with data(match three strikes gain), but a million is a bit much even for a high end system.

    Or just better freaking data type objects.

    You know ones that can actually store x and y positions like an index. Like a stack.

    Just like objects.

  • honestly I like making my "empty object" sprites. I make them nice colors and it looks good on the event sheet.

    For example I use a sprite object called "GameTimer". And whenever I need a timer for something I use it for that. I make it nice and orange and it looks like a nice custom object in my event sheet.

    if you can't spare 1 sprite that isn't even rendered you probably have much bigger problems than needing an empty object!

  • There is also the solution of empty dictionary/array, only downside is that you can't give them behaviors

  • When you make for example 1 000 000 sprites...

    I don't think anyone is suggesting using a million empty off-screen sprites. The alternative is to use just a couple of off-screen sprites. Try to measure the performance impact of that - not some other far more intensive case. I doubt you will be able to measure any difference at all, because the overhead of just a few off-screen sprites is negligible. Hence there is no performance reason to add a separate object for this purpose.

  • So my original issue that triggered my empty object suggestion was that I discovered you can't move/reposition a sprite itself while actively using the Orbit plugin on it. So I was looking to make the sprite a child of an empty object and move the empty object with Tween while doing the Orbit.

    I ended up creating a 16x16 yellow filled sprite named Empty (to make it easy to see on the Event sheet), making it invisible and turning off collisions and adding the Tween behavior to it, and using the Orbit Pin feature to pin the sprite to the Empty sprite. Now I move the Empty sprite with Tween and the sprite moves with it and can orbit with no issues.

    I do agree that a scenario of 1 million empty sprites causing a slowdown is extreme and not realistic. On the flip side, maybe an empty object would be a good project for someone in their spare time as a third party addon.

  • To be fair. Simple test showed that objects are not completely blank or empty. If you disable visibility, you get 0.05% GPU with 10 or 0.5% with 1m objects. So, it's working and GPU performance increase is non-existence.

    But CPU should not increase, if you got other objects which are moving. They still interact with eachother. I bet behaviors also check each other and you cannot never have blank object with it. ie: disabled/empty object which has no performance impact or link to other objects.

    1 000 000, 4-8% CPU, but when some other object moves it's 80%. Which makes it ~14x increase. From this, user can have ~72 000 object, to have CPU impact 4-8% while something else moves. A mobile or laptop is much weaker and easy calculation 100k instead of 1kk, from that 100k/14 -> 7100 empty object on lower performing device with 6% CPU. Now if empty objects have behaviors or such, it will be 2-10x less objects overall. So, potentionally empty objects with behaviors ~1000 of them, which should be blank and out of reach of other object are still having major impact.

    What should engine offer or have.

    • Way to disable object and remove CPU impact. Like setting it invisible, which complete removes GPU impact.
    • A layer where user can send objects and mark them disabled

    OP post descripes empty object as parent. Which seems to be more then few sprites offscreen.

    Anyway this how i see it:

    Engine cannot have disabled object.

    Engine internally checks other objects constantly.

    Pretty sure behaviors still check eachother, even when made disabled by checkbox.

    Haven't tested, but seems to be: ultimate tick mode still ticks engine math at refresh rate(60). So testing most stuff with that method, other then pure event math only, is invalid.

    User cannot change internal polygon/math tick rate.

    Everything has to check each other, redraw and recalc itself for next frame. User cannot influence it or change it to save perf or battery life.

    Anyway. Post does not seems to be, hey use array, but shed light if empty/disabled object could be done and are blank sprites complete good, considering performance. I added in some my own ideas n stuff, because why not.

  • Again, if you are considering only a few off-screen sprites to track variables and such, any discussion of 1000+ sprites is simply irrelevant to the use case and not worth discussing. I'm sure you can measure performance impact with a million sprites. But that has no relevance whatsoever to using a few off-screen sprites. The question is can you measure any significant performance impact with a few off-screen sprites? The answer is no, the performance impact is negligible.

    Even if we added an empty object to do things like orbit other objects around it, the engine would still have to track its position, and flag it as invisible. That's exactly what an invisible sprite does too. So I don't see how an empty object would improve anything in that case - the engine still has a tiny amount of work to do, similar to an invisible sprite, and so if you go and make a million of them there will be some performance impact. But the per-sprite performance impact is already so tiny, it doesn't seem to matter at all.

  • But the per-sprite performance impact is already so tiny, it doesn't seem to matter at all.

    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.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)