physics collision questions e.other

Solar2D General Questions/Discussion
#1

I’ve got a crash which I think is physics related so I’m trying to check that I’m doing everything correct.

  1. In my object collision listener function I set a flag to say that the object has collided and then use that flag to change the objects properties in the main game loop which is based on the enterframe event. Is this OK?

  2. in the collision listener function I check the phase of the event but does it matter whether I set the flag in the began or ended phase? At the moment I am using the began phase because if I use the ended phase the collison does not seem to take place as soon as I want.

  3. In my collision listener function can I change object properties like alpha without causing problems?

  4. If I have two physics objects WALL and BALL. And I detect a collison in the WALL collision listener function. Can I use e.other (which refers to BALL) and safely apply changes to BALL within the WALL collision listener or do I still have to set a flag for BALL and change it’s properties in the main game loop? [import]uid: 51494 topic_id: 25890 reply_id: 325890[/import]

#2

As a general rule of thumb, you can’t perform “physical” changes to colliding objects in the same game cycle. While some might claim that this is a “Corona shortcoming”, it’s actually a Box2D issue.

Basically, most non-physical interactions should be possible in the same collision game cycle, including alpha changes, and even deleting an object. What’s NOT possible is changes to the object’s position, and most physics-based API calls.

If you ever wonder what is allowable and what’s not in the collision cycle, just try it and observe the Terminal. Corona will let you know, via warning or outright error, if there’s a problem.

Finally, a constantly-running game cycle probably isn’t the most efficient method, unless you already use/need that for another purpose (i.e. ParticleCandy particle updates). If you don’t need this, it’s far more efficient to execute a short timer for delay-necessary physics interactions which run just once. The EnterFrame listener is useful for various purposes, but it’s not optimal for the reason you describe.

Brent Sorrentino
Ignis Design

[import]uid: 9747 topic_id: 25890 reply_id: 104786[/import]

#3

Hi Brent,

Thanks for the response. I’m not getting any problems in the simulator but crashes on the actual device.

I am using particle candy but to be honest I thought I needed the enterFrame game loop. (I’d worked with a 3d engine before where every cycle everything was redrawn so was perhaps blinkered in my approach.)

I suspect I have made a stupid error somewhere but am ****** if I can find it. I’ll keep digging.

Thanks again for the clarifications. [import]uid: 51494 topic_id: 25890 reply_id: 104795[/import]

#4

Yes, it’s understandable coming from other SDKs and engines. Corona definitely doesn’t “need” a game cycle listener, or typically not one running constantly. In one of my apps, I start such a listener when it’s necessary and turn it off when it’s appropriate, to optimize efficiency.

However, ParticleCandy requires it to update its particles. Even so, you’re still probably better off just executing timers for the delayed collision events you need, versus adding a “flag” check to every iteration.

Brent
[import]uid: 9747 topic_id: 25890 reply_id: 104800[/import]