Jump to content

[Bug?] Moving camera also moves sprites in invisible groups


Recommended Posts

Hi everyone!


I am currently facing a very weird behavior... In my test-project there are two maps, each contained in a group. With the R key you can switch from one map to the other (this basically makes one map invisible and the other visible).


I have put a character into the first map, which is a basic Sprite object. With the arrows you can move the camera (the character, however, can't do anything).


If you move the camera in the first map : everything is fine. If you switch to the second map and move the camera, the character mysteriously starts moving and falling through the floor. The debug hitbox does not match at all the debug text. The scene seems pretty much messed up.


Can anyone see a problem in my code? Is it a bug?


Thanks in advance for your help!


PS : I attached the code


Link to comment
Share on other sites

Seems a bit strange.

Until someone tells you why this happens, use char1.exists=false; instead of making in invisible. This seems to stop the body from moving on it's own.


A note about your previous post:


The gravity you use is huge. According to your previous post you where having problems with the sprite going through tiles. Try lowering the gravity to something more normal , like 500.

Link to comment
Share on other sites

Hi j0hnskot and thanks a lot for caring!


It feels nice to know that someone else also finds this behavior weird! I hope someone more competent regarding the framework will soon get an eye on this.


For your suggestions, I can't use exists = false, because I need my character to be updated. But it would definitely have been a great solution otherwise. And regarding the gravity, you're totaly right, it is huge, but these are the only values I have come up with that make moves like I want. I should definitely try again some new settings.


Thanks again!

Link to comment
Share on other sites

Hi everyone!


I have worked on the bug lately, and unfortunately I can't precisely figure out what is going on. I have, however, simplified to code to isolate as much as possible the 'bug factors'. So all is left is one 'char' sprite, which becomes invisible when pressing R.


When the camera moves as the sprite is invisible, the sprite also starts moving, and with great incoherence between the sprite coordinates and the sprite.body coordinates.


I have made a Plunker to illustrate the situation : http://plnkr.co/edit/WvbjfyEs6K3jFllqIo3T?p=preview


As anyone any idea?


Thanks in advance!

Link to comment
Share on other sites


I think the horizontal moving is simply a bug in the debug renderer of the arcade physics. You only see the debug shape but the real sprite is still at place- well not really. It starts falling through the walls as soon as the ground tile is out of view and therefore removed from the display. 


The bug is that the object falls through the walls when it's not visible. This doesn't happen when the object is visible (as expected). Maybe this is a known limitation between arcade physics and the tile system. I haven't used the tile system yet. It's worth to post this as a bug in github (https://github.com/photonstorm/phaser/issues) as it really feels like a bug. You can also mention the debug shape thing as a second bug. Thanks for providing an isolated and online available example. This made it really simple to test it myself.




Link to comment
Share on other sites

Interesting. The problem is that the Physics Body relies on the Sprites world value in order to calculate its position. A Sprite only has a current world value if it's visible, because otherwise it gets skipped in the transform updates. This happens down in Pixi, not in Phaser. Thus "visible" and physics updates are basically tied together in a way that isn't easy to modify.


However all you are really doing is trying to stop the sprite from rendering, right? If so you can do sprite.alpha = 0 - this will keep the body alive, the position updated and still have its transform populated by Pixi, but it will skip the render phase entirely. It might feel a little counter-intuitive, but it works.

Link to comment
Share on other sites

Thanks a lot rich for your explanation, your solution does work perfectly in my small demo! (I still have to try it with my real project code though, which implies groups and much stuff, but there's no reason why it shouldn't work)


I just did not want to use the alpha = 0 solution because I had read somewhere that 0-alpha-sprites are still rendered (which would be a huge waste of performance here) : but if you say that it's not the case, then it fits perfectly.


Thank you one more time!

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...