Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Velocity of PhysicsBody altered by gravity despite contact #8407

Open
minggo opened this issue Sep 30, 2014 · 1 comment
Open

Velocity of PhysicsBody altered by gravity despite contact #8407

minggo opened this issue Sep 30, 2014 · 1 comment
Labels

Comments

@minggo
Copy link
Contributor

minggo commented Sep 30, 2014

Note

This issue is migrated from here. It was created at 2014/04/09 20:31:54 +0000

Description

When a sprite with a dynamic PhysicsBody is stopped by contact with another PhysicsBody, the velocity of the sprite's PhysicsBody continues to update based on gravitational acceleration -- even though the body itself is not moving because it is obstructed by the second body.

For instance, in the sample code included in the Physics Integration documentation (https://github.com/Yangtb/newPhysics), the circle sprite falls due to the gravity of the PhysicsWorld. When it hits the edge at the bottom of the screen, it stops falling -- but the velocity of the sprite's PhysicsBody continues to change based on the gravitational acceleration. The sprite's PhysicsBody is also never at rest, even when it stops all actual movement.

The correct behavior would be for the velocity of the PhysicsBody to accurately reflect what is visible on the screen. In this case, when the circle sprite's fall has been stopped by the edge, its vertical velocity becomes 0. The PhysicsBody should also be updated to be at rest.

(I'm fairly new to Cocos2D-X and open-source development in general, so I hope this is the correct way to report such a bug. Apologies if I'm going about this the wrong way.)

  • jefferific added comment:
    I've come back to the app where I ran into this issue, and things seem to be working correctly now. Very mysterious. Perhaps something went wrong in the build when I had the problem earlier? At any rate, it's working fine now, so perhaps this isn't an issue that needs addressing.
@minggo minggo added the type:bug label May 7, 2015
@minggo minggo added this to the unconfirmed milestone May 7, 2015
@pandamicro
Copy link
Contributor

@Hempleg confirmed the same issue in v3.7.1 : #13548

@minggo minggo removed this from the unconfirmed milestone Aug 19, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants