Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


edited March 22 in Questions Posts: 180

I’ve been playing around with the physics in Codea, trying to see what the upper limits are.

I’m seeing that it looks like on A14 chip I can get around 500 boxes bouncing around and maintain 60 FPS granted there are no huge amount of collisions all at once, let’s say we spawn 100 boxes all in the same x,y position, these boxes will all collide and there is some massive churn for a few seconds as the collisions are resolved.

500 seems great for 60fps, but I’m greedy and bullish. Maybe we can get more?
Well when ever I try around 900 or more, the slow down is quite bad.

I wonder, what physics library is Codea using under the hood? Is it box2D, and is it the latest version? Just want to confirm if this is the best we can do from a software perspective.



  • dave1707dave1707 Mod
    Posts: 9,586

    @skar According to the Codea Credits, it uses the box2D library. See

  • SimeonSimeon Admin Mod
    Posts: 5,714

    @skar I think this will be possible with the new runtime @john is working on. That would allow compute shaders and physics to be evaluated on the GPU for orders of magnitude more objects

  • edited March 25 Posts: 180

    That’s awesome, hope Codea 4 is releasing soon.

    I’ve put some more play time into this and replaced the line drawing of physics boxes with a Mesh texture, performance is better, even at 900 there is still slow down but it’s not as bad as before and is primarily on the mass number of collisions situations.

    I’ve tried using physics.iterations() with many different values but they don’t really seem to have a framerate benefit.

    Next I’m going to try to see how well the mesh holds up with a 60fps changing image.

  • Posts: 1,125

    gotta get you guys onto the continuous delivery path :smile:

  • edited March 26 Posts: 180

    Here’s my latest test -

    600 bodies + 600 mesh textures (each mesh texture is a separate mesh to assume each unique mesh in a real game) animating at 60 FPS

    Personally this is really good results, it should mean that in a real game scenario, we could have tons of animating objects that respond to physics. Even more head room the less physics you have, I was able to get thousands of meshes animating and moving at 60fps, seems to drop to 30 around 6000.

    My next goal with this mini project is to make that time scale option work, going to try and see how I can add “slo-mode” and a “speed up”

  • edited April 1 Posts: 180

    I’ve been putting some more time into this project and have managed to get loading screens working using coroutines for Threads.

    I’ve also adjusted the mesh to fit the size of the physics boxes and added the boxes outlines again, which does impact performance a bit (as expected since it’s extra draw calls). I’m adding the project in its current state zipped here for anyone who wants to check it out (@UberGoober ;) )

    @Simeon hi Simeon, one thing about this project is that if you set physicsMultiplier to 7 to get 700 boxes and meshes, the performance has a drastic hit and then I will also get crashes of Codea. Is that expected because the demand is too intense? Or is there another problem?

  • Posts: 1,379
    Won’t run on my iPhone
  • Posts: 2,428
    @skar - asset image not included
  • edited April 1 Posts: 180

    Oh that’s a whoopsie... DemoSprite is meant to be a comparable renderer to DemoMesh. DemoSprite uses the 1-60 images each broken out into its own image, while DemoMesh uses a sprite sheet/atlas so it’s only 1 image. Here’s a working zip with all sprite images included but a hacky implementation using ‘assets.all’ (kinda unfortunate I cannot have sub folders in the project assets...@Simeon).

    this will allow the project to run, if you end up wanting to use the sprite rendering just make sure you comment out line 11 in DemoSprite, I forgot to after debugging

  • Posts: 1,379
    @skar this is some very interesting research you’re doing.

    I wonder if you’ve been following this thread:

    That simulation is really cool, but it slows down a ton when it gets around 600 objects—if the work you’re doing could help boost it into the thousands that might really be remarkable.
  • Posts: 180

    @Simeon hey Simeon, I noticed that the “” does not report “MOVING”( or “CHANGED”). Check out Physics Lab Example Test 4

  • edited April 27 Posts: 180

    i keep putting more and more work into this project. eventually i hope to use it as an all encompassing boiler plate for games i want to make...

    anyway, i've now added my own z stacking algorithm and ability to use any 2D shader i find online (mainly from and maybe later on i'll buy the shader pack from unity and see if i can import them into codea

    as you can see, using a complex shader like this (it creates, draws, and moves around random circles with random colors) has a big performance hit, even with only 300 bodies and meshes we're at 30fps,

    hopefully C4 will have a massive improvement to this (fingers crossed)

  • Posts: 2,428

    @skar - very impressive, balancing features against the cost of using more advanced tech looks like it could be frustrating. Could you use this to simulate fluid flow?
    Please keep us up to date with your progress.

  • Posts: 180

    @Bri_G thank you! there's actually a C++ library for fluid motion -

    maybe if @Simeon has time and he can add it in eventually

  • Posts: 2,428
    @skar - OMG that's superb. I assume you can merge the spheres in some way.
  • Posts: 1,379

    @skar any chance you want to share the newer version ;) ?

    Your Queue class is really cool and it could be renamed “OmniTable,” because it acts like an array that’s accessible like a hash table and vice-versa.

  • Posts: 180

    @UberGoober i don’t mind sharing just keep in mind there’s still a lot of WIP stuff going on and i’ve reworked the Queue to just be a simple array but added an OrderedQueue which is like a hash table but with 2 dimensions that i use for z ordering

  • edited May 20 Posts: 180

    i’ve been working on this again and i now have time scaling working as well as a bunch of internal improvements that generalize the code more, as well as being able to drag and throw any body with a touch, still a lot of this is WIP especially around managing shaders but it’s getting really close to the point where i will have no excuse but to work on some actual gameplay

    shows that the speed of frame animations and physics movements can be controlled with a timeScale variable that mimics the effects of slow motion and fast forward

Sign In or Register to comment.