[iOS/Safari] [DEMO] Choppy movement with simple "body.velocity.y"

[imshag]

Soooo, i can't figure this one out.

 

Before deciding to go with Phaser as my framework, i  tested all possible examples/samples/pixi examples/community projects within all possible browsers, mobile included.

There were NO problems, espacially not with choppy movements of sprites.

 

After coding a simple prototype for my game idea, it hit me hard when i realized that sprite movement was choppy all of a sudden (ios/safari).

The implementation is a super basic "load some sprites, add to game, and move them with body.velocity.y".

 

This is a major concern of mine, since i am planning to release on mobile platforms as well.

 

Here is a live demo:

DEMO

 

Is this related to body.velocity.y? Is it a known bug? Is my implementation flawed?

 

I would appreciate any clarification.

I am using Phaser 1.1.4.

 

Edit:

+ Code

Just for clarification, i am setting the velocity once. No inputs are made.

'use strict';var game = new Phaser.Game(800, 800, Phaser.WEB_GL, 'gameWindow', {  preload: preload,  create: create,  update: update,  render: render});var debugOn = false;var wallLeft;var scrollSpeed = 200;var wallPieceWidth = 144;var wallPieceRealHeight = 174;var wallPieceHeight = 194;var bg;var randomFrameNumber;function preload() {  game.load.spritesheet('wall', 'assets/wall_sprite.png', 144, 194);  game.load.image('background', 'assets/background.jpg');  game.load.bitmapFont('desyrel', 'assets/fonts/desyrel.png', 'assets/fonts/desyrel.xml');};function create() {  // basics  // world  game.stage.scale.maxWidth = 800;  game.stage.scale.maxHeight = 800;  game.stage.scaleMode = Phaser.StageScaleMode.SHOW_ALL;  game.world.setBounds(0, 0, 0, game.world.height * 2);  // bg  bg = game.add.sprite(0, 0, 'background');  wallLeft = game.add.group();  for (var i = 0; i < 25; i++) {    if (Math.floor((Math.random() * 3)) % 3) {      randomFrameNumber = Math.floor((Math.random() * 3));    }    var wallPiece = wallLeft.create(0, game.world.height - (i * wallPieceRealHeight), 'wall', randomFrameNumber);    wallPiece.body.immovable = true;    wallPiece.body.setRectangle(wallPieceWidth * 2 / 3, wallPieceRealHeight - 20, 0, wallPieceHeight - wallPieceRealHeight + 5);  }  wallLeft.x = 0;  wallLeft.setAll('body.velocity.y', scrollSpeed);};function update() {  updateWallPosition();};function updateWallPosition() {  wallLeft.forEach(function (piece) {    if (piece.y > game.height && piece.inCamera === false) {      moveWallPieceToTop(piece, 'left');    }  }, this);}function moveWallPieceToTop(piece, wallType) {  // get last wall piece, counting from top it's the last to be displayed  var lastPiece;  if (wallType === 'left') {    lastPiece = wallLeft.getAt(wallLeft.length - 1);  }  piece.y = (lastPiece.y | 0) - wallPieceRealHeight;  piece.bringToTop();}function render() {}

[Heppell08]

Probably best if you throw some code on here. It could be something in the update of how you're making the sprite moved. Example can be of a justPressed(); or isDown; because justPressed fires a one time shot so you need multiple presses to move. But onDown is if the button is down and will move the player at a constant rate when down. Might be that or could be something totally different but throw some code here and a better answer will come out.

[imshag]

No inputs are processed.

 

@edit

Now with code example.

[Heppell08]

Your image for the wall doesn't need to be a spritesheet. It just needs to be an image without height and width declared to it as you don't have animations. That is all I see that is unnecessary and maybe the problem. Just add the wall as:

game.load.image('wall', 'assets/wall_sprite.png');

[imshag]

@Heppell08

Thanks for the suggestion.

Unfortunately it still stays the same, maybe even worse.

[Heppell08]

wallLeft.setAll('body.velocity.y', scrollSpeed);

Try changing that to:

WallPiece.body.velocity.y = scrollSpeed;

[Heppell08]

Set the velocity of the wallpiece itself within the group. So each of them in the group is already told the velocity instead of setting the group velocity. So remove:

wallLeft.setAll('body.velocity.y', scrollSpeed);

And set the wallPiece with:

wallPiece.body.velocity.y = scrollSpeed;

Might be worth a shot.

[imshag]

@Heppell08

Meh, did the change. No effect But thanks!

 

I test the latest pixi.js version in safari/ios-safari by simply loading a sprite and moving it with body.velocity.

The result: same effect, it has "choppy" movement.

 

Maybe it's pixi.js related? But then again, why do other games show no such side effects?

[Heppell08]

I have no idea. I know physics is getting a revamp in 1.2 so might be worth testing it but I don't know why some show smoother rates than others. Maybe someone with a bit more knowledge may know and reply to this post but tbh I really don't see an issue in the code myself. GL with it though

[Blinzy]

Still no fix for this. We have been discarded Phaser for mobile games due this bug. We believe Phaser is quite promising but this is a major issue.... we had to rebuild from scratch 2 minigames because of choppy movement. Working great just with Pixi.

[rich]

This is an old thread, but even so it highlights some glaring assumptions.

 

The demo game in question (above) was using a game size of:

 

var width = window.innerWidth * window.devicePixelRatio;
var height = window.innerHeight * window.devicePixelRatio;

 

This is an insane size to use on a mobile device. You'd be lucky to scroll anything smoothly on a resolution like that.

 

Also using the stats.js component actively slows down mobile browsers as well. Really only use it on desktops.

 

 

Still no fix for this. We have been discarded Phaser for mobile games due this bug. We believe Phaser is quite promising but this is a major issue.... we had to rebuild from scratch 2 minigames because of choppy movement. Working great just with Pixi.

 

There's "no fix" because there's nothing to actually fix. Phaser 2 adds next to no overhead onto what Pixi is already doing (unlike 1.x which was used above, which added a lot). If you're working directly with just Pixi then you added in your own physics, collision and motion handlers, yes? If not then it's not a comparison.