currently I'm developing a simple game which uses physics engine (Farseer for XNA).
I would like to ask how can I make the character so that he can walking on the ground, jumping on platform without rotating itself.
Because I need to update the body position and rotation, because it is a physics object so it will response like the usual which will rotate itself.
Anyone know how can I fix it?
For Farseer 2.1 you can set:
body.MomentOfInertia = float.PositiveInfinity;
Farseer 3.0 appears to have a flag for fixed rotation, which appears to do the same thing internally:
body.FixedRotation = true;
Although I also set rotation to zero after the physics update, just to be sure:
body.Rotation = 0;
Don't be afraid to go in, after your physics update runs, and change any physics values you "don't like". Most games fake and fudge things quite a lot.
Related
I wrote few simple SpriteKit games and always had problems with strong collisions behaviour. Even now with my latest game in development the same issue appears quite randomly.
Game-play area is inside edgeLoopFromRect physics body
There are some objects (with circle physics body) bouncing around
But sometimes (this happens very rarely) when a strong collision (edge <- body1 <- body2) happens directly near the edgeLoopFromRect physics body, sometimes colliding-object (body1) jumps out. I am totally confused how to debug this kind of behaviour.
EDIT: I have recorded a video of what exactly happens:
Physics engine collapses
For the demo I have made impulse strength (the biggest blue ball) on purpose 10-times stronger, so the effect can be seen sooner. Look what happens after 10-15 seconds. Physics totally collapses. This can be seen by background totally going off and balls fly into the unknown.
Note: everything I do in this demo is applying impulse on the blue ball.
You need to enable usesPreciseCollisionDetection. This will force SpriteKit to calculate the physics positions of the entire movement, which will now prevent it from popping out. Code for this would look like this in Objective-C:
self.body1.physicsBody.usesPreciseCollisionDetection = YES;
And in Swift:
body1.physicsBody?.usesPreciseCollisionDetection = true
This will have a performance impact, but will prevent your glitch from happening. You will probably have to do this for all of the circular physics bodies that you have moving around.
Here is the code for setting the characters physics body.
character.physicsBody = [SKPhysicsBody bodyWithRectangleOfSize:character.size];
It works fine, I mean it stays where I want it to but as you can see it displays the character's physics body in the bottom left of the screenshot (which is the grey box).
Is this a bug or can this be fixed?
I had a similar problem which may or may not solve yours.
It looks like you are using some sort of viewport system. Perhaps with a node called world and one called camera? If this is the case then you must be moving your world node every frame in order to center the content correctly? When drawing physics, you need to move the world node at -didEvaluateActions instead of -didSimulatePhysics
I'm working on a game in which the user should be able to trigger 'rods' that come out from the edge of the screen to displace elements on screen (balls). These projectiles roughly resemble pool-cues. Or perhaps pinball plungers, except that they start from the 'loaded' position (mostly offscreen), and when triggered, they eject out, then quickly retreat.
I'm unclear how I should build these with Sprite Kit.
The game uses the PhysicsEngine, and the onscreen balls should be effected both by gravity AND they should be displaced when they collide with the rods. However the rods should neither be effected by gravity, not displaced when they collide with the balls -- they should simply retreat regardless of whether they've made contact with the balls.
I realize I can set the affectedByGravity property for the rods. However because they will still displace slightly when they collide with the balls. How can I 'fix' or 'peg' them in place? Do I need to use an SKPhysicsSlidingJoint? If so, has anyone encountered any examples online? Is there a simpler way to do this?
A related physics engine, Box2D distinguishes static, kinematic, and dynamic bodies.
Kinematic bodies can move and will collide with other objects, but they are themselves not affected by dynamic bodies or forces like gravity. Thus, consider setting rod.dynamic = NO; but animate it with actions. See also here in the reference for SKPhysicsBody.
I want to make some sprites affected by physics gravity, but not all of them in the display screen. For example, the player don't need to be affected and, when collision with another, this one leaves another sprite object that will be affected.
Sorry for my english i'm foreign and try to explain better I can do.
Thanks!!!.
Check this thread out,
Collision Filtering
or check for collision filtering and masking bits.
Are you looking for this?
http://docs.coronalabs.com/api/type/Body/gravityScale.html
Setting gravityScale for a physics body to zero makes it unaffected by gravity.
myObj.gravityScale = 0
Setting it to a negative value makes it "float", for example if you want a balloon going up :)
I'm pretty new to Box2D and cocos2d. I'm trying to do something which I thought would be pretty simple, but it is turning out to be more difficult than I had expected and I cannot find a working answer anywhere.
Basically, I want to move a b2body and rotate it to a certain point with animation.
I can get it to the correct position and rotation with:
targetBody->SetTransform(b2Vec2(10.0f,1.0f),10);
But I have no idea how to animate it there over time. I tried using cocos2d animation on the sprite used for the body, but that doesn't do anything. Any ideas?
There are a couple of ways you could do this.
You could use SetTransform every time step to update the position of the body gradually over time, in effect performing the animation yourself. The drawback with this method is that the body is 'teleporting' to the new position rather than moving, so it has no momentum, which means you can get odd results if it hits anything along the way. Still, if you know it will not hit anything or does not need to react to a collision this would be ok.
The other way is to SetLinearVelocity and SetAngularVelocity to give the body proper movement. This will keep the results of a collision realistic, and you don't need to keep updating anything every timestep. On the other hand, you will need to detect when the body has arrived at the desired position and then set the velocities back to zero, otherwise it will just keep moving. For dynamic bodies you will also need to counter gravity somehow, either by setting the gravity scale of the body to zero, or by applying an upwards force to balance gravity, or by changing the body type to kinematic during the move.
In general, you use Box2D to simulate the physical behavior of objects in relation to each other. The rules of mechanics implemented by Box2D dictate how your cocos2d CCSprites move if you continuously update the translation and rotation of your sprites according to their corresponding Box2d b2Body. You will have some kind of repeatedly invoked tick: method in which you step your Box2d world along in time, and in which you update your sprite positions according to simulation results of Box2d.
This pattern corresponds to b2Bodys of type b2_dynamicBody. Physical laws dictate the motion of the body in this case, and your sprites will follow these simulation results. This is why setting a conflicting position of a sprite by means of a CCAction or even directly will be undone almost instantaneously with the next tick:.
Solution 1: kinematic body type
However, there do exist other modes for a b2Body, and one of these is b2_kinematicBody in which the translation is no longer governed by the world but by the velocities or angular speeds you dictate through setters. So it would be one solution to work with body type b2_kinematicBody as in:
b2BodyDef bdef;
bdef.type = b2_kinematicBody;
With this you would manipulate the velocity and angular speed of a b2Body explicitly. In this case, Box2d is still responsible for moving bodies around, but according the velocities you dictate, and without any force effects of collision or gravity applied to this particular body. Also with this strategy, your CCSprites will follow b2Bodys. Setting conflicting positions for your sprites directly or by applying a CCAction would not make sense for the same reason as described above.
Solution 2: decouple sprites from Box2d
An alternative way to animating sprites would be to fully decouple those sprites from Box2d. In this case, you would simply not have any b2Body that governs the position of the sprite you are going to animate. Now, in this case, only you will dictate the position and rotation of your CCSprite, i.e. directly either through its position property or by applying a CCAction.