[Request] "Unload from memory" action

Discussion and feedback on Construct 2

Post » Mon Dec 29, 2014 11:37 pm

@newt
The subject may get skewed to the lack of technical knowledge. However the focus is Unload Plugin Object. Remove every instance, remove the object from the pool, remove all memory associated. Such as all the variables, texture and audio files while only keeping constructors for future use.

This is not about unloading a single part of a of a texture sheet, but the entire texture sheet. Good memory management usually means that textures are packed into themes. Such as snow theme, grassy, roads, houses. If all the images of a theme are packed to a single Sprite plugin. Then once you leave the Arabian city far enough, just unload the sprites that store the Arabian city and various other Arabian city themes objects.

So if the developer is making a vast world where players can explore pole to pole each visual thematic area would be composed of a Sprite Object for each visual type of an area.

Area Vegetation
Area Animals
Area People
Area Buildings
Area City Stuff(fountains, benches, lamps, signs....)
Area Paths(roads, paths...)

Unloading a piece of a texture would serve no purpose. even if that happened the sheet itself would still be composed of X by Y size.

However the catch and I understand this from Ashley's point of of view. This requires more understanding and technical knowledge. And we know what happens when more technical aspects are implement. There is a big rush to use, only to find out that such a feature is for expert use and not beginner.

However I do feel that such features should be there to use, with warning that it's not for beginners. C2 is a fantastic community with an incredible amount of helpful people.
B
90
S
18
G
9
Posts: 2,455
Reputation: 15,038

Post » Tue Dec 30, 2014 1:21 am

I don't think it should be unload texture.
More like: destroy object... with extreme prejudice.
But then the wet blanket would now have to be placed over "how does that work in canvas2d?"
Image ImageImage
B
171
S
50
G
179
Posts: 8,382
Reputation: 113,458

Post » Tue Dec 30, 2014 3:25 am

Besides there a problem that system is destroying an object even all instances are destroyed may NOT unload memory.

It only works when layout is changed to another layout including global objects. I think destroy sprite as unload from memory would be useful feature.
B
99
S
35
G
29
Posts: 3,139
Reputation: 28,421

Post » Tue Dec 30, 2014 3:32 am

Sometimes you only need to create an object to do something specific and after that you don't need it anymore. But unfortunately object loaded into a memory will stay there until next layout and of you have few that kind of object then this is simply a waste of memory.

I wonder: would the memory for deleted objects be reclaimed if we set the layout static, go to another layout, and then return to the static layout? If so, then we have a workaround that you need to have the user swap out to a different scene from time to time.

Personally, I would like the ability to create scenes and delete scenes during runtime. Again, quite useful for open-world scenarios.
B
6
Posts: 4
Reputation: 258

Post » Tue Dec 30, 2014 1:34 pm

@shinkan - as far as I can tell from your example, your process is to:

1) load 100mb of images on startup
2) draw them in to Paster (which only uses ~16mb)
3) (the request) release the 100mb of images

Even if this was supported, it appears your peak memory usage is still 116mb. If the device is memory constrained, then unloading the textures afterwards will not help, it will have already risked running out of memory at the point of drawing them in to Paster. In fact using Paster increases the peak memory usage from 100 to 116mb. And if it can handle having 100mb of images loaded for a moment, then surely it can handle leaving them there until the end of the layout too? Since AFAIK the main issues with memory usage come from crashes due to peaking high, it seems the better option is to give up the optimisation and go with a lower steady 100mb than a 116mb peak, plus it is probably simpler.

I don't think everyone else who's agreed so far is aware of this. I think there needs to be a description of a better use case where objects are created/destroyed during runtime and they really can't hold their images in memory until the end of the layout.
Scirra Founder
B
399
S
236
G
89
Posts: 24,525
Reputation: 195,382

Post » Tue Dec 30, 2014 2:12 pm

@Ashley

1) load 100mb of images on startup
2) draw them in to Paster (which only uses ~16mb)
3) (the request) release the 100mb of images

at point 3. after releasing all 100mb of images same time I'm removing every instance of every object I don't need anymore. So after a "clean up" there should be only one object in the layout - Paster, and this layout should use only ~16mb altogether because there is nothing else.

i do not say that device can't handle this or there are crashes of any kind.

As I see it. There are hundreds of different kind of objects in the layout, that are using ~100mb in textures. And they are doing nothing. No tests, no collisions. They are simply a "background image". But they take quite a lot of memory and probably quite few draw calls and some CPU just for being there. So instead of keeping them I could exchange them for only one object that takes less of everything.

And this goes only for my example. There a lot of other things that could benefit from ability of dynamic unloading from memory.
ImageImageImageImage
B
158
S
66
G
43
Posts: 2,603
Reputation: 35,868

Post » Sat Jan 03, 2015 1:57 pm

My point is if you're going to run out of memory at any point, it will be step 2, before there's any chance to unload anything, meaning the feature doesn't help prevent the device running out of memory.
Scirra Founder
B
399
S
236
G
89
Posts: 24,525
Reputation: 195,382

Post » Sat Jan 03, 2015 5:50 pm

doesnt a game that has 100mb in memory run slower then a game that has only 16mb in memory? so even if you dont run out of memory you should get a better performance on older devices wright?
B
38
S
11
G
5
Posts: 485
Reputation: 5,340

Post » Sat Jan 03, 2015 6:05 pm

Why would it run slower? It either has enough memory or not.
B
19
S
6
G
7
Posts: 1,101
Reputation: 6,146

Post » Sat Jan 03, 2015 6:37 pm

maybe im wrong but i figured this because i have 4gb of ram on my pc and when the browser uses >1gb everythign kind of lags so i thought on a mobile its the same, even if the game doesnt use all of the memory (or more then available), other tasks in the background too need memory and everything just runs slower when you come near the memory limit. is that wrong?
B
38
S
11
G
5
Posts: 485
Reputation: 5,340

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 4 guests