Is there a workaround to memory issues (yes, sort of)

0 favourites
  • 8 posts
From the Asset Store
amazing template of the game of ordering colors with strings made with construct3 (requires c3 license) optimized with j
  • Hello. I have been reading the forum hours and hours today and did find out that many has had the same problem as I did: The game crashes after an hour (or so) and this problem seems to be caused by a memory leak.

    I wonder if the game could save & load itself during playing; could it be the solution to clean the memory and how could this be done. I wonder if there is some experienced workaround to solve this problem.

    I wonder if there could be a somekind of :

    -when entering or exiting layout the game would save it´s state as a slot.

    -Then after X happens (x being: entering layout etc) : browser plugin reloads the game and after that loads the saved slot.

    Have you found somekind of solution to this memory leak problem for example with this kind of a solution (I don´t know how it would work yet)

    Surely there are some tips and tricks to this issue?

    I really can´t "diminish" the game so that´s not a solution for me. It´s not going to be a mobile game but a full desktop version.

  • If you think you are having a memory issue that cannot be resolved then probably post your capx and the necessary details in the bug section.

  • This bug is a well known issue and reporting it is not the solution as it is already many times reported. I think the solution however could be a simple one if reloading clears the memory. Just wondering how this could be implemented in the game. I test it today and let you know if I can work it out.

    Here are the links and capx´s to check out.

    I think that the conclusion was that these problems are memory related.

    I will now again try that box web solution (in my memory however it didn´t solve the problem, but let´s try again)

    Then there was this:

    the rotating beam (from hell). It really did cause a lot of problems. I think that in the end it was the memory again.

    So. Maybe IF reload fixes the memory leak, it could be used in some "genius" way in a game?

    edit: I wonder if chipmunk physics is the answer?

  • I have now tried chipmunk physics. Js error in 2 hours as the vanilla physics gives it in hour. I also tried an automated save and load and browser: reload system but it gives an error too. So memory is not cleared even though the layout was reloaded and in addition to that the game also did go to another layout from where it loaded the slot. The slot was an automated save after every 30 seconds (I tried with different values too).

    So far have not found a solution to memory purge.

  • To be clear the physics behavior issue and chipmunk behavior issue are two independent issues.

    I can only speak for the chipmunk behavior though.

    A save/load will do nothing for the chipmunk behavior, and in fact I didn't make saving/loading do anything.

    The only way to "refresh" is to reload the webpage.

    I probably won't have time to track down where the leak is in the behavior.

    In the meantime a practical solution is to maybe diminish the amount of leaking so it can run longer.

    Creating less physics objects is an obvious thing to do, but it's probably not the issue here.

    Less obvious is every time a physics object changes size, or changes animation frame, or in the case of the tilemap is modified then that actually causes stuff to be recreated in the physics engine.

    So if you want an animated Sprite to have physics then instead pin the animated Sprite to another Sprite with physics.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Good ideas! I will try to implement to the game browser: reload and after that load the game. Maybe that will clean the memory. It would be good if the save slot could be emptied too.

    edit.

    Once tested and seems to be working.

    My workaround is:

    1. Make the game (or player) save the game before critical moment (every 30 minutes or 1 hour or...) : save "slot"

    2. Make the game reload the game (browser: reload)

    3. Loader screen happens now and then player will click Continue.

    4. If load fails then go to menu

    5. If load exists: Load "slot"

  • To be clear the physics behavior issue and chipmunk behavior issue are two independent issues.

    I can only speak for the chipmunk behavior though.

    A save/load will do nothing for the chipmunk behavior, and in fact I didn't make saving/loading do anything.

    The only way to "refresh" is to reload the webpage.

    I probably won't have time to track down where the leak is in the behavior.

    In the meantime a practical solution is to maybe diminish the amount of leaking so it can run longer.

    Creating less physics objects is an obvious thing to do, but it's probably not the issue here.

    Less obvious is every time a physics object changes size, or changes animation frame, or in the case of the tilemap is modified then that actually causes stuff to be recreated in the physics engine.

    So if you want an animated Sprite to have physics then instead pin the animated Sprite to another Sprite with physics.

    What if the animation collision points are in exactly same positions in every frame? Is it "cheaper" considering memory usage?

    I will test it however to see if it feels lighter.

  • This is a quote from the chipmunk thread: "when the animation frame is changed the collision shape is recreated. The only way for it to know if the collision polygons of two different frames are the same is to compare all the points, which may be slower than just recreating it. Also note changing size also causes the collision shape to recreated as well."

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)