physics question

Here’s something I ran across that doesn’t seem to work how I thought it would. I’m creating 2 physics bodies and letting them fall. I have 3 delays set up, one before I define the 2 physics objects, one between the 2 physics objects, and one after the 2 physics objects. I have the limit set to 12000000 which causes about a 1 second delay on my iPad Air. You’ll have to set this to a smaller value and change its value until you get a 1 second delay if you have an older iPad. Setting val to 0 doesn’t cause any delay and the 2 bodies start at the top of the screen and fall together. If I set val to a value of 1, 2, or 3, I expected to see different results depending on which delay was executing. But it doesn’t matter which delay I execute because I get the same result for the 3 values. Both objects appear halfway down the screen. That’s where they would be after a 1 second fall. But I expected the different delays to cause the objects to be at different positions when they were displayed. It’s as if the 2 objects get defined and start falling and the delay doesn’t matter where it’s executed at.


function setup()
    limit=12000000  -- change this value to cause about a 1 second delay
    val=0   -- change this value to do one of the 3 for loops
    if val==1 then
        for z=1,limit do
    if val==2 then
        for z=1,limit do
    if val==3 then
        for z=1,limit do

function draw()
    fill(255, 0, 0, 255)
    fill(0, 255, 8, 255)

I’m not sure why it’s happening, but it seems that you don’t see anything until the setup is finished but the physics are still running so they appear part way down the screen

If I understand the desired effect correctly, it should be doable using tween.delay

@dave1707 - this is my best guess.

  1. The physics objects are stored with the time they were created, which is used to animate them

  2. the time value doesn’t change within the setup function, even if it takes several seconds

  3. by the time the first frame draws, a second has passed since the objects were created, so they are halfway down the screen

But I think the most relevant point is that the clock seems to freeze within a function. You can prove this by printing os.time() or ElapsedTime at start and end of setup - they are the same!

@JakAttak I’m not trying to use it for anything. It just didn’t do what I expected. Like I said above, it’s like the 2 physics objects get defined and start running and it doesn’t matter where the 1 second delay gets executed, the results are the same.

frozen clock is the answer

@Ignatz I put a print( os.clock()) at the start and end of setup and there’s about a 1.6 second difference for me.

well, that doesn’t mean physics isn’t freezing the clock, which seems to be the problem

PS I wonder why my clock freezes in setup, and yours doesn’t

I think there was another discussion about how the physics clock is independent of the program clock, that might have something to do with this

I did a 10 second delay between the define of the first object and the define of the second object and they were both at the same position in draw. It’s like Codea is parsing the setup function and processing any physics defines and then parsing again and executing any other code. That would explain why the 2 objects are at the same positions no matter where the delay is coded.

Well, my above assumption isn’t correct. I added the time to the creation of the 2 objects. If they were created at the same time, their times would be the same, but they were different by the delay amount in between their creation.

It may be that Codea has to give Box2D the time, and it only does it once per frame