Phaser 2.4.2 easing updates?

[tips4design]

Were there any updates to Tweens or Easing between 2.3.0 and 2.4.2?

 

With 2.3.0, my animations are smooth and play as intented. On 2.4.2 they end much quicker, are much snappier and the easing effect is not really visible. So, in 2.3.0 the tween animation looks nicer, in 2.4.2 seems jaggy/snappy.

[rich]

Tweens or Animations?

 

Tweens were updated to use a real system timer, rather than a fixed timestep. Which means a 2 second tween will last exactly 2 seconds and not a bit more, where-as in 2.3 if the system lagged it could potentially last much longer than 2 seconds.

[tips4design]

Tweens or Animations?

 

Tweens were updated to use a real system timer, rather than a fixed timestep. Which means a 2 second tween will last exactly 2 seconds and not a bit more, where-as in 2.3 if the system lagged it could potentially last much longer than 2 seconds.

 

Tweens.

 

Well, that could explain why they end much faster, I will try to change the time of the Tweens and see if I can achieve the same effect as I did with 2.3.

 

Thanks!

 

LE: Increasing the time of the tween a bit will lead to the tween being as fast as in 2.3, but it still seems not to be as fluid as it was in 2.4.2, small shutters happen.

[tips4design]

When I update to 2.4.2 things go crazy in IE11. Frames drop from 40+ to <10. Tweens complete instantly (jump to the end, I think this is caused by the low fps).

 

And there seems a problem with .pointerOver() in IE11. I have a close button, when I click it I hide the button, but the closeButton.pointerOver() function always returns true after that, even if my mouse is not over the button, the button has 0 alpha and visible = false. 

[rich]

2.4.2 made no changes to anything that would effect IE11 specifically. Or indeed to anything timing or render related. It was purely a pointer event fix and some cache tweaks.

[tips4design]

2.4.2 made no changes to anything that would effect IE11 specifically. Or indeed to anything timing or render related. It was purely a pointer event fix and some cache tweaks.

Yes, this bug also happens on Chrome, I have added a ticket on github: https://github.com/photonstorm/phaser/issues/1955

[rich]

This works fine in IE11 / Chrome / FF for me:

var game = new Phaser.Game(800, 600, Phaser.CANVAS, 'phaser-example', { preload: preload, create: create, update: update });function preload() {    game.load.image('bunny', 'assets/sprites/bunny.png');}var bunny;function create() {    bunny = game.add.sprite(game.world.centerX, game.world.centerY, 'bunny');    bunny.alpha = 0.5;    bunny.anchor.set(0.5);    bunny.inputEnabled = true;    // bunny.input.pixelPerfectOver = true;}function update() {    if (bunny.input.pointerOver())    {        bunny.alpha = 1;    }    else    {        bunny.alpha = 0.5;    }}

[tips4design]

 

This works fine in IE11 / Chrome / FF for me:

See my post above: http://jsfiddle.net/5qzjjegt/4/

[tips4design]

I fixed it for now by checking like this:

if(sprite.visible && sprite.input.pointerOver())

But this way you won't get pointerOver if you hover over an invisible sprite.

[tips4design]

Now, regarding tweens, this is what I noticed:

 

For now, I will stick to version 2.3 for my current project, why? Because the new tweens look very ugly on low FPS. The old tweens would keep the sprites moving at a constant speed regarding the FPS. With 2.4.2 @60fps everything is smooth, but when it goes to @20fps the sprites move 3 times as fast and the animations look jaggy. With 2.3 @20fps the sprites would move the same as @60fps.

 

So, why I stick to v2.3 is because for my project I don't care for the sprites to move to a position in a certain time, I just want them to behave smoothly (think of stars moving slowly on the night sky).

 

I'm not really sure that this is something that should be fixed, or that is not working as expected, but I just wanted to point this out: tweens look better on v2.3 than on v2.4 when it comes to low fps.

[rich]

I fixed it for now by checking like this:

if(sprite.visible && sprite.input.pointerOver())

But this way you won't get pointerOver if you hover over an invisible sprite.

 

You never would have anyway - pointerOver checks the sprite.visible as the first thing and returns false - it's always been like this. See my comment on github re: the rest of it.

 

As for the tweens they are time based not frame based, all duration values given to them are in ms, not frames. If you say "This tween should last 2000ms" then it should last exactly 2000ms regardless of what the frame rate is. It shouldn't suddenly last 3000ms on a slow computer, as that isn't a time based tween at all and leads to deeper problems.

 

What is needed is the ability to tell the Tween system to use times or frames, which is a whole other level of feature request, but worth doing eventually.

[tips4design]

I think a fix for this could be something like instead of using 2000ms for a tween, to call the tween with 2000 * 60/FPS. This way, at 30FPS the sprite should move as smooth as it does at 60fps. Did not really think much about this (as I stuck with 2.3 for now) but seems like a quick option to maintain the animations smoothness. (assuming fps is ~constant during the animation, which in most cases it should be)

[rich]

https://github.com/photonstorm/phaser/commit/fc83dc6bdf10a0a7d9ce6402019f34020052dffe

[rich]

The problem with that approach is that the frame rate is rarely consistent. Using a time based approach does interpolate the position of the tween accurately, based on the time that has elapsed. If the machine was butt slow and ran at 4fps then it's correct that in a 1000ms duration tween you'd only see the object move 4 times in very large jerky steps, because that tween absolutely has to finish 1000ms later, no matter what happened inbetween.

[tips4design]

How do I go about using the frameBased property?

 

I tried something like this, but it still doesn't work as intended (ends faster at low fps):

 

        this.scaleTween = game.add.tween(this.lastBlock.sprite)                                  .to({height: Block.maxHeight, width: Block.maxHeight}, Block.scaleTime, Phaser.Easing.Quadratic.Out)                                  .to({height: Block.minHeight, width: Block.minHeight}, Block.scaleTime, Phaser.Easing.Quadratic.Out)                                  .delay(200, 1);        this.scaleTween.frameBased = true;        this.scaleTween.start();

[rich]

That's exactly what frameBased should do: match the frame rate of the device. So on faster systems it'll end quicker than on slower ones, because the rate of update is linked to the frame rate, not the clock. The duration given is the quantity of frames the tween should run for.

 

Technically it's possible to revert back to the old / inaccurate delta timer code from before (i.e. from like Phaser 2.0) as it'd just need the Time.update method overwritten, but the repercussions elsewhere would be pretty deep. I'll have a think about how to handle it.

[tips4design]

I got it to work, I was using the dev build version, but this was not included in the latest build (had to build it myself or copy/paste the code) for it.

 

I mean, it works as expected, the tween is FPS-dependent. The problem with the new tweens is that they (almost always) end quicker than expected as the FPS might drop exactly when the tween is playing (because it adds extra processing). I ended up using frame based tweens for scaling/moving objects and time based tweens for UI (eg: animate the score when +1 is added or moving coins to the top corner, as an "coin received" animation)

 

Thanks!