Open GoogleCodeExporter opened 8 years ago
Sweet! Thanks again! Keep them coming :)
All your changes will be in my next commit, whenever I can make it.
Original comment by doug...@gmail.com
on 18 Jul 2011 at 2:31
[deleted comment]
There's another thing that I can't understand.
open qb2World.as
at line 430 you have this code:
processingBox2DStuff = true;
b2Base.lib.b2World_Step(_worldB2._ptr, timeStep, velocityIterations,
positionIterations);
processingBox2DStuff = false;
now, try to add this code, after the previous one, and put a breakpoint. So you
have:
processingBox2DStuff = true;
b2Base.lib.b2World_Step(_worldB2._ptr, timeStep, velocityIterations,
positionIterations);
processingBox2DStuff = false;
var obj:CarDriving = _objects[2] as CarDriving;
if (obj.playerCar.b2_body.m_linearVelocity.y != 0)
{
var bbb:Number;
bbb = 0; // Put a breakpoint here.
bbb += 1;
}
now, start the demo. (with cardriving).
the car is stopped. Now press KeyUp to starting accelerate.
Bang! the breakpoint is called.
why? How it could be possible that internal box2d change the velocity.y value
of an object, without knowing about it?
the update call for playercar, is called few line after that one. so at the end
of the box2d call, the carplayer object shouldn't be changed, because box2d
doesn't know playercar.
I hope you understand what I mean.
I use a fixedtimestep of 1/60. and when I press keyup, the linearvelocity.y
contain 0.13. but this value doesn't come from any of your "upper-level"
function. It's box2d which change this value, and I can't understand why.
Original comment by magi...@gmail.com
on 18 Jul 2011 at 3:39
[deleted comment]
you can do the same check, editing the update method of tdCarBody.
add this as first line of update()
var dbg:Boolean = brainPort.NUMBER_PORT_1 != 0;
if (dbg)
{
var aaa:Number;
aaa = 0; // put a breakpoint here. and you see that this.b2_body.m_linearVelocity.y != 0
aaa += 1;
}
but this isn't possible! the car is stopped. and you have just pressed KeyUp.
Original comment by magi...@gmail.com
on 18 Jul 2011 at 3:46
That seems right to me. Pressing KeyUp applies a force to the quickb2 object,
which applies a force to the box2d object. In the b2World::Step() method, the
force is integrated into the motion equations, affecting the b2Body's velocity.
The velocity (and position/rotation) of the b2Body is synced with the quickb2
object in the qb2Object::update() chain after b2World::Step() is complete.
Original comment by Agnes.Kr...@gmail.com
on 19 Jul 2011 at 4:49
no, because Keyup apply force in the update method of the carbody. not outside.
the only reason of this "issue" is a multithreaded issue. I'll check for it,
and I reply here.
but my idea, is that the update of carbody is called, and the keyup isn't
pressed. after the assignment var dbg:Boolean = brainPort.NUMBER_PORT_1 != 0;
(which return false to dbg varible) but before the pedal check inside the
update itself, The keypress is detected. so the same check
(brainPort.NUMBER_PORT_1 != 0) is evaulated in two different way in the same
method in the same loop.
may you confirm that controller is on a parallel thread ? (or, that the phisics
loop is on another thread)
Is there a way to disable multithreading? (if disabling multithreading remove
this issue, than we have a proof).
If so, you should move the controller update, before the phisics management or
you lost consistency and determinism.
Original comment by magi...@gmail.com
on 19 Jul 2011 at 7:26
I may confirm that the controller input is updated while physics update are
processed.
but this may create inconsistency on the physic model, because I may change the
single physic update from the outside.
The input controller status should be updated "Before" the physics update loop.
Original comment by magi...@gmail.com
on 19 Jul 2011 at 10:06
As far as I know, even with Alchemy, Flash cannot be multithreaded by the user.
If it can, please let me know how :)
I'm not sure I understand completely, so let me first describe a simple flow,
so I know that we are on the same page...
1.) A driving simulation starts with the user holding "KeyUp".
2.) Nothing happens in the first physics step (b2World::Step()) because KeyUp
hasn't been detected yet.
3.) Right after the first b2World::Step() call, the first qb2Object::update()
chain is called, where KeyUp is detected, and a force is applied to the
qb2CarBody (and then to the b2Body).
4.) In the second b2World::Step() call, the force is integrated into the motion
equations, affecting the car's velocity.
So therefore, it's impossible to have a car start moving on the first frame.
You mentioned that controller status should be updated before the physics
update loop. In a sense it is, because the next physics step will be aware
that a force has been applied.
I know it seems a little backward, but my intention is so that there's only one
update chain per time step. If controller status was updated directly before
b2World::step(), then we would have to iterate through the whole world tree
twice, once to send information to box2d directly before b2World::Step(), then
once again directly after b2World::Step() to get information from Box2d.
My approach combines the two tree iterations into one iteration. I can see
some arguments for doing two seperate "read and write" iterations, but I didn't
want big performance penalties if your world contains thousands of objects that
have to be visited twice for every time step.
Original comment by doug...@gmail.com
on 19 Jul 2011 at 3:31
[deleted comment]
[deleted comment]
Ok, I found where I'm getting wrong :)
the input is updated in the superclass SmartBody :)
so I have to put the breakpoint "AFTER" the super.update() call inside the
carbody.
^_^
Original comment by magi...@gmail.com
on 20 Jul 2011 at 9:01
Cool...I'm glad it wasn't something very mysterious, because Alchemy has done
some very weird things in the past, and I wouldn't be surprised if it was doing
it again.
Do you use some type of debugger? FlashDevelop has a very good one. The
reason I'm asking is because in a debugger, you can put a "Watch" on a variable
to see exactly when/where it's changed.
Original comment by doug...@gmail.com
on 21 Jul 2011 at 2:29
FlashDevelop
Original comment by magi...@gmail.com
on 21 Jul 2011 at 2:41
Original issue reported on code.google.com by
magi...@gmail.com
on 18 Jul 2011 at 9:01