4 replies to this topic

[Aethelwulffe]

Fishing for any other occurrences of a little issue:

effect_create_above(ef_smokeup,other.x,other.y,0,c_black);
effect_create_below(ef_spark,other.x,other.y,3,c_red);

The simple code above is a cheap way to set objects colliding with an exploding incendiary grenade afire.
It is timed to last for 45 steps, and may affect several objects simultaneously (yes, expensive).
With previous version, had not ever noticed any problem using these built in particle systems, but now this particular code slows the game to a crawl (0.1 FPS), and does not let go of the framerate even after the creating object is destroyed. I have not noticed any issues with any home-brew particle systems, only this one bit that uses the built-ins.
I am vaguely aware of some memory leaks in GM that prompt me to clear system memory between runs, and how it leaves the desktop partially unrendered on several machines (upper half of top icon row not drawn) when closing sometimes, but this is a new one.
Any chance that the particle system isn't getting destroyed properly with the built-in effects? I'd blame it on the machine, but GM8 and GM7 seemed fine, and the frame rate stays trashed after the offending object is destroyed.

Comments?
-Art

[icuurd12b42]

If not in view, do not create the effect is the only way to limit particles using those functions, existing particle off screen would still take process time.

You dont need to worry about leaks using those simplified methods, but yes, if GM7 and 8 is fine, you should probably log a bug for 8.1 or html5, those functions should not leak but from what you describe, it is possible they got broken.

http://bugs.yoyogames.com

[DanRedux]

They do leak. There's a game on the WIP forum which has built-in particles, and about 10 minutes of playing results in so many of those effects having been USED in the past that it lags, even though there's nothing actually happening on-screen. They seem to be destroyed upon room changes.

[Aethelwulffe]

I just verified the destruction on a room change.
It does not seem to be ALL the built-in effects. I will test others.

I reduced the tested number of the effects going off, and got a proportional change in the step rate/fps.

Edited by Aethelwulffe, 10 January 2012 - 06:06 AM.

[Aethelwulffe]

This issue still seems to be extant.
effect_create_below(ef_spark,other.x,other.y,3,c_red);} by itself will create it. just running it for a few cycles creates lag, and switching rooms, or even shutting down and re-launching does not actually help. I logged a bug report, but no fix as yet.
Clearing windows memory manually DOES fix it in between runs....definitely a memory leak issue from my POV.