Jump to content

Why does sprite.kill() not halt the update loop?


JTronLabs
 Share

Recommended Posts

Add a console function to a sprite's update. kill the sprite. The console will be logged indefinitely. Why was this design decision made? I doubt it's a bug, as it seems like a really basic behavior, but sprite pooling is a super common paradigm and needlessly running the update loop seems wasteful.

http://phaser.io/sandbox/edit/htyDEbYq

(note for the sandbox, you have to click on the game in the 'play' tab for the game to have focus & do the logging)

Link to comment
Share on other sites

I asked this to Rick some time ago, specifically why is it that setting exists to false (which kill() also does) won't stop the update method.

This was his answer:

Quote

`exists` bails out of `preUpdate`, but `update` will still be called because it’s entirely empty, there just for >over-riding, so you can set it to ignore if exists is false as needed

 

Link to comment
Share on other sites

@tips4design  I lold at the zombie comment. @rgk I think destroying would be really inefficient, and make it hard to pool as it auto-removes the sprite from its Group.

 

@darkraziel are you suggesting overriding/editing the base Phaser engine to achieve this behavior? Currently I am including `if(!this.alive) return;` at the beginning of every one of my game loops, but it's messy code and I am not a fan. Over-ridding the base engine would be a lot cleaner, but would require manual, annoying setup after downloading/pulling from an NPM package. Do you have a link to Rich's original answer?

Link to comment
Share on other sites

3 minutes ago, JTronLabs said:

@tips4design  I lold at the zombie comment. @rgk I think destroying would be really inefficient, and make it hard to pool as it auto-removes the sprite from its Group.

 

@darkraziel are you suggesting overriding/editing the base Phaser engine to achieve this behavior? Currently I am including `if(!this.alive) return;` at the beginning of every one of my game loops, but it's messy code and I am not a fan. Over-ridding the base engine would be a lot cleaner, but would require manual, annoying setup after downloading/pulling from an NPM package. Do you have a link to Rick's original answer?

The update method itself is empty and meant to be overriden, either by assigning a function to the sprite update (like in your example) or by extending the Sprite class for personal use. So if you ever add override the update method you can then set it to return if exists, alive or visible is false, depending on what you need.

Link to comment
Share on other sites

Ah ok yes that is what I am doing currently. It's a bit annoying when I have a long inheritance chain, as each parent & child needs to have this check at the beginning of their update loop. Works, but makes the code a bit messy. It would be nice if the update signal for sprites/groups/text/displayObjects would only ever be triggered if they were alive. That way it not have to call the function or check alive/exists conditional. I posted about this issue here for Rich to take a look at https://github.com/photonstorm/phaser/issues/2776

Link to comment
Share on other sites

On 9/29/2016 at 0:12 PM, darkraziel said:

Over-ridding the base engine would be a lot cleaner, but would require manual, annoying setup after downloading/pulling from an NPM package.

You can just include after Phaser:

Phaser.Group.prototype.update = function() {
  var child, i;
  i = this.children.length;
  while (i--) {
    child = this.children[i];
    if (child.exists) {
      child.update();
    }
  }
};

 

Link to comment
Share on other sites

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...