Does overwriting the variable the sprite is assigned to delete it?

[Legomite]

I know the method sprite.destroy(), but it seems a bit tedious for me. I have to delete around 1 - 128 sprites and doing a for() seems to be performance draining.

 

Can I just overwrite the variable? Like if the sprite was "sprite1" and I did 

 

sprite1 = undefined

 

would that work?

[mattstyles]

I can't actually answer your question but my guess would be no. The problem is garbage collection. If the sprite object creates some listeners (or there are some other conditions) then even though there is no reference to it the GC still can not be sure it is not used somewhere, so will not collect it, hence you have a potential memory leak by not cleaning up properly.

[nkholski]

No, that won't work. That will only make the sprite1 variable refer to undefined instead of the sprite object, and the sprite object will be alive.

What you probably want is to pool your sprites. Repeatedly destroying and creating high number of objects will hit performance as the automatic garbage collector will be busy tiding up after you.

There is a lot of information on the issue. I wrote a blog post here: http://metroid.niklasberg.se/2016/02/29/making-a-custom-pool-class-by-extending-phaser-group
The weapons plugin didn't exist at the time of the blog post. If it's bullet-type sprites you're destroying than I think that's your best choice.

[samme]

If you have a Group you can do

group.removeAll(true)

instead of looping through them all.

9 hours ago, Legomite said:

Can I just overwrite the variable?

Someone described JS variables as more like "tentacles" than "containers": when you assign to it, it grasps one value; when you reassign to it, it grasps another value.

When you do

var sprite = game.add.sprite(/*…*/);

sprite = undefined;

the sprite still exists (particularly in `game.world.children[*]` somewhere), but you've lost a reference to it through the `sprite` variable.

destroy() doesn't actually destroy anything, but it breaks all the links on the object, which lets it eventually pass into oblivion.

[mattstyles]

You can try to delete a variable, but that can be even more misleading in JS land

[mwissink]

Why do you need to delete so many sprites? If you can, I would try to reuse them instead by implementing object pooling. 

[ldd]

var obj = {a:1};
var arr = [obj, {b:1}, {c:1}];
arr = arr.map( t => {t=undefined});

//Let's see arr and obj 
arr
//[undefined, undefined, undefined]
obj
// Object {a:1}

That is why people are telling you that unless you know what you are doing, you shouldn't go ahead and 'delete' stuff. 

Using

delete t

above won't help you either. obj will still be {a: 1}.

In my personal case, I use

    addNPCEntity() {
        return this.getFirstDead(true, 0, 0/*, stuff */);
    }
    removeNPCEntity(entity) {
        entity.kill();
    }
    resetChild(entity, x, y) {
        entity.reset(x, y);
        //other operations go here...
        return entity;
    }

 

in conjunction with Group.classType to easily add and remove stuff from a Group. As others mentioned, use Groups, Group.removeAll and read the documentation, it's there and it's very accessible code

[mattstyles]

1 hour ago, ldd said:

Using

delete t

above won't help you either. obj will still be {a: 1}.

I think thats a neat, concise example. The above wouldn't confuse me though, maybe its my programming background but I'd expect that to delete the pointer (used for pass by ref) rather than the actual data.

The actual problem with 'deleting' stuff in JS isn't situations like you describe (or shouldnt be), its the use of a garbage collector (GC) that can be potentially confusing i.e. you never free memory manually, you just try to flag it as available for freeing, and there are lots of things that can screw with that flag so you think you're flagging stuff for the GC to free but actually you're not.

For example, in your example, if that stuff is wrapped in a function then you lose reference to it as soon as the function scope closes and the GC will tidy it up when its ready, if you'd passed the object in then it wouldn't be flagged for deletion. Similarly, if you returned that array from the function (the array of undefined) the obj memory would soon be freed up because the ref to it is lost when the function ends, if you hadn't nuked your array list then it couldn't be tidied up, if you've nuked the list later, it would be. A potential source of confusion maybe, but logical.

MDN has some nice info about ref-counting and GC, plus some good links if anyone is feeling particularly interested.