Reserved atlases are added to memory

#1

Hey there!

I have a few dozen atlases (1024*1024) with characters and objects. And as someone suggested earlier I’ve stored those atlas names to a script just to let application know that I will use them. It looks like this:

go.property(“a”, resource.atlas("/data/ccom/00.atlas"))

go.property(“z”, resource.atlas("/data/ccom/26.atlas"))

But I’ve just checked amount of RAM the app takes, and it looks like atlases themselves are stored in memory not some kind of references. I.e. it takes 300Mb and once I remove 30 of those go.property lines it takes 200Mb.

Can I somehow remove them (atlases) from the app memory and only leave their references? Now I use only like 30% of what it will take in a release build.

Thank you!

0 Likes

#2

Hey,

Any chance that what you are trying to do is meant to be achieved by dynamically loaded factories?

1 Like

#3

Hmm… not sure if it’s the case. That “batch” script is in main.collection. I create factories in runtime and then default atlases inside them are replaced with new ones (mentioned in “batch”). In that case you’ve mentioned, I’ll need dozen factories with the same functionality or with those “batch” descriptions.

For example… I have a default character factory and there’re 3 characters in game session. When it starts, I place 3 character factories with the same functionality and replace their atlases with other characters.

But it looks like this “Load Dynamically” can be helpful. Thanks! But still it might be really complicated since a lot of data is generated at runtime, i.e. I’ll have to load all possible cases.

0 Likes

#4

Oh now I got you, you’re replacing atlases at runtime and resource.atlas() doesn’t work outside of properties…

Then yeah to utilize this you’d need multiple objects, one for each atlas, and a factory for each one. Not very nice.


If resource.atlas() worked outside of go.property() then you could probably create a collection with a dummy object that was referencing all your atlases at once (so that they aren’t excluded from the bundle).

Then add it as a collection proxy and just never load it. So you would then just call resource.atlas() when updating the sprites. Perhaps they could add some sort of resource.atlas_async() to do this job at run-time?

1 Like

#5

Thanks! Guess it really might help, but it’s an incredible amount of work to put all references to separate factories… Items, characters, locations… OMG :cry:

Actually thought that those go.property line only adds some kind of reference.

0 Likes

#6

A job for an editor script extension maybe?

1 Like

#7

Sure! Thanks, britzl. Just found that feature a while ago.

0 Likes

#8

Do resources get unloaded from memory once the game object with script with resource properties gets deleted?

1 Like

#9

The resources are reference counted.
Resource properties are just hashes, thus have no real connection to that.
However, at build time we scan the resource properties to see what resources should go into a collection.

EDIT:
What we’ve thought a (very little) bit of, is to create a way to easily increase/decrease ref counts between collections. This is still on the drawing board, with no concrete plan attached to it.

2 Likes

#10

It doesn’t seem like go.delete somehow affects the memory used by the app. That “heavy” collection will be unloaded once the game gets back to meta. Still never tested this, but I guess it should work.

0 Likes

#11

Thanks for clarifying this!

Actually, after giving some thought it looks like that factories/dynamic loading feature is quite an accurate solution. Our current build is a bit heavy on images, so we know that it might have some issues on any engine… =)

1 Like