MV 1.3 Memory leak

[brandos]

So for me the memory leak for parallax maps is still there. Good job.


How to recreate the problem:


1. Create new project


2. Create 3-4 maps


3. Add a huge parallax map to each map. 


4. Test the game and travel through the maps


5. See the game.exe ram usage go up without going back again


Edit: 


Or create a map with a large parallax map and spam right-click. 


I honestly can't believe this isn't fixed.

 

[Tuomo L]

So for me the memory leak for parallax maps is still there. Good job.


How to recreate the problem:


1. Create new project


2. Create 3-4 maps


3. Add a huge parallax map to each map. 


4. Test the game and travel through the maps


5. See the game.exe ram usage go up without going back again


Edit: 


Or create a map with a large parallax map and spam right-click. 


I honestly can't believe this isn't fixed.

I do have a question related to this parallax memory leak since I recall that you had a working workaround. Does the old Parallax map memory leak patch work still? I think one of the previous updates to the engine broke mine and I haven't been able to use it. Is it updated and if so, where can I get it now?

 

[brandos]

There's no real fix for it, only plugins that dampen the effect. I've commissioned a plugin which doesn't let the memory leak go above 1GB which is a huge success in my eyes but I won't share it on this forum.

 

[Dad3353]

MV Memory Leak issue, 'Bug' report...


1 - No plug-ins, new Project from completely updated 1.3.1 version, stand-alone on a 64-bit, Windows 10 PC


