Using Sprite velocity makes things "choppy"

[Pert]

Here's something I came across while trying to prototype something late last night. Phaser version should be 1.1.3

When I use sprite.velocity.x = -100 the animation seems visibly "choppy", even on my PC and there's nothing else going on like physics calculations or collision checks, tab uses 22% processing power according to Chrome tab. App was running between 45-60FPS.

It came as a bit of a surprise, because week before I used particle effect with more particles and compiled with CocoonJS to run on Nexus 7 and it was very smooth.

Haven't had time to check few theories, but could it be because sprite location get's rounded up or down to a hard pixel position, and that creates illusion of frame rate issues?

I had a look this morning on official example, and moving image one to me seemed to have same issue where the movement does not seem completely smooth.

Anyone else noticed this?

[Pixelguy]

You should use:

 

sprite.body.velocity.x = -100

 

[Pert]

Yeah, I didn't have the source code at hand and I didn't remember while writing OP if it was .body or just sprite. One way or another, it works, but is choppy.

[rich]

Values aren't rounded anywhere, so I'm not really sure what the cause is. I have noticed it intermittently in only Chrome (the latest version with the borked scrollbars bug) but haven't had time to dig any deeper, it seems massively inconsistent - like sometimes it can start-up and run happily with no frame drop, and sometimes it gets stuck in some kind of 'stutter' mode which can eventually catch up with itself and normal out. To be honest I'm going to have to leave this is a known anomaly for now as once I finally release 1.1.4 I can finally rip it all down internally and rebuild to upgrade to the latest Pixi, which I feel may solve a number of issues in one sweep.

 

Even so, if you do dig deeper and find a cause, let me know!

[Pert]

Interesting, will have a dig around then. Should I do it on 1.1.3 or 1.1.4?

 

Never tried it on anything else, but I guess Cocoon must use Chrome engine then, because they have very similar behaviour.

Annoying, because other things like particles animate beautifully!

Will have a dig around tonight.

[rich]

I'm seeing the same across 1.1.3 and 1.1.4 and the systems used to move sprites are almost totally different between them, which means it must be related to something else (I'm suspecting some timer / raf related).

[Pert]

I wonder if the key here is particles usually don't move in straight line and rotate as well, or maybe I just tried to look too hard on the diamonds and now I notice slight "choppiness" on Diamond Burst example too . . . it's going to be a loooooong night

[rich]

If I was going to tackle this I would disable as many internal sub-systems as possible first. So remove input, sound, etc from the core game loop. I still reckon it is delta timer related at heart though

[Pert]

So, I did a quick test with using delta in update to add my own quick velocity calculations.

Delta was all over the place, but seemed to do a sine - up and down all the time.

In the end I dug out my Eclipse and updated Android SDK and libGDX, and got smooth result with just using pos += delta * velocity quite easily (I say easily, it took me 2-3 hours to figure out all the new configuration Eclipse needed to get things compiled).

So, unfortunately I'll be doing things native just to avoid headache with optimising performance - hopefully when we get to do a small limited public web demo teaser, someone else has tackled this issue head on

[pandavigoureux29]

Hi, 

 

I'm having the same problem here ! ( well I guess so, as I don't really know what "choppy" could mean -- french, sorry )

 

I've an actual framerate of ~60 fps but my sprites are moving in a twitchy way.

 

This really bugs me as I want to deploy a quick version of my game soon.

 

Are you saying making your own velocity update (with time.elapsed I guess?) worked for you? 

You had me confused talking about libgdx and eclipse ^^

 

Thanks

[pandavigoureux29]

Hi,

 

I tried to make it move in the update(), like this :

this.x += speed * game.time.elapsed;

 

but it did no good

 

So this doesn't seem to be body related, from what I can assume.

 

Is this a known error? Will it be okay in version 1.2 ?

 

Thanks

[Pert]

Has this improved with new Phaser updates, does anyone know?

[defic]

old topic but i still experience this with Chrome. It only occurs when there is not much going on on my scene. In my game, if only 1 ball is bouncing, it looks like it is stuttering even though fps is solid 60. If I throw multple balls, stuttering stops and it is more fluid.

 

I also experienced this kind of behaviour with chrome's requestAnimationFrame on a simple canvas animation and I suspect that that is causing the stuttering here also. The effect is even worse with new phaser rc 2.2.0.

 

And btw I am using P2 physics also.

[rich]

Be aware that Chrome extensions can and will mess-up performance. I've swapped to doing all of my testing in Canary now with no extensions loaded at all, and the raf stuttering is gone completely. I believe you can get a similar result by using an incognito tab. I've yet to waste spend the time to work out which extension is causing me grief in my regular Chrome version.

[MishaShapo]

Been more than a year now. I have a simple game and I still get the random shuttering. I have just a couple of sprites with a velocity moving across the screen, resetting position, changing texture using loadTexture (http://phaser.io/docs/2.4.4/Phaser.Sprite.html#loadTexture ), and moving back across the screen.

 

Specs:

• Phaser v 2.4.4
• Pixi v2.2.9
• Canvas
• Testing in icognito window on Chrome 47 on a 1.8 GHz i5 MacBook

 

We'll see what happens when I package the game in CocoonJS, but I am thinking about libGDX too. It's about the same size project on GitHub. Shame though since Phaser is so simple, laughably easy to set-up (as apposed to libGDx and all the Gradle stuff), and I've invested time (and money) to learn it. I just hope that with Phaser 3 or 2.4.5 (whatever comes next) this will be fixed.

 

I know this isn't the dev's fault. Just a paradigm of JS that we all have to deal with. =)

[s-p-n]

Does the problem reproduce in every browser? Does the problem reproduce on canvas and WebGL rendering? Are you running any programs besides your web browser that could make your CPU struggle? So many things can cause this issue.. Try to make sure your GPU is rendering, and none of your CPU cores are near 100%. Is the FPS steady at 60? Can you post the simplest code possible that replicates this problem so we can try and figure out what's causing it and if it reproduces on other platforms?

[MishaShapo]

Hey, s-p-n 

 

I tested on Chrome 47 on Windows and it worked better. I read A LOT of posts in this forum, and so far I've concluded that the issue is with browsers on Mac OS X.

 

And to answer your questions:

 

• 1. Yes

In Chrome 47, it's the worst

In Canary, it's just as bad as Chrome 47.

In Safari 9.0 , the stuttering is still there but it is much less frequent

In Firefox 43, is much the same as Safari.

 

• 2. Yes, the stuttering is the same whether I used Canvas or WebGL with the same performance in each browser as listed above.
• 3. There are very few background programs running, and from Activity Monitor, I saw that my CPU load never went above 50%
• 4. My MacBook Air has Intel HD Graphics 4000 , so there is no standalone GPU. 
• Activity Monitor shows 0 Bytes of Swap Memory (Good) and that App memory is at 1.48 GB which means that there is about 1.5 GB left (Memory Used shows 3.15 GB). For an explanation on Mac OSX memory readings, check out: https://support.apple.com/kb/PH19644?locale=en_US
• 5.  FPS was 60 in all browser. I used a key listener that logged game.time.fps so as to not hurt/influence performance. 
• 6. I will post the smallest replicable code soon. 

 

In conclusion, I will just continue to work on features in my game and test on my Windows machine. I have yet to test my game on mobile, but hopefully CocoonJS can help with that.