Jump to content

Sprite.angle and Body.rotation questions


j0hnskot
 Share

Recommended Posts

Hello there!

I'm making a game to learn  the phaser engine (guess what! A flappy bird again !).

I got 2 images of pipes. One looking up and one looking down.

I realised that since the image is the same i could save a few bytes by using the same image for the sprite but rotating it.

I used sprite.angle but the problem with it is that when i apply an anchor and the physics are enabled for the pipe it fly off the screen. 

I used body.rotation with success on the bird sprite to animate it while flying but the problem is that it works only if i do so in the update loop.

 

So what i ask here is either tell me a good practice to use correctly sprite.angle or tell me how i can change the body.rotation outside the update() loop.

 

Also, what are the differences of those two? Is on of them more "expensive" in resources than the other? Which should i use for that kind of work?

 

Here you can see the code .

 

Thank you in advance!

 

Link to comment
Share on other sites

Setting sprite.body.moves = false before adjusting the other values may help. Essentially, if you start playing with the positioning in any way of an object affected by physics, it will start to do weird things as it attempts to rectify that sudden movement into a physical effect on the object, which usually results in it flying off the screen at high speed. Setting body.moves to false stops the physics system from controlling the object so you can manually position it as needed.

Link to comment
Share on other sites

To answer your other question, in Arcade physics at least, body.rotation I believe just proxies the value back to the sprite, as the body cannot be rotated (part of the reason it's so fast, as all it has to do is compare aligned rectangles - hence 'axis aligned bounding box') so I'd suggest you just use sprite.angle. I believe the reason for body.rotation is so that when you use body.angularVelocity to start an object spinning, the body keeps its own record of how far the sprite should be rotated, so that it can change the sprite's angle on the next render update.

Link to comment
Share on other sites

Setting body.moves back to true (maybe on a very short timer to ensure you get past the physics update) and then setting the velocity will re-enable them. I found that velocity in general caused more problems than it solved for this exact purpose (I've made a Flappy Bird clone) as the physics system is a bit overkill for simply scrolling obstacles past the screen, when all you really need is the collision detection. I instead resorted to manually updating the body.x by a fixed amount multiplied by the delta (physicsElapsed) time to account for frame rate inconsistencies. This gave me better control, and allowed me to update the speed of the obstacles in real-time, simply by changing the speed value.

var speed = 50; // speed in pixels per secondfunction update() {  sprite.x -= speed * game.time.physicsElapsed; // move the sprite to the left at [speed] pixels per second}
Link to comment
Share on other sites

Thank you for the answers! It seems that with all that work i won't gain much at performance (it might be worse than it is now).

For this game i think it's better just to use a spritesheet including both the pipes. But your information was helpful for future needs of my games. Thanks again!

Link to comment
Share on other sites

I tried it . It gets flipped but messes with the body and the collision. If i put an anchor on the center to flip and create the body after, it flies to the sky. If i create the body first ,use body.moves=false and then put an anchor the collision is wrong as it keeps its starting position. 

I can't understand where i mess. am i putting the anchor wrong? Do i get wrong the order of commands? I'm so confused!

Link to comment
Share on other sites

I just found out that the reason that the pipe fly away is when i put a negative number. Here for example :

    pipe.scale.setTo(1,1);    pipe.anchor.setTo(0.5,0.5);    game.physics.arcade.enable(pipe);

the pipe stays still. If i change the anchor or the scale to a negative number it flies to that direction. Why this happens? 

Link to comment
Share on other sites

Try this:

pipe.scale.set(1); // 'set' is a short way to set both x and y to the same valuepipe.anchor.set(0.5);game.time.events.add(20, function() {  // wait 20ms (just to be sure) before enabling physics, so that the physics system  // doesn't try to erroneously interpolate the movement  game.physics.arcade.enable(pipe);}, this);

It's not a particularly elegant solution, and I'm sure there are much better ones - but the issue you're battling with is due to the fact that physics systems have very specific use cases; that of allowing an object to be affected by chaotic (in the true sense of the word) forces and reactions. As soon as you start to try to rein in the physics system and get it to conform to a particular way that you want it to work, you'll start to find it difficult and messy. In the case you're using it for, non-physics based movement would be far easier and, ultimately, more performant.

Link to comment
Share on other sites

I tried it but it messes up because i use the var pipe to create all the pipes and by adding this it just skips the current pipe since it is an event and the app doesn't stop running. 

But i did something different. I updated from 2.0.1 to 2.0.4 ! I can use negative values now.  But another problem remains. 

I'm able to flip the image but the body doesnt follow it even if i create it after. It creates the body on where the sprite was created ,based on the anchor but not on the scale. 

 

Is there something i can do? Or i must manually move the body to the correct place?

Link to comment
Share on other sites

It's working fine only when i re-place the body. If you see the code at github you will see that i change it on the addPipe function.

I'll revert the change on the server too and ill enable the debuging so you can see for yourself.

 

Edit: I reverted the changes but the debuging doesn't work for some reason. I don't know what the heck changed since last time. 

You can still see that the collision is wrong.

 

Edit 2: Fixed, you can now see the debug.

Link to comment
Share on other sites

 Share

  • Recently Browsing   0 members

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