[Request] "Unload from memory" action

0 favourites
From the Asset Store
2D Tile Set
$2.99 USD
Tile map for your 2d platformer games, custom sets available on request
  • Ashley

    I asked about that in some random post, but I decided to make a "official" request, so here I am. Please

    In other post you mentioned that objects place on a layout are automatically loaded into a memory and will stay loaded until layout is changed. Objects that are not placed on a layout but spawn/created in runtime are then loaded into a memory and when last instance of it will get destroyed object will be unloaded from memory. But then it turns out that even if you create or spawn objects they will stay loaded for entire layout, even when last instance is destroyed

    And this is nice and good in overall, but not everytime. 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. Especially on mobiles where memory is very limited.

    In my previous and current project (and probably any future project that will need it too) I'm using very simple yet very powerful technique (sound a bit like some super martial arts killing moves ;P). And by the way a little tip for everyone.

    It involves using a R0J0hound Paster plugin. Basically all my backgrounds and UI's in game are made of a lot of instances of different sprites, tiled background, sprite fonts, 9-patched and whatever I need to make it all pretty. When everything is placed or spawn and set how I wanted then I paste it all into one Paster instance and delete them all.

    This make's my layout nice and clean because I don't need to do anything with them anymore - in my current project objects count drop to 1 (just the Paster) from initial 276!

    So object count is no more an issue. Unfortunately memory usage still is. Current background objects only are using over 100MB - this is after a lot of time spent on assets optimization and trying dozens of different things to do same thing. Adding one image that represents same content and same resolution takes only about 16MB! But doing it like this, using an image instead of all the assets, I'm loosing all randomness on level generation. And here comes the Paster. After pasting everything I get more less same memory usage as with normal image but I still have my randomness every time layout is started! And even that I still have control over Paster resolution, so I can make it a bit less pretty and save extra few MB.

    So once again, pretty please for adding an "Unload" action

    I don't want to make a hard choice between making my game pretty or playable on as many mobiles as I can

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • I think this was asked for before. Around the time the room region thing was implemented.

    I thought the answer was basically no. Value wasn't seen in it. Which is absurd. Open world and single layout games would greatly benifit among other things. But I believe the answer was along the lines of use multiple layouts.

    I believe the main concern was such a feature would likely be misused. And many people would complain about objects popping in as they load etc.

    Anyways, I would love to see this implemented.

  • Tylermon

    Yep. I put in the request object unloading completing a few times. With either no replies or the one you posted above.

    I agree with you. I would like it if Ashley would stop taking the quality of the game responsibility in his hands and put it the developers hands. Ashley shouldn't be concernd with popping, that should be our responsibility. If we want to allow popping because the feature benefit is worth it. Then let us.

    I pointed out that games like Midnight Club and GTA have popping and players have no problems. Let me handle popping and presenting the user experience. Not lock it off in the engine.

    However 2/3 years and I don't see the feature being implemented at all

  • I would love to have this feature as well. I wanted to have multiple weapons in my game each with unique animations. I have a lot of animation frames and would need to unload weapons I'm not using. Since that's not possible, I'm limited to only one weapon.

  • Yeah, something like an "unload from memory" sprite action, or system - "unload unused images" will be really helpful. It's annoying to restart a layout everytime when i want to destroy a heavy sprite and spawn another.

  • I think this is one of those features that would be useful to more experienced users, but would cause a lot of confusion for newcomers. I imagine Ashley has forseen the onslaught of 'performance issues' and 'bug reports' that would inevitably arise from improper use of such a feature.

    It's also quite possible that this would require some deep changes to the engine, given that, in its current state, textures are only unloaded at the end of a layout.

    Still...I would like to see this. It would make expansive, single layout games possible in C2, even on mobiles. I see the recent addition of 'Reload Layout X/Y' as a sign that Ashley has some interest in facilitating this.

  • Kind of hard to remove part of a texture from a spritesheet isn't it?

  • Kind of hard to remove part of a texture from a spritesheet isn't it?

    Not impossible

    But seriously. Sprite sheets are made by objects. Each object (well sprites only) have it's own sprite sheet(s). And it's quite logical that "unloading" the object you are simultaneously unloading it's textures. So if you have one sprite with 10 animations with 20 frames each, "Unload" will unload it completely. These are the thing

    TiAm was talking about "could cause a lot of confusion for newcomers". On the other hand loading that kind of object in the middle of the game will have exactly opposite effect. It will load entire object with all it's textures into a memory (no matter how many frames or animations that objects have).

    And new users should know that already.

  • Sounds like a useful feature, which would allow more variety to the types of games that can be made.

  • I second this, at the moment we really need to be stingy on how many animated textures we can have before gameplay stutters like a retard with parkinsons.

  • 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.

  • 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?"

  • 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.

  • [quote:kdtkumj9]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.

  • 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.

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