Preloading sprites into Video Memory issues

> There is no need for a preload feature. Construct 2 already preloads any objects placed on the layout. If you create an object at runtime which is not in the layout, it has to load it then and there, which can introduce a jank - so just place the object in the layout and destroy it on start of layout. They will still be preloaded. Any objects placed in the layout will not be unloaded until the end of the layout. Objects loaded at runtime may also be unloaded at runtime if the last instance is destroyed.

>

Ashley I am a bit confused here. Say that the layout does include one instance for each required object. Naturally the objects will load with the layout. But immidiatly after that you suggest to destroy the objects. Wouldn't these objects be unloaded since the last instance is destroyed???

The suggested method is not very practical in my case. It is not reasonable to load all presenter animations when the layout will eventually use only one (randomly selected). My solution is to create a random presenter animation and place it offsscreen while the layout is being played, so it is ready for use when needed. This is actually an a bit lame but effective gfx preload procedure.

As far as I am aware, if the instance is placed on the layout view, it will exist on start of layout, and so will be loaded into memory for the whole duration of the layout, same if you create the object at runtime.

If you do not need an object to be loaded into memory, just don t create it and by extension do not place it inside the layout view, as for using a unique sprite with a lot of animation, I am pretty sure this is the exact reason why you should not use that unless the number of animation is not high.

Sorry to hijack your thread, but I have a small question: I have an unused layout, which contains all assets that are spawned in other layouts.

Is this a good practice, or should I place all the objects in the layout where they are spawn during gameplay?

Ashley I am a bit confused here. Say that the layout does include one instance for each required object. Naturally the objects will load with the layout. But immidiatly after that you suggest to destroy the objects. Wouldn't these objects be unloaded since the last instance is destroyed???

No: the runtime treats separately objects which are placed in the layout, and objects that are not placed in the layout but created at runtime. If you destroy the last of an object that was placed in the layout, it is still not unloaded until the end of the layout. If you destroy the last of an object that was not placed in the layout, it will unload it.

Ashley - Thanks for clarifying this issue. Makes perfect sense

Aphrodite - I do not use multiple animations in one sprite. On my setup each of these heavy animations is a separate object , I never need more than one animation at the end of layout so no need for multiple animation load.

No: the runtime treats separately objects which are placed in the layout, and objects that are not placed in the layout but created at runtime. If you destroy the last of an object that was placed in the layout, it is still not unloaded until the end of the layout. If you destroy the last of an object that was not placed in the layout, it will unload it.

hmm, did something change in releases since this post?

In r187 I have two layouts. layout1 is completely empty, layout2 have a sprite with few frames.

In runtime on layout1 when I click mouse button it creates Sprite from layout2, at this point image memory goes up to ~28mb. But if I then destroy this object image memory stays at ~28mb.

It looks like this "If you destroy the last of an object that was not placed in the layout, it will unload it" is not working, because after destroying last instance of the object that was initially not placed on layout1 it will keep it in memory instead of unloading it.

Edit: Switching between layout1 and layout2 shows image memory correctly. ~3mb for layout1 and ~28mb for layout 2. So i would assume that C2 is not unloading objects from memory even if you destroy the last instance of object from other layout.

Ah, maybe I was wrong - and it actually is probably more useful that way anyway. If you create an object at runtime then you might create it again later even after destroying it, so keeping its textures loaded helps prevent jank on the next creation.

Ah, maybe I was wrong - and it actually is probably more useful that way anyway. If you create an object at runtime then you might create it again later even after destroying it, so keeping its textures loaded helps prevent jank on the next creation.

Weeell not necessarily xD

Action to unload object would be really nice.

Scenario of how this could be useful. I was struggling with this for mobile games

You have a background made from 20 different objects and a lot of instances of them (tilemaps, tileddbg and sprites), and then on start of the layout you could simply paste all this objects into a Paster plugin and destroy/unload those objects because you don't need them anymore for this layout.

So instead of ending up with a bunch of different objects you have only one object that uses less memory and is easier to manipulate.

From my tests 1 sprite with few animations, each one have four frames with big images takes about 50mb of image memory.

After adding a Paster and pasting all of this sprites memory goes to about 60-65mb - Paster+current sprite loaded into a memory.

15mb or even 30mb instead of 50mb it's quite a lot for mobiles

Please consider adding an option to unload objects from memory, pretty please ^^

Shinkan, i'm with you on this, we need more control over video memory and an unload sprite action.

I stopped coding with Construct 2 becos of this issue and the stuttering performance I got on both a high-end PC and Mobile.

I thought a big point of the "room" discussion was partly memory management....but if I recall Ashley didn't feel we need any memory management. Even suggested using multiple layouts among other things.

My issue is multiple layouts means forget making any open world or dynamically created games.

We simply need 2 system event/action to do two things:

Unload any unused sprites/textures.

Unload specific sprites/textures. It can delete all instances as well.

On a similar note, if we can unload textures we should be able to pre-load them as well.

Label it an advanced feature. Warn people it is not advised to be used unless necessary. Tell people misuse could break games. But it is honestly something we need.

It's worth remembering some of the tests from the jerkiness thread (I think) which demonstrate that there are overheads associated with creating objects in addition to the video memory used. The conclusion there was reusing sprites was far more efficient than creating and destroying them.

It's worth remembering some of the tests from the jerkiness thread (I think) which demonstrate that there are overheads associated with creating objects in addition to the video memory used. The conclusion there was reusing sprites was far more efficient than creating and destroying them.

Yes, that is true and you should alway recycle your objects if you can. But sometimes you need only "one use" objects. And if that kind of object been used by player or whatever it will not show anymore in current layout. So there is no need to keep it in memory.

Like in my background example. I want some objects only for few ticks and after that they are not needed anymore. I don't really care about jerkiness on start of the layout because level is creating at this specific moment.

I liked the background example, very neat.

Edit to add: The creation and distruction of the same object type during runtime sometimes caused variations in dt so it would misalign with vsync, causing occasional frame drops or partial draws. My point about recycling is that, unless you are memory constrained (mobile, & like your example shinkan) there is something to be said for holding reusable game objects like bullets in stasis outside the layout, and only bring them into play at the appropriate time. I agree that this has no bearing on single use objects and I didn't mean to confuse matters.

Colludium

ahh. I see what you meant and Yes that is true as well.

I liked the background example, very neat.

Edit to add: The creation and distruction of the same object type during runtime sometimes caused variations in dt so it would misalign with vsync, causing occasional frame drops or partial draws. My point about recycling is that, unless you are memory constrained (mobile, & like your example shinkan) there is something to be said for holding reusable game objects like bullets in stasis outside the layout, and only bring them into play at the appropriate time. I agree that this has no bearing on single use objects and I didn't mean to confuse matters.

This can work wonders if you have a lot of bullets flying around (or any other small objects). Explicit recycling of bullets cut my CPU usage drastically. However, I think it depends on how many objects you are dealing with. I have up to 1500 bullets onscreen at once...were there only a couple hundred, the difference might not be so dramatic.

This can work wonders if you have a lot of bullets flying around (or any other small objects). Explicit recycling of bullets cut my CPU usage drastically. However, I think it depends on how many objects you are dealing with. I have up to 1500 bullets onscreen at once...were there only a couple hundred, the difference might not be so dramatic.

Could you help explain what you mean by this exactly? For example, what is the lifespan / timeline of a bullet exactly?

Thank you so so much