I hate introducing myself on a forum with a help post. So for that, I apologize. I am developing an app that would require thousands of tiny (pixel size) objects on the screen at once. A good example of what I mean by thousands is this app ( https://appsto.re/us/Boj8H.i ). I wanted to use physics objects, but maybe that won’t be the way to go. They need to be able to interact with eachother (collision detection) and be affected by gravity, which is why I wanted to use physics. I’ve tried using circles, squares and lines. But when it reaches about 200 (on the air) it drops to 30-20 fps. Any tips? Maybe just vectors in tables with sprites assigned? Thank you all for your time, this post had to be quick.
EDIT:
Actually what I want to do is make a game like http://powdertoy.co.uk that for iPads. I find it extremely fun. Any new helpful comments?
@Kjell I could use that image idea for pixels that are buried, and have each color identified with a certain element. That way when movement, etc happens it can be converted back into a physics object.
@WhatsALua You already found out that the more physics objects you have, the slower things get. As long as you want the objects to react with each other, you’re limited by how many there are. I can’t think of a way around that.
I’ve watched a video of the app you described (http://youtu.be/ZbMXFu5IWiQ), I don’t know if this is exactly what you’re after. But in this case, you can greatly oversimplify the system.
Assuming you can only drop sand from above, you only need individual grains of sand tot interact with each other at the top layer, right? Once a grain is covered by a layer of, say, 20 pixels thick, you can assume that it will stay there. Than you can draw that pixel permanently onto an image, which is drawn underneath the still ‘fluid’ sand layer. That way you can greatly decrease the number of physics objects necessary.
Actually what I want to do is make a game like http://powdertoy.co.uk that for iPads. I find it extremely fun. Any new helpful comments?
@Kjell I could use that image idea for pixels that are buried, and have each color identified with a certain element. That way when movement, etc happens it can be converted back into a physics object.
@WhatsALua your best bet is probably creating an image the size of the screen and using image:get/image:set. In my version I use this and have objects defined by colour.
I played with a little bit of stuff akin to this a long time ago. Unfortunately I don’t think the box2d physics engine scales very well to these small objects, and approaches like image:get are also far to slow to make this work. But a full physics engine is probably not the right approach, if you look at sand games like this they tend to have a very simplified model of movement and stacking, which you need to get performance.
I’m not sure lua/Codea (while very powerful and easy) is going to get the performance you want, but if I were to do this again now, there might be angles in shaders to write optimised code and get the GPU to do some of the heavy lifting.
