This project has moved and is read-only. For the latest updates, please go here.

FP3 Trouble with values

Topics: Developer Forum, User Forum
Aug 4, 2010 at 10:39 AM
Edited Aug 4, 2010 at 10:41 AM
So I have a level with surrounding walls a roof and a ceiling if you will, and a few dynamic boxes in the middle of the screen. I then have a ball in the bottom left corner. What I am trying to ultimately achieve is an effect where the user can drag from the ball to draw its trajectory and then release to throw it. To keep things simple for now I wanted to see how the ball reacted when I called certain functions from the engine on it, so I made it so that I just have to click the ball to make it shoot off at a 45 degree angle to the floor. To my surprise, when I called Body.ApplyForce() or Body.ApplyLinearImpulse() nothing really happened. So I started changing values around, the things I can think off that will effect this test are gravity, the balls mass, the balls damping, and the strength of the force being applied. To simplify things a further I started using Body.LinearVelocity to set the balls trajectory immediately without applying a force. I eventually got the ball launching up into the air, but really only a pathetic amount (about 100 pixels high). I want the ball to fire off at a high speed and maybe bounce off 4 or 5 walls before coming to rest. The problem I was having was that I was using the maximum possible value for a float in the vector i was setting for Body.LinearVelocity. I loaded up FP2 to look at some examples I noticed gravity was set to a vector of (0,100) an objects mass was only 5, friction was .4f and restitution was .2f with no damping whatsoever. I copied these values into my level and still I cant get the ball to fly off at high speed. I even tried making the balls density 0.02f, gravity (0,50), no damping and applying a LinearVelocity of (99999999999999,99999999999999). I'm guessing I must be doing something fundamentally wrong here? Any insight would be greatly appreciated.
Aug 4, 2010 at 10:56 AM

F3 is using a different scale, more aimed at the real world. That means a length of 1 is approx 1 meter and so on. This generally means that you need far smaller values then in F2. Looking at your values, I can at least see the gravity is enormous. Try it with something around 10 or lower. And shouldn't it be negative, pointing down? For density I usually start off with 1.

Aug 4, 2010 at 1:51 PM
Thankyou kindly for your response jordos. If I set gravity to be (0,10) then when a box is created near the top of the screen it takes about 90 seconds to reach the floor?
Aug 4, 2010 at 2:12 PM

It might be because your physics world is extremely large. What size is the box? The Box2D manual recommends you to keep those values (size) between 0.1 and 10.
Otherwise, check the density and set it to 1.

Aug 4, 2010 at 2:18 PM
Interesting - might be getting warmer now. I used the FixtureFactory to create my box and set the dimensions of it to be the same as its size in pixels. So the floor in my World is 1280 x 240 and a box is 32 x 32. If i scale everything down and make a box say 3.2 x 3.2 does that mean I will have to do calculations on the box to figure out where it should be positioned on screen?
Aug 4, 2010 at 2:31 PM


For me that is always the hardest part, converting from Farseer's coordinate system to the screen's / game-engine's coordinate system and back.

Aug 4, 2010 at 2:41 PM
oh god! Just when I thought I was onto a winner. I guess Ill just divide and multiply by 100, making 1 pixel 10cm in the physics world. This is going to be fun (not) thanks for the hlep jordos you're always a star.
Aug 4, 2010 at 3:16 PM

Generally you must realize Box2D uses a right-handed coordinate system. That also means rotation is ccw, and the Y axis is pointing up. This is different than in raw xna. Therefore I asked if you wouldn't want to make the gravity negative. Seeing it now, I guess it's alright as long as you don't invert the y value of the positition when drawing an object (but in fact the objects will 'fall' up in the simulation). Lastly you need both the origin of a body and of an entity (sprite) in your game to be the same, otherwise the rotation will look odd.

You might want to consider using the FlatRedBall engine. This engine uses a right-handed coordinate system, and units instead of pixels that can be used in Farseer directly. You'll need to invest some time in getting used with the engine though.