I am sure that some common practises to make sure is not happening is to check how many sprites are spawned or created since if they come to same x,y it´s possible that there are many of them stacked one on another and game designer doesn´t see it.

For example my example of: create object did just that. In human intuitive there was this thought that: Create object (if there is not already and only one) however the game can create them all the time if you are not careful.

The conditions are therefore very important to see if they happen once are all the time.

This is the main thing about my question here.

I wanted to clarify the conditions when trigger once while true is really needed. For example I had a situation where game created sprites and invisible sprites that had a touch trigger on them.

Game went very slow and I realized that my condition was a global variable (Thisthing=1) and event was create object a (and b etc etc)

Then I realized that it created them all the time and game became very slow. So I put there this trigger only once additional condition.

It would be good to know when these are needed. For example if there is a condition that turns sprite to zero angle.

(and it has done it). Does it still do it everytime or will the game just "see" it that the sprite´s angle is 0 and does not try to do the command.

So in a nutshell: Is it more efficient to a) put there a additional condition: sprite angle <> 0 or is it faster to just let the game try to check the angle.

Which one is more efficient in a game sense meaning which are the things and solutions that are faster than slower (sorry english is not my primary language)

I wonder if we could actually make a list of common solutions that work better than the other and has the same kind of an outcome.

For example: Which one is the best way to bring a sprite into a play. a) another object spawns it b) it´s already there hidden somewhere and it´s repositioned or c) create object

Or:

Set animation to default

Then the animation is default. Should the game check it all the time and put the animation to default even though it already is or does the game check that: animation is already default and does not have an impact on it (does not do anything).

I wonder if there are many conditions it would slow down. For example in the previous example. Should there be an extra condition:

if animation is not default then set it to default.

or just simply:

set animation to default (no matter what, even if it already is default)

Which one is a better practice?

Yeah. Depends on the situation is probably the easiest answer but certainly people that have a lot of experience have a somekind of a feel that which way is the best to approach.

So I think that we need those experienced solutions that game maker should try first. There are a lot of tips and tricks spread all around these forums and those tidbits should be put into a same place where they are easily found. Common practises or something like that.

Like this way:

All triggers should be on top of events

All ticks should probably be on the same action

Avoid too many sub-events

Always create object and not use spawn object if possible (or vice versa)

wait for 0 seconds (sometimes very useful even though not intuitive)

What kind of conditions are best working when something occurs only once or all the time.

Condition can be left empty!

All kinds of stuff.

etc. etc.

Sure there are many of this info available but somekind of a experience must have been built that which solutions work faster than others.

Sorry for my english.

This has bothered me also. Could someone please show an example capx or an image of the code.

I just put a huge layout into only 200x200 but margins are 25000 and 25000 (unbounded scrolling: Yes). It seems that strangely layout size does not affect the outcome at all! The little layout dotted line square gets smaller but at least in my game it doesnot have any purpose. I wonder if it makes the game run smoother.

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.

> Where is this Video plug in you are talking about?

>

It's a Plugin so will need to be added to your Layout like you would any other Object. It's under the section 'Media'.

Thanks. This is interesting!

Where is this Video plug in you are talking about?

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"

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.

Just to be sure

1. What kind of shapes are forbidden or denied? Overlapping lines in collision points?

2. Concaving shape? (I can´t remember correctly but I think that somewhere was mentioned that these kind of "U-shapes" should be avoided)

Tried to check for manual but could not find any mention about "forbidden" shapes

I am having a similar kind of a problem. I wonder if it´s a memory leak. I hope it could be fixed.

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?