Moving a sprite in 2.0 and 2.01

[Willyfrog]

I'm currently starting with phaser, so this might not be the best way to move a sprite. But it was working for me on 2.0 and now it doesn't so I'm not sure if I am doing things the wrong way or if it's a bug.

 

Given the following code: http://pastebin.com/2N4iAmTd

 

I get 2 different behaviours depending on using 2.0 or 2.0.1

this.bird.body.x

works for 2.0 and moves the sprite apropiately. This doesn't seem to work on 2.0.1 as the value changes but it is not updated on redraw

this.bird.x

 does not work for 2.0 (I'm not even sure it's valid) but in 2.0.1. is valid, but instead of moving the sprite to the new X position it just adds some x-velocity to it and keeps moving it.

 

So, what am I doing wrong? did I just found a bug?

 

Thanks for any tips/solution

[rich]

If the Sprite is using an ArcadePhysics body and you want to re-position it somewhere, other than by using forces, then in 2.0.1 you need to set sprite.body.x/y directly. This didn't work on 2.0.0 (in that version you would do sprite.x/y instead), but we regressed it back to a previous version due to various issues, and the way it is now is how it will remain.

[rich]

I'm writing a guide to Arcade Physics at the moment btw. Keep an eye out for it! Should be helpful for lots of people.

[Willyfrog]

I'm writing a guide to Arcade Physics at the moment btw. Keep an eye out for it! Should be helpful for lots of people.

Great, I'm reading through the docs but a guide is always helpful

 

If the Sprite is using an ArcadePhysics body and you want to re-position it somewhere, other than by using forces, then in 2.0.1 you need to set sprite.body.x/y directly. This didn't work on 2.0.0 (in that version you would do sprite.x/y instead), but we regressed it back to a previous version due to various issues, and the way it is now is how it will remain.

 

I tried using sprite.body.x/y but it seems to ignore it in 2.0.1 sorry if I wasn't clear about it previously. Just change the comments between both lines to see the different effects (spoiler: in 2.0.1 the value changes but the sprite remains in place )

[rich]

Here, this is the test case I used to show it working:

var game = new Phaser.Game(800, 600, Phaser.CANVAS, 'phaser-example', { preload: preload, create: create, update: update, render: render });function preload() {    game.load.image('atari', 'assets/sprites/atari130xe.png');    game.load.image('mushroom', 'assets/sprites/mushroom2.png');}var sprite1;var sprite2;function create() {    game.physics.startSystem(Phaser.Physics.ARCADE);    game.stage.backgroundColor = '#2d2d2d';    sprite1 = game.add.sprite(300, 50, 'atari');    sprite2 = game.add.sprite(400, 450, 'mushroom');    game.physics.arcade.enable([ sprite1, sprite2 ], Phaser.Physics.ARCADE);    game.add.tween(sprite1.body).to( { y: 400 }, 3000, Phaser.Easing.Linear.None, true);}function update() {    game.physics.arcade.overlap(sprite1, sprite2, overlapHandler, null, this);}function overlapHandler (obj1, obj2) {    game.stage.backgroundColor = '#992d2d';    obj2.kill();}function render() {    game.debug.body(sprite1);    game.debug.body(sprite2);}

You can just drop this into the examples folder and run it.

[Willyfrog]

thank you for the example!

I'll try it as soon as I get home from work 

[Willyfrog]

I've been looking a bit more into this.

 

Modifying sprite.body.x/y inside the update loop or within a teen animation does work. But if inside create I add this:

this.atari = sprite1; game.input.onDown.add(function () { this.atari.body.y = 380; }, this);

it doesn't work, I've added a debugger line to it, and I can change the value of x and y but on a second click is back to it's original value, like if I had created a variable shadowing another further in the scope, but the variable does exist prior to the function being declared.

 

I have also tried doing a that=this, just in case it was a problem of this being a different reference than I thought, but I've got the same results.

 

Any tips on where should I look in order to solve my little mystery?

[JP91]

maybe //create game.input.onDown.add(function(){this.any = true}, this);

//update

if (this.any){

sprite1.body.x = 100;

}

[Willyfrog]

maybe //create game.input.onDown.add(function(){this.any = true}, this); //update if (this.any){ sprite1.body.x = 100; }

 

that would be okay if the behaviour is a bug and needs to be addressed, but otherwise I wouldn't like to use it. Thanks anyway for your suggestion

[Lucas]

How make collision with layer of tiled map? Using this function of movement: this.bird.x

[Willyfrog]

As a workaround I'm currently tweening in a short time, since only during the update seems to work, but I would prefer not doing a tween as it should not be neccessary in this particular case (I'm just repositioning an object prior to some other stuff). Another option to achieve a similar effect would be to duplicate the sprite and kill the original, but that seems too much overhead for such a simple task.

 

I'm willing to debug the issue (and even patch it if my skill is up to it), but as I know very little of the framework I need some pointers on where to look for possible causes :S

[rich]

I'm aware why this happens, but trying to find a suitable fix isn't that clear-cut. Am still working on it. But basically the issue is this - the delta values for the body are calculated as the difference between the body position in preUpdate and the previous body position. If you change them in a mouse event this happens outside the normal update flow, i.e. it could happen immediately before postUpdate when the delta is applied, causing some massive delta spikes. This is why if you modify them during the State update function it works fine, because it's expecting it there.

 

There is a body.deltaMax limiter to try and curb this, but that doesn't stem the root of the problem. I've been playing with this a little today and will see if I can figure out a way to resolve it properly.

[Willyfrog]

Great! I'll try and look into it tomorrow and see if I can figure something out

[Willyfrog]

I have been reading phaser's code (btw very clean and documented ) and come up with a somewhat hacky fix. I've only changed it for x/y in arcade, but I suppose this would need to be done in other attributes of the body class.

 

The changes are on the following branch:

https://github.com/Willyfrog/phaser/tree/movement (link to exact commit)

 

Critics & comments welcome, as I'm not an experienced JS dev.

[rich]

Don't worry I'm nearly done on this. I fixed the issue with sprites flying off if scaled, you can also now tween them or move them around by changing body.x/y values directly. And I've tested it against the current Arcade Physics tests too and Tilemaps and they're all still working.

 

It's literally just changing a sprite in an input event I need to resolve, and I've got a work-around for it, I just want a cleaner approach.

[rich]

Ok guys I'm done! The new build up in the dev branch should solve a whole raft of issues. This is likely to be the final 2.0.2 release which I'll publish later today.

 

I have included build files as well, so please grab them and have a play. But basically you can now:

 

Tween a sprite directly via x/y even if it has a physics body

Re-position a sprite via x/y in an input handler without it flying off the screen

Tween Sprite.body xy values

Scale a sprite to any size and have it not fly off the screen

 

In my test case I've got a sprite that is tweening via body xy, but you can also move it using the cursor keys (which sets velocity on it) OR click anywhere and it re-positions via Sprite.xy and all of this works together without any weirdness going on. I've also tested 2.0.2 against virtually all of the ArcadePhysics and Tilemap Examples and it's happy and working, so I'm feeling good to sign-off on this release.

[rich]

Ok I've just pushed 2.0.2 live. Please upgrade to this if you're affected by any of the ArcadePhysics related issues described above.

[Willyfrog]

Working again! thanks a lot