Least labor intensive -- physics engine / translate etc

Solar2D General Questions/Discussion
#1

Hi,

ok I am embarking on another game with Corona after a break of moving into C# with Unity and VIVE VR.

My new game will have possibly hundreds of objects on screen and I will need to be checking for collisions etc.

So, I have created a bunch of objects in seperate Arrays that I am pooling to save having the garbage collector kicking in and out clearing lots of stuff up all the time.

At the moment I am moving the objects with transition.

I need to check for collisions on all these objects.

Question: should I use the physics engine or use overlapping rects/circles ?

Benefits of the physics engine are that I can check easily for collisions, If Iam using the physics engine I could use linear impulse to propel my objects instead of the transition api.

Question: what if I use the transition api for movement and the physics engine to check collisions? Is this going to save any CPU time?

I just want to get off to the correct start.

Thanks

#2

This is hard to give a good answer to.

My suggestion is that you create a super-basic test bench for both cases and try ‘physics’ versus ‘DIY COLDET calculations’.

One problem I forsee is your combination of transtion.* with physics objects.  It is entirely possible that the objects will go to sleep if you’re always moving them via transition.*  So, you’ll need to force them to stay awake.  Doing this will increase the load on your system dramatically as all objects will essentially be awake all the time.

On the other hand, DIY coldet (even simple center to center distance tests) will be slow once you get into the upper hundreds of objects.  (one way to solve this is to amortize the cost over several frames, but this gives up accuracy)

So, again, the only way to know is to test out both ideas with a representative dataset.

#3

Transition is fine for some objects… not so fine for hundreds.  For hundreds I would look at a more enterframe() approach and approximate the collision detection.  

You will want to proxy the dimensions instead of reverting to displayObject properties as that is slower.

#4

If you end up going with a DIY approach, consider the speed difference between directly accessing display object fields versus a lua table.

https://forums.coronalabs.com/topic/71838-great-performance-blog-post-by-dave-bollinger/

#5

@RoamingGamer

thanks for the input, even though I have come across “isSleepingAllowed” many times I definalty missed that in this scenerio, makes sense.

Thinking about this I could perhaps check for collisions once “near” the proximity of the collider and collidee by comparing their respective x,y co-ords? But I would still need to be listening for those events I guess.

Test bed sounds the way forward, shouldnt be to much trouble to do that.

@SGS

yes just moving with a gameloop ( enterframe ) was a consideration rather than transitions for sure.

So i wonder if moving objects with enterframe and checking without the physics would be better, again I need to test.

@RoamingGamer

great link to Dave Bollinger, that is quite an impressive performance improvement, never would have thought of that in a million years.

#6

This is hard to give a good answer to.

My suggestion is that you create a super-basic test bench for both cases and try ‘physics’ versus ‘DIY COLDET calculations’.

One problem I forsee is your combination of transtion.* with physics objects.  It is entirely possible that the objects will go to sleep if you’re always moving them via transition.*  So, you’ll need to force them to stay awake.  Doing this will increase the load on your system dramatically as all objects will essentially be awake all the time.

On the other hand, DIY coldet (even simple center to center distance tests) will be slow once you get into the upper hundreds of objects.  (one way to solve this is to amortize the cost over several frames, but this gives up accuracy)

So, again, the only way to know is to test out both ideas with a representative dataset.

#7

Transition is fine for some objects… not so fine for hundreds.  For hundreds I would look at a more enterframe() approach and approximate the collision detection.  

You will want to proxy the dimensions instead of reverting to displayObject properties as that is slower.

#8

If you end up going with a DIY approach, consider the speed difference between directly accessing display object fields versus a lua table.

https://forums.coronalabs.com/topic/71838-great-performance-blog-post-by-dave-bollinger/

#9

@RoamingGamer

thanks for the input, even though I have come across “isSleepingAllowed” many times I definalty missed that in this scenerio, makes sense.

Thinking about this I could perhaps check for collisions once “near” the proximity of the collider and collidee by comparing their respective x,y co-ords? But I would still need to be listening for those events I guess.

Test bed sounds the way forward, shouldnt be to much trouble to do that.

@SGS

yes just moving with a gameloop ( enterframe ) was a consideration rather than transitions for sure.

So i wonder if moving objects with enterframe and checking without the physics would be better, again I need to test.

@RoamingGamer

great link to Dave Bollinger, that is quite an impressive performance improvement, never would have thought of that in a million years.