2 - Already reported; this is the closest I could find (Could these 'official' Bug Reports be grouped somewhere, to help searching for 'em..? Just a suggestion...).


3 - I noticed this when testing a Windows-deployed Game for someone. After a short time (just the first screens of what should have been a fairly long, playable Demo...), the Game would crash (simply disappear from the screen...). Upon investigation, I noticed, by watching the Details of Memory though the Win 10 Task Manager that the 'Game.exe' memory usage increased by about 50 Mb at every screen change. It was easy to spot; even simply opening and closing the Menu screen would have the usage build up. Once approaching 4 Gb (not hard to do with 50Mb per Battles, and other screen updates...), the programme would simply disappear from both screen and Task Manager.


I tested this out on my own Projects, both in deployed form, and under the Editor, with exactly the same result. I have created an 'empty', minimum Project; this displays the same behaviour.


I was somewhat suspicious of this fatal '4 Gb' barrier, as that indicates to me (retired IT Manager...) a limit to 32-bit handling somewhere. I therefore tried having the MV 'Game.exe' run in Compatibility mode. The Mode that worked best was Vista, Service Pack 2, although XP SP 3 worked, too. Running in these conditions kept the memory use to a very reasonable level of a few Mb, with slight increases on changing screens, and a frequent memory reduction (something not seen running as native, 64-bit Win 10...). Running the RPGMV Editor in Compatibility mode gave similar results.


My conclusions..? There would appear to be something that runs badly under 64-bit, ramping up memory and not restoring it. This mis-handling seems to be 32-bit, as, when the addressing limit of approx 4 Gb is reached, a fatal crash occurs, with no warning. It can be alleviated by running under 32-bit conditions, where the memory is better (but not perfectly...) handled, being often released. It still cumulates, but at a very much slower rate, and could only become threatening in a very long, continuous, play sequence.


4 - Error report..? None


5 - Bug replication..? Run a new Project on a Win 10, 64-bit OS, and watch detailed memory use (Task Manager, Detail tab...). Play test the Project, and toggle the Menu screen on and off. Observe the memory use increasing in bounds of approx 50 Mb. Continue until 4 Gb is reached (it won't be...).


6 - A Sample Project (59 Mb...) can be found on my Google Drive, here ...


 Memory_1.zip ...


Thanks for your attention, hoping this helps; meanwhile...


Have a nice day


Douglas

 

[captainsteff]

MV Memory Leak issue, 'Bug' report...


1 - No plug-ins, new Project from completely updated 1.3.1 version, stand-alone on a 64-bit, Windows 10 PC


2 - Already reported; this is the closest I could find (Could these 'official' Bug Reports be grouped somewhere, to help searching for 'em..? Just a suggestion...).


3 - I noticed this when testing a Windows-deployed Game for someone. After a short time (just the first screens of what should have been a fairly long, playable Demo...), the Game would crash (simply disappear from the screen...). Upon investigation, I noticed, by watching the Details of Memory though the Win 10 Task Manager that the 'Game.exe' memory usage increased by about 50 Mb at every screen change. It was easy to spot; even simply opening and closing the Menu screen would have the usage build up. Once approaching 4 Gb (not hard to do with 50Mb per Battles, and other screen updates...), the programme would simply disappear from both screen and Task Manager.


I tested this out on my own Projects, both in deployed form, and under the Editor, with exactly the same result. I have created an 'empty', minimum Project; this displays the same behaviour.


I was somewhat suspicious of this fatal '4 Gb' barrier, as that indicates to me (retired IT Manager...) a limit to 32-bit handling somewhere. I therefore tried having the MV 'Game.exe' run in Compatibility mode. The Mode that worked best was Vista, Service Pack 2, although XP SP 3 worked, too. Running in these conditions kept the memory use to a very reasonable level of a few Mb, with slight increases on changing screens, and a frequent memory reduction (something not seen running as native, 64-bit Win 10...). Running the RPGMV Editor in Compatibility mode gave similar results.


My conclusions..? There would appear to be something that runs badly under 64-bit, ramping up memory and not restoring it. This mis-handling seems to be 32-bit, as, when the addressing limit of approx 4 Gb is reached, a fatal crash occurs, with no warning. It can be alleviated by running under 32-bit conditions, where the memory is better (but not perfectly...) handled, being often released. It still cumulates, but at a very much slower rate, and could only become threatening in a very long, continuous, play sequence.


4 - Error report..? None


5 - Bug replication..? Run a new Project on a Win 10, 64-bit OS, and watch detailed memory use (Task Manager, Detail tab...). Play test the Project, and toggle the Menu screen on and off. Observe the memory use increasing in bounds of approx 50 Mb. Continue until 4 Gb is reached (it won't be...).


6 - A Sample Project (59 Mb...) can be found on my Google Drive, here ...


 Memory_1.zip ...


Thanks for your attention, hoping this helps; meanwhile...


Have a nice day


Douglas

Thank you for your post Douglas. I too am struggling with this, as my game "Max, an Autistic Journey" is live on Steam and I'm getting complaints from players about RAM usage... 


I tried several different compatibility modes and I'm sorry to say, it didn't help at my end. It stayed the same or got really bad... However, I did run the Compatibility Troubleshooter on Game.exe and it gave me a report of "Incompatible application" and fixed it (!?). Now, RAM usage is somewhat better (between 10 to 20 Mb per leap less than before when changing maps.)


We're rooting for you dev team! Please fix this soon! 


Thanks!


Stef

 

[o_ggy]

MV Memory Leak issue, 'Bug' report...


1 - No plug-ins, new Project from completely updated 1.3.1 version, stand-alone on a 64-bit, Windows 10 PC


2 - Already reported; this is the closest I could find (Could these 'official' Bug Reports be grouped somewhere, to help searching for 'em..? Just a suggestion...).


3 - I noticed this when testing a Windows-deployed Game for someone. After a short time (just the first screens of what should have been a fairly long, playable Demo...), the Game would crash (simply disappear from the screen...). Upon investigation, I noticed, by watching the Details of Memory though the Win 10 Task Manager that the 'Game.exe' memory usage increased by about 50 Mb at every screen change. It was easy to spot; even simply opening and closing the Menu screen would have the usage build up. Once approaching 4 Gb (not hard to do with 50Mb per Battles, and other screen updates...), the programme would simply disappear from both screen and Task Manager.


I tested this out on my own Projects, both in deployed form, and under the Editor, with exactly the same result. I have created an 'empty', minimum Project; this displays the same behaviour.


I was somewhat suspicious of this fatal '4 Gb' barrier, as that indicates to me (retired IT Manager...) a limit to 32-bit handling somewhere. I therefore tried having the MV 'Game.exe' run in Compatibility mode. The Mode that worked best was Vista, Service Pack 2, although XP SP 3 worked, too. Running in these conditions kept the memory use to a very reasonable level of a few Mb, with slight increases on changing screens, and a frequent memory reduction (something not seen running as native, 64-bit Win 10...). Running the RPGMV Editor in Compatibility mode gave similar results.


My conclusions..? There would appear to be something that runs badly under 64-bit, ramping up memory and not restoring it. This mis-handling seems to be 32-bit, as, when the addressing limit of approx 4 Gb is reached, a fatal crash occurs, with no warning. It can be alleviated by running under 32-bit conditions, where the memory is better (but not perfectly...) handled, being often released. It still cumulates, but at a very much slower rate, and could only become threatening in a very long, continuous, play sequence.


4 - Error report..? None


5 - Bug replication..? Run a new Project on a Win 10, 64-bit OS, and watch detailed memory use (Task Manager, Detail tab...). Play test the Project, and toggle the Menu screen on and off. Observe the memory use increasing in bounds of approx 50 Mb. Continue until 4 Gb is reached (it won't be...).


6 - A Sample Project (59 Mb...) can be found on my Google Drive, here ...


 Memory_1.zip ...


Thanks for your attention, hoping this helps; meanwhile...


Have a nice day


Douglas

Hello, I have found the cause of this bug, and propose a work-around!


First, I show a work-around as plug-in. Please try it !


https://gist.github.com/oggy83/08851bce158191450c42535cdb0e9746


This memory leak bug is caused by PIXI.RenderTarget leaking.


Using debugger, Take a Snapshot, you can see increase the length of TextureManager._mangedTextures array.


TextureManager class contains Texture and RenderTexture instances, and Textures will be destroyed by TextureGarbageCollector class after running GC.


But, TextureGarbageCollector does not destroy RenderTexture instances (see PIXI.js at 12259 line)(RenderTexture has _glRenderTargets at WebGL mode).


In default script (that is, no-plugin), RenderTexture is generated by Bitmap.prototype.snap().


So, the number of RenderTexture's instance increases at TextureManager every open-close menu(or map transition), and never destroyed !


(You can see increase the number of Texture's instance too, but these will be destroyed after running GC. You don't have to care it, in ordinary case )


I think that RPG Maker MV should destroy RenderTexture explicitly.


- This is a new bug form RPG Maker MV 1.3


- This bug replicates at WebGL Mode.


<My WorkAround>


In Bitmap.prototype.snap(), I write a mark to generated RenderTexture.


then, on the next snap time, I search and destroy the RenderTexture explicitly.


Now, RenderTexture doesn't remain in TextureManager._managedTextures.


Thank you.

 

[Hackerham]

@o_ggy Great! We'll include this fix in 1.3.2. For now, its the only place where RenderTexture is used.

 

[Dad3353]

@o_ggy...


Disappointed. I downloaded the 'RAW' js file, placed it in the 'plugins' folder of my Memory_1 Project referred to above, used the Plugin Manager to incorporate it and ran the Project. There was no difference at all; when calling up the Menu then releasing it, the memory usage increased in exactly the same fashion as without the plugin. The Render explanation sounds plausible, but the 'work-around' plugin does not appear to make any difference.


I'll try again, in another Project with multiple Maps, which I could not run for more than a few minutes in Windows 10 mode, but which would run in Windows Vista mode. I'll report back here whether the plugin makes any difference there.


To be continued...

 

[Hackerham]

@o_ggy...


Disappointed. I downloaded the 'RAW' js file, placed it in the 'plugins' folder of my Memory_1 Project referred to above, used the Plugin Manager to incorporate it and ran the Project. There was no difference at all; when calling up the Menu then releasing it, the memory usage increased in exactly the same fashion as without the plugin. The Render explanation sounds plausible, but the 'work-around' plugin does not appear to make any difference.


I'll try again, in another Project with multiple Maps, which I could not run for more than a few minutes in Windows 10 mode, but which would run in Windows Vista mode. I'll report back here whether the plugin makes any difference there.


To be continued...

@o_ggy


GC runs every 2 minutes or so. The effect can be reproduced only if you wait for some time.

 

[Dad3353]

@Hackerham...


I'll run my 'Memory_1' Project again for a bit longer, then; cheers.


Edit: Ah..! That's much better..! A bit strange, but reasonable. This is a Test Project, with only one Map, so I duplicated this solitary Map so as to simulate more closely 'real' game-play. The Game starts off with 350 Mb of memory used. Transferring from Map to Map increases progressively in steps up to 1.25 Gb, which then stabilises over time. If I increase memory (by transferring rapidly, or by switching the Menu On, then Off rapidly...) I can push the memory up to over 2 Gb, but this gradually reduces back to 1.25 Gb once I cease this artificially brutal memory increase. In 'normal' game-play, the memory would appear to stabilise at around 1.25 Mb after having increased from the starting memory use. I can't see any way (in normal play...) that this could increase to the 4 Gb which was the original problem.


I'll now try using a 'real' Project, one which I could not use for long due to this memory problem. I'll post again with the results. I'm just going now, and may be some time...

 

[Dad3353]

Here's the result of some (non-exhaustive, but thorough...) tests done this afternoon...


On the Memory_1 test Project, the plugin works well, keeping the memory at a fairly constant 1.25 Gb from a starting memory take-up of around 350 Mb. Although technically possible to have memory use climb (hammering the Menu On/Off, for instance...), it can't occur in 'normal' play. Success.


With a more typical (for me...) game (Rachdale Cheese Teaser...), the opening memory use is a round 750 Mb. This climbs to around 1.5 Gb during normal game-play, including moving from Map to Map, dialogues, Menu switching and Battles. Without the plugin, the memory continues to slowly increase, and it doesn't take too long to grow to over 2 Gb. It is to be noted that my Games use no, or very few lightweight, plugins, and mostly RTP Maps. With the plugin, memory use stabilised at around 1.5 Gb. I do have one or two Maps with Parallax images (used in the traditional 'background' fashion only...); these Maps obeyed the same memory use as any other, and stayed at 1.5 Gb. If, artificially, the memory use is increased (rapidly moving between Maps, or Menu-bashing...), it soon falls back to the stable level. Again, in 'normal' play, no danger of reaching the 32-bit limits of 4 Gb or thereabouts, so success.


I have another Project, however (not my own...) which uses an extraordinary number of plugins, mostly from the Yanfly stable. In adding this 'work-around' plugin, I could not get it to reduce memory at all. I tried placing it as a last one in the (long...) list, and right at the top, as well as immediately after the Yanfly Core, all to no avail. Memory continued to climb from a starting take-up of some 800 Mb, when moving between Maps, turning Menu On and Off and Battles. The game crashes as before when approaching 4 Gb (usually around 3.5 Gb...). Unsuccessful, then, in that scenario. No explanation, as I'm a complete novice in the Dark Art of plugins.


Partial success, then, so 'Well done' for that; hope this helps; meanwhile...


Have a nice day


Douglas

 

[Andar]

@Dad3353 "Memory leak" is rarely a single error, most of the times it is several errors all creating the same result.


And your testing basically proves that this patch does solve the memory leaks of the default engine, but that some of the plugins introduced their own memory leaks.


But then that problem is in those plugins, not in the default, and no update to MV-default will solve those problems


It's the way how memory leaks work - uf they aren't solved at the source, the only thing other program parts can do is force a memory dump, and that will introduce other problems (and most likely break those plugins that don't have a good memory management).

 

[Dad3353]

@Andar...


I fully agree; I'm not complaining about MV in any way at all, simply trying to give some input to those with some of these issues. Myself, I'm much more of an unworthy 'grasshopper', and use MV in its standard, 'vanilla' form as much as possible. I can't offer any help to those using these plugins, except to illustrate, modestly, exactly that point, ie: the basic 'engine' is sound, and more so still since this new 'work-around' has been proposed. If, indeed, it becomes integrated into an later version, I shall be glad to abandon the plugin and rely solely on the native code to keep things in control. Those working with, or developing, plugins may, though, benefit from this accumulated knowledge. I certainly hope so.

 

[captainsteff]

@o_ggy Dear O_ggy, your fix worked like a charm for my game!! I had already taken out all of the parallax images, but still had some 300 Mb to 500 Mb jumps in RAM usage when changing maps. Your plugin fixed all that... I'm very grateful! Thank you!


Max, an Autistic Journey


http://store.steampowered.com/app/511630/

 

[Leon Kennedy]

I hope this gets fixed but at the same time people should really show respect to those who even put together MV this far into things and at the moment this is the only "big" bug I've heard of for 1.3.1. 

So for me the memory leak for parallax maps is still there. Good job.

Completely uncalled for. Not a surprise this one didn't stick around to try to figure things out but I guess he did follow this up with

I've commissioned a plugin which doesn't let the memory leak go above 1GB which is a huge success in my eyes but I won't share it on this forum.

Doesn't even warrant a response. Thanks to those actually trying to do something about this  

 

[YuiDemonia]

I am also hoping that this will  be resolved soon. I also use parallax images in every maps I have in my project and everytime I transition from 1st map to another, the memory usage goes higher until the entire pc freeze and couple of minutes later, the test exe. will auto close.


I will try the plugin work around o_ggy suggested later as soon as I get home.

 

[YuiDemonia]

Hello, I have found the cause of this bug, and propose a work-around!


First, I show a work-around as plug-in. Please try it !


https://gist.github.com/oggy83/08851bce158191450c42535cdb0e9746


This memory leak bug is caused by PIXI.RenderTarget leaking.


Using debugger, Take a Snapshot, you can see increase the length of TextureManager._mangedTextures array.


TextureManager class contains Texture and RenderTexture instances, and Textures will be destroyed by TextureGarbageCollector class after running GC.


But, TextureGarbageCollector does not destroy RenderTexture instances (see PIXI.js at 12259 line)(RenderTexture has _glRenderTargets at WebGL mode).


In default script (that is, no-plugin), RenderTexture is generated by Bitmap.prototype.snap().


So, the number of RenderTexture's instance increases at TextureManager every open-close menu(or map transition), and never destroyed !


(You can see increase the number of Texture's instance too, but these will be destroyed after running GC. You don't have to care it, in ordinary case )


I think that RPG Maker MV should destroy RenderTexture explicitly.


- This is a new bug form RPG Maker MV 1.3


- This bug replicates at WebGL Mode.


<My WorkAround>


In Bitmap.prototype.snap(), I write a mark to generated RenderTexture.


then, on the next snap time, I search and destroy the RenderTexture explicitly.


Now, RenderTexture doesn't remain in TextureManager._managedTextures.


Thank you.

Dude! I just want you to know that you are awesome! Memory leak has been reduced significantly and most of my maps that got parallax images on it are loading faster! (with the help of TDDP_PreloadManager.js)


I ran a playthrough test and so far so good! The only thing that I would like to raise though, is during sideview battle, there are random instances when the FPS will really drop to 1-5, and if I scroll to the battle options such as Attack, Magic, Item, Guard, Etc, the FPS goes up to 60 then immediately goes down to 1-5 again. If I select Attack for example, and selected a target, the FPS goes back to normal.


For some reason, the FPS goes down when it's my (random) character's turn to attack.


If we could figure this out too, this will definitely help alot of people

 

[Andar]

@YuiDemonia, please avoid double posting, as it is against the forum rules. You can review our forum rules here. Thank you.


Additionally, please do not quote entire posts for answers - the @ username function is enough for that.

 

[YuiDemonia]

@Andar


Oh sorry, I keep forgetting that i can use @ to call usernames xp I will keep this in mind.

 

[o_ggy]

I confirmed that RPG Maker Mv 1.3.3 has not been applied my memory leak fix yet, and the patch still works in the latest version.
You can use my patch continously.