Optimizing memory of large background images when changing maps

[Artsilver]

Hello there, first post!

I'd like to ask one thing that was on my mind for a very long time throughout the course of my online multiplayer game's development.

Imagine there is a large mansion and each distinct location/room of that mansion is a large JPG background image (2048x2048 or even 4096x4096 depending on room size, or along those dimensions), basically using a similar principle like what some games used prerendered backgrounds/illustrations for locations.

I want to know if there are any serious issues with this approach memory-wise, and I'd like to know how I could optimize these gigantic maps, how to go about loading/unloading them, because for now I just use a variable in which I store a  PIXI.Sprite for the background which changes its texture when entering another map. I also use the .from method rather than preloading.

I haven't done any crazy tests except trying to load 14 different backgrounds of 4096x4096 size at once and display them on the stage just to test things for fun, to which I got 1500MB or so memory in Chrome task manager for the GPU process, but essentially I'd like to know whether there is something I should be aware of regarding any overhead from this. Characters/entities are done with skeletal animation, but I don't think it's really that relevant.

To be clear, I want to make sure if I should free memory in some way when changing locations, and when I should free it, considering there will be probably dozens of rooms/locations of images of large sizes.

Any help/insights are welcome.

[ivan.popelyshev]

> 14 different backgrounds of 4096x4096 size at once

14 * 4096 * 4096 * 4 (RGBA32) = 896MB.  * 4/3 because of mipmaps , 1194MB. You might remove mipmaps if you use special webgl2 textureStorage operation instead of regular texImage2D. Otherwise, even if you didnt enable them - memory will be reserved. because of webgl backend on top of directx.

If you use compressed textures : DDS format (worsk on PC's) , PVRTC, ETC (ios, android) or even BASIS ( transcodes to all those formats, everywhere) - you'll get 1 byte per pixel

As to how to load fast - well, if you use JPG browser stores JPG and decodes it to RGBA before its uploaded, then frees it when it wants. You may use the same approach and use BASIS / DDS with gzip!, and decompress them when needed

Its not an easy task, yes.

Edited July 12, 2020 by ivan.popelyshev

[Artsilver]

Thanks a lot Ivan, I'm going to have to apologize for mentioning those"14 different backgrounds" because that was just a casual test to see how I can push limits of displaying things at once, but in the game things like this will never happen.

I want to display just one background at once, and changing it depending on where the player is, when colliding with a door, the player gets sent to another map, the background changes, etc etc. Just like the usual prerendered/hand-illustrated style of games. In other words, what I wanted to ask for with my question was whether there are any serious pitfalls regarding this design of changing maps, whether I should clean them up at some point and such.

I'm going to take notes of the things you mentioned though.

Edited July 12, 2020 by Artsilver

[Exca]

You can destroy the textures after you have used them and create new ones when needed. Or if you know that you are about to reuse them at some point then you could just reuse the old ones and let pixi automatic memory management handle things.

I have done one similar solution so that I created a graph that has basically a node with knowledge of what background it has and what are the next positions where it can move to. Then load that nodes bg and the ones next to it. And if distance goes farther away than N (in my case it was 1) then destroy that asset and reload when coming near again. And if loading hadn't happened yet when movement to another stage occurs then show a loading bar.