Upgrading from phaser 2.3 to 2.4.3 makes my animation very jittery. It runs perfectly on 2.3

[kriket]

I made my entire game in Phaser 2.3 and now whilst upgrading to 2.4.3 (mainly for performance and optimizations reasons as I don't really need 2.4 but likely a few bugs were fixed and performance increased), my animation becomes very jittery. 

 

Here's the spritesheet animation code:

 

In preload.js

    this.load.spritesheet('shiny_effect', 'assets/images/shiny_effect.png', 128, 128);

In create() in game.js

    this.shiny_effect = this.game.add.sprite(0, this.game.height*2, 'shiny_effect');    this.shiny_effect.anchor.setTo(0.4, 0.25);    this.shiny_effect.animations.add('shiny_effect_anim');

Called in a gameOver function:

    gameOver: function() {        this.player.kill();        this.shiny_effect.anchor.setTo(0.4, 0.4);        this.shiny_effect.scale.set(4);        this.shiny_effect.tint = 0xFF0000;        this.shiny_effect.position.x = this.game.width/2;        this.shiny_effect.position.y = this.game.height/2;        this.shiny_effect.animations.play('shiny_effect_anim', 32, false);                this.sound.play('Fail');        this.game.time.events.add(Phaser.Timer.SECOND * 3, this.restart, this);    },

 

 

 

Again, its looking awesome on phaser 2.3

 

Any suggestions. I need to make more levels/games for this huge game and would rather move over to phaser 2.4 now than having to do that again for other levels and games.

[icp]

I also got issues with 2.4( every version), while everything works smooth with 2.3 . I choose to keep it since there are no major improvements with 2.4 .

[Tilde]

I have a problem where, depending on the current frame rate (apparently), an animation might not move to its final frame, instead hanging on the previous frame. Dunno if that's related.

[richpixel]

Just wanted to chime in - I tried my game today with 2.4.3 after previously having run on 2.2.2 - the animations are slow and choppy on mobile devices now, where before they were nice and smooth.

 

Tilde, I also had the 'final frame' animation issue, which happens sometimes when the fps drops. I fixed it with this patch code to make sure _frameIndex is set to the last frame in all cases:

    // EXTEND complete on Phaser.Animation to set _frameIndex to _frames.length-1        /**    * Called internally when the animation finishes playback.    * Sets the isPlaying and isFinished states and dispatches the onAnimationComplete event if it exists on the parent and local onComplete event.    *    * @method Phaser.Animation#complete    */    Phaser.Animation.prototype.complete = function () {        this.isPlaying = false;        this.isFinished = true;        this.paused = false;        this._parent.events.onAnimationComplete$dispatch(this._parent, this);        // RCL fix - animation doesn't stop on last frame if frames are skipped due to low fps        this._frameIndex = this._frames.length-1;        ////        this.onComplete.dispatch(this._parent, this);        if (this.killOnComplete)        {            this._parent.kill();        }    }    

[Tom Atom]

Hi, I noticed, that DisplayObject.updateTransform changed from:

    // multiply the alphas..    this.worldAlpha = this.alpha * this.parent.worldAlpha;    //  Custom callback?    if (this.transformCallback)    {        this.transformCallback.call(this.transformCallbackContext, wt, pt);    }

to:

    // multiply the alphas..    this.worldAlpha = this.alpha * p.worldAlpha;    this.worldPosition.set(wt.tx, wt.ty);    this.worldScale.set(Math.sqrt(wt.a * wt.a + wt.b * wt., Math.sqrt(wt.c * wt.c + wt.d * wt.d));    this.worldRotation = Math.atan2(-wt.c, wt.d);    // reset the bounds each time this is called!    this._currentBounds = null;    //  Custom callback?    if (this.transformCallback)    {        this.transformCallback.call(this.transformCallbackContext, wt, pt);    }

2 sqrts and 1 atan2 on every DisplayObject on every frame! I do not believe, that today computers/mobiles are already so powerful to do this. Try to comment it to see if it improves performance.

[richpixel]

Is there any news on this issue? I guess for now I will also stay with 2.3

[jmp909]

Hi richpixel/Tom Atom

 

have you raised these at the github repository? they seem fundamental enough problems to warrant being an 'issue'

 

if these sort of performance killing maths calculations are included, it would seem that they should be in some way optional (or conditional on a property of the object). 

 

J.

[Tom Atom]

@jmp909: I did not rise any request. For me, I just commented it out in my last game. I am not sure, whether it is source of jittering others are experiencing, but after commenting I saved some time according to profiler stats.

 

I was not using those world vars. But if I needed them, I would change their calculation from on every frame to some "dirty" mode and calculate them on first user read request.

[qdrj]

@Tom Atom - good observation regarding DisplayObject.updateTransform

So you just comment out this section without any further bugs?

[Tom Atom]

@qdrj - yes. It is new feature of 2.4 - see change log:

 

• PIXI.DisplayObject.worldPosition contains the position of the DisplayObject (and therefore any object that inherits from it, such as Phaser.Sprite) taking into account all transforms in the display list. It is updated at the end of DisplayObject.updateTransform. DisplayObject.position reflects only the position applied to the object directly, whereas worldPosition includes the positions that may have been applied to its ancestors.
• PIXI.DisplayObject.worldScale contains the scale of the DisplayObject (and therefore any object that inherits from it, such as Phaser.Sprite) taking into account all transforms in the display list. It is updated at the end of DisplayObject.updateTransform. DisplayObject.scale reflects only the scale applied to the object directly, whereas worldScale includes any scales that may have been applied to its ancestors.
• PIXI.DisplayObject.worldRotation contains the rotation of the DisplayObject (and therefore any object that inherits from it, such as Phaser.Sprite) taking into account all transforms in the display list. It is updated at the end of DisplayObject.updateTransform. DisplayObject.rotation reflects only the rotation applied to the object directly, whereas worldRotation includes any rotations that may have been applied to its ancestors.

 

 

 But quite expensive, I think. So, as I did not needed it I commented it out. I think, that these variables are mainly for your usage. Only place in engine where I found its internal usage is in BitmapData.drawFull method.

[jmp909]

i still think it's worth bringing up.. if additions like these are expensive, should they not be part of eg a more specialised object? (AdvancedSprite vs Sprite.. well.. whatever) or at least an optional conditional property as mentioned, so the code can just be skipped over internally

[Skeptron]

@jmp909 agreed. Everyone is backing off 2.4 because of these performances issues

[Skeptron]

Any update on this? 

[jouniii]

I suspect the issue is with the timer changes where animation time is kept constant and causes frame skipping if fps cannot be held constant. You can try fix it with setting lower target fps, but note that your animations will then run multiples faster and you need to adjust. 

 

Another option (which I chose) is to force tweens/animations back to old style timing which does not skip, but just slows down the animation thus it looks smooth although slower. Note the down side is that Timer based events are run then in different cycle and animations may not synchronize with timers. I think this was the main reason for the change. ie. you say play tween for 2000ms and have timer event for 2000ms - new way makes sure these are executed with same real time period. Old way allows the tween to drift.

 

For tweens it is just setting it's frameBased property (not sure if there was default in tween manager to be set), but I had wrapper for tweens so it was just adding single line there after creating a tween. Don't remember off the shelf if there was something similar with sprite animations.

[ritherz]

I suspect the issue is with the timer changes where animation time is kept constant and causes frame skipping if fps cannot be held constant. You can try fix it with setting lower target fps, but note that your animations will then run multiples faster and you need to adjust. 

 

I've noticed my game is terribly slow on older devices, next to unplayable.  It's a turn-based game, so skipping frames isn't much of an issue, however I hesitate upgrading to 2.4 due to the jittery animation problem.

 

Do you have any further insight as to the timer changes?

[richpixel]

Tried out 2.4.4 and still see slowish animation on my iPad 3 (ios 8) and iPhone 5c (ios 8)

 

I originally developed the game with v2.2.2, which always ran smooth, so I'll have to stick with it for now.

 

Perhaps enhancements were made that were not back-tested on older devices/iOS. I'm guessing there are no issues on the newer devices or this would be seeing more of an outcry.

 

Also should note that the DisplayObject.updateTransform() change (to comment out the code) suggested by Tom Atom did not help my situation in which I have multiple sprites running animations sequences at the same time.

 

That code is actually in the PIXI codebase which is separate from Phaser.

[Tilde]

 

Tilde, I also had the 'final frame' animation issue, which happens sometimes when the fps drops. I fixed it with this patch code to make sure _frameIndex is set to the last frame in all cases:

 

I'm currently using forceSingleUpdate to tackle this and other problems(and keep my entire game frame-based), but thanks! I'll keep this in mind since I want to compare and contrast with a time-based system.