Notice: topDown Transmission

[GoogleCodeExporter]

Version: 2.0.6

function: shiftToOptimalGear
line: 175

code:

var estimatedTireRotSpeed:Number = linearSpeed / _carBody.tires[0].metricRadius

you should use a driven tire. you are doing the assumption that all the tires 
has the same radius.
if I use a car with front wheel radius < rear wheel radius, and the rear wheels 
are the driven ones, that your code produce a wrong result.

(in any case, you should check if the carBody has at least 1 tire :) )

Original issue reported on code.google.com by magi...@gmail.com on 18 Jul 2011 at 9:01

[GoogleCodeExporter]

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

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

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

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

FlashDevelop 

Original comment by magi...@gmail.com on 21 Jul 2011 at 2:41