A fast, easy to use, free, and community supported 2D game engine
fgmanfredini
Member
@Kafu
does calling resetSmoothStates before the loop cause the previous states to be outdated if the loop executes more than one step ? Lets say, for example, the loop executes 3 steps (it can execute a maximum of 5, right ?) the previous states will be from the first step called. Won´t this cause incorrect smooth calculation ?
@karnak yep, compilation options play a big factor with numerical simulations :)
@fgmanfredini Yes! You are absolutely right, and I've misinterpreted your optimization (that was to avoid a double iteration over the bodies list). I tough you want to avoid unnecessary calls to resetSmoothStates_()...to do so you are right, and the correct code should be:
const int nStepsClamped = std::min (nSteps, MAX_STEPS);
for (int i = 0; i < nStepsClamped; ++ i)
{
if (i == nStepsClamped - 1)
{
resetSmoothStates_ ();
}
singleStep_ (FIXED_TIMESTEP);
}
world_->ClearForces ();
smoothStates_ ();In this way when smoothStates_() is called, the cached state refers to the penultimate computed state (that is smoothed with the last computed one). Thank you.
indy2005
Member
Hi,
@Kafu, so we should implement the change you list above, together with @fgmanfredini's optimisation - to save us one iteration over bodies?
Regards
i
fgmanfredini
Member
@kafu
Thas exactly the code i had in mind... ;-) i was about to give you this sugestion (to only call resetSmooth at the last iteration inside the loop)...
@indy2005
yes, I think we should use both my optimizations and kafu's optimizations toghether to get best results.....
I think there is on more issue, regarding bodies that were recent spawned getting smoothed values even they did not exist in previous frames. I think we should implement some control to avoid mistaken smoothness in sprites that were spawned in a frame but did not exist in previous frames... I'm getting some visual glitches now and then (some jumps back and forth, very fast, for only 1 frame ) when new enemies spawn in the scene or when they get off screen on one side and i teleport them to the other side of the screen (in my game, enemies that get off screen one side, reapear in the other side)....
@indy2005 Are two different optimizations. To save one iteration over bodies is needed only the optimization of @fgmanfredini. Mine can be used only if you are sure to not call, from collision responses in singleStep_(), code that in turn uses the smoothed CCNode positions to perform some logic.
@fgmanfredini Nice to share the same programming style ;)
About the spawning of new objects, each CCPhysicsSprite instance needs to be properly initialized with its current Box2D state (setting both previous state and smoothed state to the same current value). No other control should be required.
For teleportation the smoothing, of course, don't works well; you should add a call to a method that re-initialize the cached state; and call it when you teleport the objects.
fgmanfredini
Member
@kafu
At the callback funtions called inside the singlestep both smooth positions and normal simulation position will always be the same, if you reset on every step. So i think we can read the normal body position , instead of the smooth position, inside the callback if we need to have access to the body position to do any game logic. Thats why i think that its a good idea to let the resetsmooth be called only once since it avoid unnecessary iterations. What do you think ?
@fgmanfredini Yes, you are right, but it depends on how you encapsulate your objects. The implementation here is derived from my article, where I completely hide the Box2D instances wrapping them in "PhysicsComponent" objects (the result is that the whole game engine in unaware of the existence of the fixed time-step algorithm and of the state smoothing). The rest of my engine interacts with the physics system only through the PhysicsComponent objects; so, my "sub-step callbacks" can query the PhysicsComponent instance, that in turn must be properly synchronized. If you don't have any further abstraction layers you can avoid the extra resetSmoothStates_() calls and proceed as you suggested.
indy2005
Member
Hi,
I don't think I will be using CCNode positions, just positions of physics bodies. I think I need to incorporate the @fgmanfredini optimisation to reduce a body iteration, and move resetSmoothStates to outside the loop. I guess I need to add some initialisation of the position of the CCPhysicsSprite to the Box2D node...or, make the PhysicsNode invisible until it has at least one iteration of being smoothly positioned (bad programming I know).
i
fgmanfredini
Member
@indy2005
Not bad programming, friend. You and kafu did a good job with this implementation. Its working and it is good as it is. But there always room for optimizations on any code. There is no code that cant be optimized some way. Thats the task we are trying to accomplish here: exchange ideas to try to refine this code to make it as efficient as possible. I'm working on one more optimization to try to remove some visual gliches im having here. I will post it here as soon as i finish it.
By the way, dont move the reset to outside the loop as you said. Instead add the if clause to make it be called only at the last step.
fgmanfredini
Member
I made a implementation variation of the Fixed Time Step that no longer needs the smoothing interpolation routine. If you are interested, take a look at
http://www.cocos2d-iphone.org/forum/topic/9737
This is working very good for me thats why i created the topic. Please let me know what you think.
@fgmanfredini As you stated, your implementation is not a fixed time step, and so it have some disadvantages over the fixed one (for who don't know: they are reported in Glenn's article). Said that, and while still preferring a pure fixed implementation, your implementation is a lot better than a variable time step, nice work (and nice sharing)!
fgmanfredini
Member
@kafu
as i said in the Semi-Fixed post, this is an alternative, not a replacement. The Fixed implementation should be the preferred method. I never say the opposite. What i wanted to post here is an alternative to anyone who may just need a simpler implementation for the box2d stepping method that does not cause the issues associated with the completely variable step or if they are having any issues associated with the fixed step (thats my case).
Xemacobra
Member
Just wanted to say Thanks to @Kafu , @indy2005 and @fgmanfredini.
noThree
Member
I have tried this solution and it's working pretty good (thanks BTW). However when I enable my smoothed camera (which is attached to a b2body, the body looks very jerky. This doesn't happen every single time I run my game. It's more like every few runs.
my camera is just a simple hookes law spring.
CamX += -k * (CamX - BodyPosition.x);
CamY += -k * (CamY - BodyPosition.y);
if I set the camera to:
CamX = BodyPosition.x;
CamY = BodyPosition.y;
everything works fine however the smoothed camera looks better when it is actually working.
noThree
Member
Hi Kafu thanks for the reply. BodyPosition is the position of the b2body but I have tried attaching to sprite position etc.
The problem was that the physics were running jerky all of the time. Because there was no spring attached to the camera, everything else looked jerky in the scene except for the b2body with the camera attached and you didn't notice it. (I hope you get what I mean)
I ended up leaving it (I had a #define to switch between this and normal physics) and continued working on something else.
noThree
Member
After working on this today, the problem has been mostly eradicated. On my 3GS however there is still some occasional jittering ( every 10 to 30 seconds). On my 2G ipod touch the jitter happens every few seconds. Is there anything I could do to combat this?
Prior to implementing this I was getting 55 - 60 fps on the 3GS and everything was working pretty much perfectly. On my ipod I was getting anywhere from 30 to 45 fps so the physics were noticeably slower.
infinity
Member
please help me....
-(void) addNewSpriteWithCoords:(CGPoint)p
{
//....
//...
//...
// initialise the variables responsible for managing interpolation
// as part of fixed time step implementation
b2Vec2 bodyPosition;
sprite.previousAngle = body->GetAngle();
sprite.smoothedAngle = sprite.previousAngle;
bodyPosition = body->GetPosition();
sprite.previousPosition = bodyPosition; -> error
sprite.smoothedPosition = bodyPosition; -> error
}
error: setting a C++ non-POD object value is not implemented - assign the value to a temporary and use the temporary.
It's a known problem of LLVM/clang when you try to assign a C++ POD to an Objective-C property, try using:
[sprite setPreviousPosition:bodyPosition]
Some infos here: http://support.openfeint.com/general/llvm-compatibility-prior-to-of-sdk-2-9-for-ios/
lgchicken
Member
Hey,
Im using the code in this thread, and it is working very well,
However, I think there is something odd in the smoothing code-
The majority of sprites work fine but often i see others flash across the screen rapidly, (most commonly at 0,0)
any idea why this is?
i am using a lot of sprites over a large area - could is be something to do with a lot of my bodies being asleep?
Many thanks,
blackmouth
Member
I'm using this implementation right now and it's working so far. Except for some reason the begin and end contact methods are being called in the same step. So, I can't use begin and end contacts for any purpose correctly. Is there a reason it might be doing that? I noticed a consumecontacts() function that is commented out, I'm wondering if it might have something to do with that.
This is my implementation right now
PhysicsSystem::PhysicsSystem (): fixedTimestepAccumulator_ (0),velocityIterations_(8), positionIterations_(1), fixedTimestepAccumulatorRatio_ (0) {
b2Vec2 gravity;
gravity.Set(0.0f, -10.0f);
bool doSleep = true;
world_ = new b2World(gravity, doSleep);
world_->SetAutoClearForces (false);
}
void PhysicsSystem::update (float dt) {
Maximum number of steps, to avoid degrading to an halt.
const int MAX_STEPS = 6;
fixedTimestepAccumulator_ += dt;
const int nSteps = static_cast<int> ( std::floor (fixedTimestepAccumulator_ / FIXED_TIMESTEP));
// To avoid rounding errors, touches fixedTimestepAccumulator_ only
// if needed.
if (nSteps > 0) {
fixedTimestepAccumulator_ -= nSteps * FIXED_TIMESTEP;
}
assert ("Accumulator must have a value lesser than the fixed time step" &&
fixedTimestepAccumulator_ < FIXED_TIMESTEP + FLT_EPSILON
);
fixedTimestepAccumulatorRatio_ = fixedTimestepAccumulator_ / FIXED_TIMESTEP;
// This is similar to clamp "dt":
// dt = std::min (dt, MAX_STEPS * FIXED_TIMESTEP)
// but it allows above calculations of fixedTimestepAccumulator_ and
// fixedTimestepAccumulatorRatio_ to remain unchanged.
const int nStepsClamped = std::min (nSteps, MAX_STEPS);
for (int i = 0; i < nStepsClamped; ++ i) {
if (i == nStepsClamped - 1) {
resetSmoothStates_ ();
}
singleStep_ (FIXED_TIMESTEP);
}
world_->ClearForces ();
}
void PhysicsSystem::singleStep_ (float dt) {
//updateControllers_ (dt);
world_->Step (dt, velocityIterations_, positionIterations_);
//consumeContacts_ ();
}@blackmouth As a single call to PhysicsSystem::update() can implies multiple calls to world_->Step(), more contacts can happens.
Anyway, as reported in Box2D manual (http://www.box2d.org/manual.html#_Toc258082975, note at the end of par 9.3):
Accessing contacts off b2World and b2Body may miss some transient contacts that occur in the middle of the time step. Use b2ContactListener to get the most accurate results.
means that multiple begin/end contacts can be reported in the same sub-step. The idea is to collect valid contacts fired by b2World::Step() using a listener; then in consumeContacts_() activate the right game logic for the detected contacts.
Thank you Indy2005 and Kafu for your code and advices, implemented a slightly changed PhysicsSystem class in my project (integrating it with the WorldPhysics singleton I use and custom CCSprite objects with the necessary properties added to it). It is working really well. One thing I had to do was to use interpolated positions (and sometimes angles) only with dynamic and kinematic bodies and not static ones.
@getbirdy I think you can consider code shared on this forum as "public domain", I think this was the intention of @indy2005 and @fgmanfredini too.
@Panajev Excluding static bodies should be a good optimization. Nice. (btw - a bit late - congrats for the Faber contest!)
You must log in to post.
