SFML community forums
Help => General => Topic started by: MrPlow442 on July 11, 2013, 07:19:48 pm
-
I wasn't sure where to post this so my apologies if I posted this in the wrong subforum. But I have a couple of questions regarding SFML used in conjuction with Box2D.
- in Box2D, methods Shape.Set(...) and Shape.SetAsBox(...) Make syncing physical bodies with SFML's shapes/sprites a bit incosistent and cause the source of my confusion.
What I noticed is that Set method calculates a shape's centroid while SetAsBox doesn't. I assumed that in Box2D shape's centroid is akin to SFML's origin in that it is the origin of all the transformations for the body. I therefore assumed that a SFML shape/sprite with it's default origin of [0,0] would perfectly reflect a Box2D physical body(of identical shape) whose centroid is [0,0], and likewise that a SFML shape/sprite with it's origin set to it's center would perfectly reflect a Box2D physical body whose centroid is accurately calculated.
However it seems to be the opposite. An equilateral triangle in Box2D created using Set with it's centroid calculated is reflected perfectly by a SFML shape whose origin is [0,0], and a Box2D square created using SetAsBox which leaves it's centroid at [0,0] is reflected perfectly by a SFML shape whose origin is at it's centroid. Can anyone tell me why is that?
- SetFramerateLimit() seems to make my application choppy when limit is 60, and when limit is set to 120 it behaves weird. In my test application, even though the limit is set to 120 it is somewhere between 60 - 70 and when the user applies thrust to the triangle the FPS jumps to 120+ and when thrust is no longer applied it reverts back to 60 - 70. Does anyone know why that might be happening? Code at the bottom of the post.
- Can anyone tell me am I perhaps doing something wrong in my code at least SFML wise so that that might cause choppyness?
Test code: https://gist.github.com/MrPlow442/5977338 (https://gist.github.com/MrPlow442/5977338)
-
Sorry I can't help with #1 as I haven't used Box2D enough. But as for #2 and #3 you should implement a fixed time step. Physics engines like Box2D work best with a fixed time step. I would say go with a fixed step between 10-20ms. You should take a look here (http://www.unagames.com/blog/daniele/2010/06/fixed-time-step-implementation-box2d) at this famous post about time steps.
-
Thanks for the response.
I read the blog post but I'm somewhat puzzled with his use of smoothedPosition and smoothedAngle variables. He calculates them but doesn't show how they're used. I assume that the body's position and angle are set to those values, or perhaps those values are applied to the render body/sprite? If that is the case wouldn't then the physical body and the sprite be a bit out of sync? Anyway since he doesn't show when and where he updates the body position and angles I have no clue what to do with those values. The fact that he's done it as a part of a component system doesn't help alleviate my confusion.
Got any advice on this?