Is their a piece of code that can remove everything off the screen? Or should I just do it one by one?
At 11/9/14 04:15 PM, GrahamNG wrote: Is their a piece of code that can remove everything off the screen? Or should I just do it one by one?
removeAllChildren() from the main class, but you'll have memory leaks if you don't take care to remove references to all the objects you will remove: http://stackoverflow.com/questions/14727194/manage-resources-to-minimize-garbage-collection-activity-and-improve-performance
I can' think of a good reason to do this. :/
At 11/9/14 08:51 PM, MintPaw wrote: I can' think of a good reason to do this. :/
How about wiping the screen at, say, the end of a level, so that all children are removed and the next level's children are loaded?
Slint approves of me! | "This is Newgrounds.com, not Disney.com" - WadeFulp
"Sit look rub panda" - Alan Davies
At 11/9/14 09:10 PM, Gimmick wrote:At 11/9/14 08:51 PM, MintPaw wrote: I can' think of a good reason to do this. :/How about wiping the screen at, say, the end of a level, so that all children are removed and the next level's children are loaded?
They just put them all in one MC to delete, if you remove absolutely everything you pretty much have to start from scratch. I see it being useful for memory reasons, but it's still pretty hacky.
If you really need to do it, just use recursion on the children:
private function removeDescendants(p:Sprite):void
{
while(p.numChildren > 0)
{
removeDescendants(p.getChildAt(0) as Sprite);
p.removeChildAt(0);
}
}At 11/9/14 09:26 PM, Sam wrote: If you really need to do it, just use recursion on the children:
private function removeDescendants(p:Sprite):void
{
while(p.numChildren > 0)
{
removeDescendants(p.getChildAt(0) as Sprite);
p.removeChildAt(0);
}
}
The name of the function is removeChildren, I said something else earlier. It does this or something similar.
It's a function in fp >11, so if you don't see it you aren't compiling to a more recent version.
At 11/9/14 09:36 PM, MSGhero wrote: The name of the function is removeChildren, I said something else earlier. It does this or something similar.
It's a function in fp >11, so if you don't see it you aren't compiling to a more recent version.
I've used it before, but assumed it didn't remove all descendants.
At 11/9/14 09:42 PM, Sam wrote:At 11/9/14 09:36 PM, MSGhero wrote: The name of the function is removeChildren, I said something else earlier. It does this or something similar.I've used it before, but assumed it didn't remove all descendants.
It's a function in fp >11, so if you don't see it you aren't compiling to a more recent version.
Yeah, I don't think it would remove all of each child's children.
At 11/9/14 10:48 PM, MintPaw wrote: Yeah, I don't think it would remove all of each child's children.
Do they still "exist" in the display list? I've never really thought about it because I'm quite meticulous when it comes to adding/removing display objects.
Even if not, the GC would do its rounds after you remove the parent. I just think it's better to be thorough than rely on the GC.
At 11/9/14 11:05 PM, Sam wrote:At 11/9/14 10:48 PM, MintPaw wrote: Yeah, I don't think it would remove all of each child's children.Do they still "exist" in the display list? I've never really thought about it because I'm quite meticulous when it comes to adding/removing display objects.
Even if not, the GC would do its rounds after you remove the parent. I just think it's better to be thorough than rely on the GC.
No, they wouldn't be on the main display list but on each child's display list, which were removed. So no.
Yeah, GC would remove the island data, as long as it's not too large.
At 11/9/14 11:07 PM, MintPaw wrote:At 11/9/14 11:05 PM, Sam wrote:No, they wouldn't be on the main display list but on each child's display list, which were removed. So no.At 11/9/14 10:48 PM, MintPaw wrote: Yeah, I don't think it would remove all of each child's children.Do they still "exist" in the display list? I've never really thought about it because I'm quite meticulous when it comes to adding/removing display objects.
Even if not, the GC would do its rounds after you remove the parent. I just think it's better to be thorough than rely on the GC.
Yeah, GC would remove the island data, as long as it's not too large.
The simple fact is that you cant completely rely on a black box like Flash Garbage Collector to take care of something like removing a large display list island. I had major memory leaks with games in the past, and the solution was to recursively remove all display list pointers from the level I was removing. Everything ran perfectly after doing this. I would highly recommend it.
Question: Would recursion increase the odds of the GC running?
Slint approves of me! | "This is Newgrounds.com, not Disney.com" - WadeFulp
"Sit look rub panda" - Alan Davies
At 11/10/14 12:50 PM, 23450 wrote: The simple fact is that you cant completely rely on a black box like Flash Garbage Collector to take care of something like removing a large display list island. I had major memory leaks with games in the past, and the solution was to recursively remove all display list pointers from the level I was removing. Everything ran perfectly after doing this. I would highly recommend it.
Yes definitely, I've lost thousands of dollars do to memory leaks due to relying on GC removing islands. Never again.
At 11/10/14 12:58 PM, Gimmick wrote: Question: Would recursion increase the odds of the GC running?
Blitting and callbacks are probably the best way, if not a bit extensive. Only create one Bitmap and draw pixels to it. For Events have one listener for each event and just pass them into the game.
Because of this there will be no DisplayObjects or Events to clean up, only simple data types.
I've ended up just using a for loop that keeps removing objects until there isn't any left :/
At 11/11/14 03:20 PM, GrahamNG wrote: I've ended up just using a for loop that keeps removing objects until there isn't any left :/
Only on the main timeline? Or within each object?
Is there a way to removeAllEventListeners ?
At 11/14/14 09:13 AM, Aprime wrote: Is there a way to removeAllEventListeners ?
If you are worried about garbage collection on event listeners, there is an additional parameter that should help.
public function addEventListener(type:String, listener:Function, useCapture:Boolean = false, priority:int = 0, useWeakReference:Boolean = false):void
We are looking at useWeakReference here. Its default value is false, but you can set it to true to allow it to be garbage collected. The definition from documentation is:
useWeakReference:Boolean (default = false) — Determines whether the reference to the listener is strong or weak. A strong reference (the default) prevents your listener from being garbage-collected. A weak reference does not.
At 11/14/14 09:13 AM, Aprime wrote: Is there a way to removeAllEventListeners ?
Yes, but this is again a bad practice. You need to learn to manage memory properly rather that just attempting to run a function every once and a while and expecting everything to be fine.
If there is too much garbage or a particular piece is too large, then Flash will give up on freeing memory.
