The problem of initial data storing objects

0 favourites
  • 6 posts
From the Asset Store
Data+ is the best Data Management solution for Construct 3. It contains 4 Addons (Plugin & Behavior).
  • If you place every object type you need in the layout in the layout editor it is supposed to make the layout load faster.

    Also you can store info in the initial objects' variables and effect parameters that the later created objects can use automatically. That is very useful.

    I have set up a condition using the "create object by name" condition that every time when a normalmapped object is spawned from a normalmapped family creates the right normalmap for that object from the normalmaps family. I'm using one instance of all the normalmaps as a storage instance since the effect has tons of conditions and they differ for different objects.

    However, I'm finding it a bit tricky to deal with the fact that I want to destroy the storage objects at the layout start so they won't get on the way. If I simply destroy them all at the start then the other normalmaps that automatically get created at the layout start (using the automated method I described previously) for my normalmapped objects get destroyed as well.

    The best way I currently have to deal with it is having the initial storage items in a "destroy at start" family and placed in their own layer, and the storage objects of that family in that specific layer get destroyed at the start. It seems a bit crude.

    Are there better methods for dealing with initial data storage objects? I know using data arrays is one solution, but I think it's actually more cumbersome overall than my current method.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Put them on an unused layout, set your default parameters there. Same effect as destroying them on start of layout.

    As far as performance goes, I believe all sprites used in a given layout are loaded into memory before the layout starts, regardless if there is actually an instance of it there to begin with.

  • A few things:

    Do the objects need to be global for this to work if you place them in another layout?

    Do you mean that if an object is referred to in an event it is loaded to memory in the start of the layout even if there is no instance of the object placed in the layout editor?

  • This is from the manual:

    Layout-by-layout loading

    Construct only loads the images for the current layout. This avoids loading the entire project in memory which would be slow and consume a great deal of memory. When starting a layout, all images for the objects placed in the Layout View are pre-loaded. This includes all frames in all animations of any Sprite objects. (In other words, Sprites are either fully loaded in to memory, or not at all - they are never part-loaded.) When the layout ends, all images that are loaded but not used on the next layout are released from memory.

    I understand this meaning only objects that are placed in the layout editor view are pre-loaded.

  • Hmm I'm not sure about the memory loading.

    I do know all sprite objects used to be required to be on a layout previously, and that was no longer the case with c3 at some point.

    Putting the sprites on an unused layout was a way to get around it, without deleting everything at start of layout. They didn't need to be global.

    Someone more familiar with this than I can probably give a more definitive answer.

  • Does anyone know what it the best practice regarding this issue?

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