Permanently keep loaded image from URL?

Hi. So I've finally cracked the code on how to work with massive animated assets without bloating boot and iteration times. I wish I knew about the potential of the "load image from URL" functionality sooner. After I made my own image point system I could work with images in the files folder as if they were sprites. However I have one slight issue with it. Whenever I restart the layout, the sprites needs to be loaded in again. While this is mostly a very good thing for memory, it's a bit cumbersome since there's about 150 frames of main-character animation that needs to be loaded in at all times. Reloading them for every level feels a bit unnecessary. Is there any way to make the loaded sprites not unload on level restart/change?

Thanks

For the sprites you don't want unloaded from memory, place them on the layout editor normally and don't use load image from URL. Sprites that are in use in both the preceding layout and following layout are not unloaded from memory.

Problem with that is it'll affect boot time and bloat the project. Avoiding that is the sole reason I'm turning to this feature to begin with.

You can't have it both ways.

It either gets loaded at the start of the layout by placing it in the layout, or it gets loaded from another layout by creating it.

Loading locally by url is completely pointless as it's the same as loading from another layout.

The advantage is that you can decide for yourself which ones to load dynamically and which ones to load normally.

Also, there are ways to restart a layout manually, so you never have to change layouts after your initial load. You'll just have to put some work in.

newt No actually it's not. Try making a blank project and put 20-50 1080p images in the files folder. Notice how previews boots instantly, and there's no increase in image memory use. Now place those same images in a sprite. Boom got yourself several seconds of loading, and that memory use's pretty big. Also done tests on HTML exports, and you can clearly tell the images from files needs to be loaded from the server. They're not loaded in the same way as sprites. Also if you have a text object print the image memory use, you will see it rise considerably once you use the "load from url" action. Restarting the layout makes it disappear, and the memory use is reset.

This is the solution to making projects scaleble. This way you don't have load your entire game just to playtest that one level giving you trouble.

newt No actually it's not. Try making a blank project and put 20-50 1080p images in the files folder. Notice how previews boots instantly, and there's no increase in image memory use. Now place those same images in a sprite. Boom got yourself several seconds of loading, and that memory use's pretty big. Also done tests on HTML exports, and you can clearly tell the images from files needs to be loaded from the server. They're not loaded in the same way as sprites. Also if you have a text object print the image memory use, you will see it rise considerably once you use the "load from url" action. Restarting the layout makes it disappear, and the memory use is reset.

This is the solution to making projects scaleble. This way you don't have load your entire game just to playtest that one level giving you trouble.

You probably didn't understand what he meant... It actually is pretty much the same. Sprites aren't loaded into memory until they are required in the layout you load into. It is the same as On start layout, all sprites load from url. The benefit is that if those same sprites are used in the next layout after that, they are not unloaded from memory.

Try putting all your large images in a sprite on an unused layout, you will notice if you preview an empty layout, those sprites are not loaded into memory.

You use load from url on any given layout to spread out the loading process, so it doesn't necessarily have to complete all in one tick at the start of layout. This can give your users some heads up so it doesn't look frozen in the event of large amounts of sprites loaded.

There are also advantages such as under the hood sprite sheeting that using the sprite object gives you. Regardless of which method you use, the sprites will need to be loaded in the end and your peak memory use will be the same regardless, so you still have to split up your image memory load across layouts anyway.

Now if there were a specific action to UNLOAD a sprite from memory in a given layout at runtime, that would open up some possibilities in certain fringe cases.

Sprites aren't made to work with 20-50 1080p images as frames, that's part of your problem.

A sprites job is to load everything into memory when it's created. So instead of loading one image after another the system hangs while everything loads.

While loading by url alleviates that problem by giving you asynchronous loading, it does not reduce gpu memory usage.

Memory is memory, it can't be reduced by sideloading it. In fact I think it can raise memory use as those textures may be ignored by garbage collection.

A better solution would be 20-50 sprite objects loaded one at a time from another layout via a timer so as to not bog down the system.

oosyrag I tried it. You're right about the ImageMemoryUse only reporting the memory use on the given layout. However the boot time was still slowed down by having the images in a sprite object. So my point about improving iteration time still stands.

Also just to test browser memory use. I saw that having the images in the sprites folder still bloated memory use even when on another layout. In images it didn't raise memory use. However you're right that once they're loaded in they won't unload ever... Guess I need to get a hold on this wonderful plugin after all:

https://www.scirra.com/store/construct2 ... emory-3812

newt That was only for easily replicating the issue in an example. Yes I don't have that many 1080p images in the game. I am mostly planning on using this feature for dynamic graphics options. The default sprites will be mobile friendly, and a second set of assets' designed to look good all the way up to 4k monitors. However loading an entire game with assets of this magnitude is just unsustainable. I think it's finally time to try that plugin out. If the unloader works then I should have total control over loading and unloading assets.

What about marking a sprite as global?

It depends if you're booting into the layout with the large sprites.

Blank layout (fast load, no memory use) -> Layout with sprites (takes time to load sprites into memory)

Is equivalent to

Blank layout with empty sprites (fast load, no memory use) -> Load images via URL into sprites into same layout (takes time to load sprites into memory)

The top setup will normally keep images in memory when moving to the next layout with the same sprites. Have you tried making the sprites global and/or using the persist behavior after loading from URL? That could possibly keep them in memory across layout changes.

Generally speaking, it is advisable to design around a set peak graphics memory limit rather than try to fiddle with loading and unloading graphics into memory dynamically to try to get past memory limitations (Usually results in bugs and crashes and time spent with extra coding).

oosyrag While I get the sentiment. I've already made and shipped one big game relying on sprites and the built-in systems for loading, and no, even an empty layout within that project takes a long, long time to boot. It's to the point where you can't work efficiently anymore, if at all. I'm never making a game that way ever again. The extra time spent making tools to take advantage of manual URL loading to keep the boot/iteration time low pales in comparrison to lost time just waiting for that loading bar again and again. I will give global and persist a try though.

Edit: Yeah seems like the plugin only works like a layout switch. I guess I should've read the description more carefully. Which means the curse of C2 memory management continues... I'm so moving on from this engine soon.