Memory overload

[Charles2020]

Hi Guys

I ran into an issue when play test my game. My game has lot's of events, lots of maps, lots of plugins. All maps use parallax. My window computer is not robust.

Everything is going fine if I dont go to many maps (I can play > 4 hours); however, If go to several maps like open world exploration thing (>20-30 maps), game keeps shutting down instantly without error messages. The editor remains open.

I noticed that I dont go to many maps memory < 500mb, but once > 20-30 maps, it keeps rising (> 1000 eventually and close instantly). The editor remains open.

I heard RMMV keeps adding map info once players pass that map.

If there a way to get around this issue ? like plugin to remove unused map memory or garbage clean up every save points/certain time

Can anyone shed some light on this issue ?

Thanks

 

[gstv87]

All maps use parallax

bitmaps are a huge load.

 

[Nolonar]

If there a way to get around this issue ? like plugin to remove unused map memory or garbage clean up every save points/certain time

If such a plugin exists, I'd love to see how it did it.

Memory Management - JavaScript | MDN

Low-level languages like C, have manual memory management primitives such as malloc() and free(). In contrast, JavaScript automatically allocates memory when objects are created and frees it when they are not used anymore (garbage collection). This automaticity is a potential source of...

developer.mozilla.org

As of 2019, it is not possible to explicitly or programmatically trigger garbage collection in JavaScript.

I've been unable to find anything more recent, but I'd love to know if anything has changed in the meantime.

 

[ATT_Turan]

As mentioned above, parallax maps get very resource-intensive. Take the fact that you're making a particularly intensive game, add the fact that you say you don't have a strong gaming computer and...basically you don't meet the system requirements for the game you're making.

I would suggest you turn off the parallax backgrounds when you're play testing, then switch them back on when you're sending it to other people for testing/putting it up for sale/whatever.

 

[Arthran]

If such a plugin exists, I'd love to see how it did it.

Memory Management - JavaScript | MDN

Low-level languages like C, have manual memory management primitives such as malloc() and free(). In contrast, JavaScript automatically allocates memory when objects are created and frees it when they are not used anymore (garbage collection). This automaticity is a potential source of...

developer.mozilla.org

I've been unable to find anything more recent, but I'd love to know if anything has changed in the meantime.

AFAIK, that's just saying that you cannot tell then Garbage Collector when to collect garbage, and you can not explicitly free an object's memory yourself. But you can still set an object's references to "null" to make the object unreachable, which let's the Garbage Collector know that you don't need that object anymore, and then it'll get deallocated at some point.

 

[Nolonar]

AFAIK, that's just saying that you cannot tell then Garbage Collector when to collect garbage, and you can not explicitly free an object's memory yourself. But you can still set an object's references to "null" to make the object unreachable, which let's the Garbage Collector know that you don't need that object anymore, and then it'll get deallocated at some point.

Yes, that's correct. But the problem here is that OP is running out of memory after visiting 20-30 maps, meaning the GC isn't collecting often enough. This could be fixed by explicitly forcing the GC to collect (e.g. before loading a new map), which is currently impossible in JavaScript as far as I know.

 

[Arthran]

@Charles2020 Have you ever updated NW.js, or is it still the version that came with MV? If you haven't ever updated it, then I'd recommend trying to upgrade it to version 0.48.4 (the same as MZ), and see if maybe that'll help. The NW.js that comes with MV is very old and has less efficient memory management.

Yes, that's correct. But the problem here is that OP is running out of memory after visiting 20-30 maps, meaning the GC isn't collecting often enough. This could be fixed by explicitly forcing the GC to collect (e.g. before loading a new map), which is currently impossible in JavaScript as far as I know.

@Nolonar I personally don't believe that the OP is managing to play through 20-30 maps without garbage collection occuring. Provided that he's using a relatively modern version of NW.js, the GC should automatically be collecting much more frequently than that. I think it's more likely that objects that are no longer needed aren't getting marked for collection to begin with, either due to excessive caching, or due to plugins unnecessarily storing references to objects after they're no longer needed, or due to plugins putting eval() calls into functions that they probably shouldn't.

However, it's actually not impossible to force the GC to collect garbage. It's true that JavaScript doesn't natively support this, but fortunately for us, Node.js *does* support it. Since NW.js is based on Node, that means that we do have a method to force garbage collection. Of course, this only works on Windows/MacOS/Linux deployements--it won't work when deploying to web or mobile.

In order to do it, you need to have the --expose-gc flag turned on. To do so, just open the package.json file in your project folder, and make sure that it contains this line:

"js-flags": "--expose-gc",

I believe that MV projects already come with that flag enabled by default, but MZ projects do not. But if it's not already in there, then just add that line into project.json.

Then you can manually initiate garbage collection at any time, by calling global.gc();. So an example plugin of what you guys are talking about could be as simple as something like this:

(function(alias) {
    Game_Map.prototype.setup = function(mapId) {
        alias.call(this, mapId);

        if (global.gc) {
            global.gc();
        }
    };
})(Game_Map.prototype.setup);

However I'm still not convinced that this alone would solve the OP's problem.

 

[gstv87]

GC should be used as a cleanup after a correct resource management.
the correct way should be to put up a preloader, queue the resources to load, check if some of them are already loaded, unload what is not to be used, load what's necessary, and then cue a GC.
that's some tricky set logic, but doable.

 

[Andar]

All maps use parallax.

a parallax map needs about two or three thousand times the RAM of a tiled map. And no, that is not a joke. Just think about it: one tile has one number as identification, usually 2 bytes, plus some overhead for the tileset itself.
But each tile are 48x48 pixels in a parallax, which need 3 bytes color information for each pixel.
Simply do the math.

And the storage size on harddrive is compressed - but you can't work on compressed data. So when you are walking on that parallax map, it needs uncompressed space in RAM.
Please make a test and save your parallax as BMP. BMP has no compression, so the filesize of BMP tells you how much RAM that map would need when uncompressed from PNG.

Most current computers can handle a parallax size equivalent of 100x100 tile maps. If your maps are larger or your computer older with less RAM than usual, you will get problems.

 

[ShadowDragon]

Right-click on the parallax and go to properties.
you would see 2 data size (original saved data) and below
the bitmap size data.

mostly, the original size = small or way smaller than the bitmap
as that is the one that the HDD take to read the data.

like the original data that I use have images between 50-300KB
as I compress them as well (original it would be 900kb - 2mb)

the bitmap data says 1-4mb which is the size that reads it).
so that is the size if you need.

a compressed games (clean), shows 155MB (instead of 479M
bitmap shows around 600mb, so there is a different

saving as a bmp file is also possible to see the size. (could be different)
so you can check the bmp properties as well and compare them.