What has codea 2.0 done?

I’m not sure if any others have updated to find certain projects act completely differently, but mine does. It’s my building game which has changed. It is laggy (~20 FPS on startup) then when it speeds up after 10 seconds (don’t know why it’s doing this either) my player seems to walk in to the air instead of staying on the floor. I will have to review the physics section for 2.0 but another bug is not being able to touch the screen whilst recording, and the player starts glitching moving over a few frames and then when I stop the recording the player teleports back to where he was when I started recording.

Codea 2.0 looks amazing and so do the forums, but I don’t like the idea of having to reroute through all my projects in order to fix the physics/speed any ideas? TLL?

Are you using custom sprites?

Yes I am, from documents in my building game only so I can’t guess what’s happening to the physics because of that, but in my paint application which I tried next, I use a lot (if not all) of my sprites from Dropbox. Only problem is I can’t sync to Dropbox, Codea just crashes.

@Luatee if you can narrow down the physics issue to a small amount of code that would be very helpful in fixing it.

Regarding the Dropbox issue, I suspect something has gone bad with the cache — this might be a bit troublesome, but could you backup all your projects using something like iExplorer and delete and re-install Codea?

@Simeon I will try to trouble shoot the physics issue, but it might help knowing what was changed in the physics engine for 2.0 as I can find parts of my code in relation to that.
I’ve just done a backup and reinstalling Codea now.

@Luatee there are some deprecations, now that I look.

The biggest one is that pixelToMeterRatio used to be a function, but is now a property on the physics table. So you do:

physics.pixelToMeterRatio = blah

instead of

physics.pixelToMeterRatio(blah)

I don’t feel that I’ve used this physics.pixelToMeterRatio anywhere, but if there are any other features in physics that have been deprecated or even just slightly changed (such as ray cast etc if you have changed that) that could affect this situation.

Weird… I just reinstalled Codea and I now have 1.5/1.6 again? I’ll try another reinstall.

@Luatee the App Store is sometimes weird like that when new updates come out.

I’m looking at the ray cast stuff and there might be an issue. I’ll have to confirm it with @John and see if we can resolve the problem in a quick 2.0.1 update.

Edit: see if you have better luck with raycastAll instead of raycast, if what I’m seeing is a bug, then it only effects the raycast function.

@Simeon On my ipad1, the words “Codea Talk” are big and cover the words Discussion, Activity, etc. at the bottom of the green area. I can kind of read them enough to figure out what they are. I assume it’s a retina reason since the ipad1 doesn’t have the retina display. No problem on the Air.

@dave1707 wrong thread? :slight_smile:

@Luatee you should be able to write a replacement ray cast as follows:

physics.raycast = function(start, end, cat1, cat2)
    local results = physics.raycastAll( start, end, cat1, cat2 )
    return results[1] -- should probably check to see if it exists
end

Sorry, wasn’t paying attention to which discussion I was in. I was jumping around too much.

Codea is failing to sync anything from Dropbox (it really has never worked for me, but I was hoping 2.0 would fix the problem). As soon as I attempt a sync, it crashes out to the main page, everytime, no exceptions.

I’ve deleted it completely. My next step is to delete it and completely power off the iPad (ensure anything that has a temporary cache is guaranteed deleted).

Is there anything else I can do to try to get it to sync? Is there more information I can give to help out?

@Luatee one of the major changes to the physics system is that it no longer reports MOVING contacts in order to make the touched() function faster for lots of physics objects touching at once. Now when you cache a contact you can still read up to date values from it outside the touched function in draw or somewhere else in your update loop.

I might add a sticky post to explain this change if enough people are experiencing it.

Ok. Got it working. Steps (now that I have a good order):

  • 1.) Unlink Codea from Dropbox.
  • 2.) Delete the Apps -> Codea folder in Dropbox
  • 3.) Go to Dropbox -> Settings -> Security and uninstall the link to Codea
  • 4.) Delete Codea from the iPad
  • 5.) Reboot iPad
  • 6.) Reinstall Codea
  • 7.) Link to Dropbox.
  • 8.) Ensure that the Apps -> Codea folder is recreated by Codea in Dropbox
  • 9.) Populate the folder
  • 10.) Sync should work.

Previously, everytime I tried to Sync, it would show 495 items to sync, and immediately crash to the desktop.

My guess is that the folder got deleted and recreated by me at some point in the past and not by Codea, so it didn’t get the right permissions. The cache was likely hanging out as well.

The first time I deleted Codea and reinstalled, it was still linked to Dropbox. After I deleted it, unlinked inside of Dropbox, and reinstalled Codea, Codea thought it was still linked to Dropbox.

I can provide screenshots of my steps if needed. Now, to get my projects back into Codea :wink:

It’s weird, this is a physics issue.
Works fine on the previous version, not on 2.0. Atleast not for me. All the circles pass through.

function setup()
    p = {}
    n =100
    r = 1
    for i = 1,n do
        p[i] = physics.body(CIRCLE, r)
        p[i].x = math.random(r,WIDTH-r)
        p[i].y = math.random(r,HEIGHT-r)
        p[i].restitution = .9
    end
    
    f1 = physics.body(EDGE, vec2(0,0), vec2(WIDTH, 0))
    f2 = physics.body(EDGE, vec2(0,0), vec2(0, HEIGHT))
    f3 = physics.body(EDGE, vec2(WIDTH, 0), vec2(WIDTH,HEIGHT))
    f4 = physics.body(EDGE, vec2(0,HEIGHT), vec2(WIDTH,HEIGHT))
    
    parameter.watch("count")
end

function draw()
    background()
    count = 0
    for i = 1, #p do
        ellipse(p[i].x, p[i].y, 2*r)
        if p[i].y > 0 then
            count = count + 1
        end
    end
end

@Saurabh This is similar to something I reported earlier when Codea 2.0 was being tested. It seems that depending on the speed of the object and where it is when the collision is being tested it will pass thru a wall. I’ll have to go back and see if I can find my original post and see what the response (fix) was. If you take your code and make the starting y value a fixed number, there will be numbers where all the objects pass thru the bottom, and numbers where they’ll all bounce back.

@Saurabh @dave1707: Prior to 2.0, Box2D’s “continuous” property was always on. In 2.0, it was exposed to the Lua side, and it is now set to false by default. Try adding this to the top of your setup function:

physics.continuous = true

For fast-moving and/or small dynamic bodies, you might also try setting the “bullet” property. Be aware that using continuous physics and setting the body.bullet property can incur a performance penalty.

One other thing to note: it’s probably not the best idea to make your bodies only 1px in radius. That’s super tiny, and all else being equal, you would likely start to run into all sorts of strange issues with bodies that tiny once your simulation starts to get a little more complex.

@toadkick Thanks. That saved me the trouble of looking thru previous posts of mine. That now sounds familiar for the original fix.

Thanks @toadkick. Yeah that’s too small, but it was only for demonstration purpose.

Btw where did you read about the change in the continuos setting?

@Saurabh: I had a problem with my bodies tunneling in a prototype after updating during the beta awhile back, and since I’ve been using Box2D outside of Codea for years, I was already aware of the setting, just not quite aware of how Codea handled it. I checked the old runtime, and found that they were always setting it to true before, and looking at the updated reference now, I see that they added the “physics.continuous” property, so that may have helped guide me as well.