World scale messing arcade collisions up?

[Raicuparta]

I'm making a game where there are a lot (hundreds) of small solid objects, and the player can collide with them. When the world scale is set to 1, everything seems to work fine. But when the world scale is set to something smaller, like 0.6, the player will some times collide with one of the many sprites, even though they are not overlapping. Are there known issues with world scale affecting collisions?

[sanojian]

Are you moving the camera by any chance?  I am just noticing that if I set the world scale, then move the camera the physics seems to act as if the camera has moved based upon a scaling of 1 and things behave incorrectly.

 

Is this a bug?

[sh0dan]

Hi!

 

I found the same issue, since I would like to create a game where all assets are scaled by a factor 2.

 

It can be easily reproduced, on this example:

 

http://phaser.io/examples/v2/tilemaps/csv-map-collide

 

Add `game.camera.scale.setTo(2.0, 2.0);` to the create function, and collisions will be broken. Is there somewhere I can should report this?

[Bengalaa]

you can/should report it to the phaser's github repo https://github.com/photonstorm/phaser

 

btw, i am having the same problem is there any way to fix this?

[Skeptron]

Did you guys try to debug-display the bodies of your objects? My guess is that the sprites are scaled but not there body, thus the weird behaviour.

 

For body debug : http://phaser.io/examples/v2/arcade-physics/body-debug

[Loathsome]

I'm running into the same issue trying to zoom in using Phaser.Camera.scale.  I've also tried using ScaleManager, Stage, and Group scale members, all have the same issue.

 

Here's my example: https://loathsome-games-afictitiousforce.c9.io/momentus-scale-bug/

And the source: https://github.com/RolandMQuiros/loathsome-games/blob/d8c5f0c151f4844c78bc280293a5275c44668ff9/momentus/js/main.js

 

WASD to move the guy around, I and K to zoom in/out.  Notice the guy and level's bodies are still set to their 1.0 scale dimensions, and zooming just messes with that further.

 

I'll go ahead and make the issue in the morning if Rich doesn't pop in.

[Loathsome]

Digging into the Phaser source, it seems like Phaser.Physics.Arcade.Body updates its position based on Sprite.world.xy, which means it takes into account the Sprite's transformations, but only with regards to the Body's position.  I changed it to just use Sprite's local xy and it seems to work as we expect.

 

Here's an updated example: https://loathsome-games-afictitiousforce.c9.io/momentus-scale-bug/index.1.html

 

WASD to move the guy.  IK to zoom the camera in and out, and JL to rotate the group.

 

I've got the fix here: https://github.com/RolandMQuiros/phaser/commit/f732cc1129c28f1cd821e28259f942f34a11c1a6

 

But I want to know if this is actually a bug, first, before I make an issue about it.  I haven't run into any use cases in the examples about scaling the camera, but the logic spills into how group transformations are handled by Arcade, too.

[Skeptron]

I don't know if using the sprite coordinates is actually a good idea. I mean, for your example it is, obviously, but I don't think it can be used everywhere. If you have a character with different animations of various sizes, then the sprite's width/height can greatly vary, whereas the body is stable to its initial size. Thus the movements are better calculated from the body's perspective. At least I think so.

[Loathsome]

It seems like the existing code is using the sprite coordinates anyway, just after scales and rotations are applied.  Do you think this might be a design flaw?