physics.stop() or physics.pause() ?

Solar2D General Questions/Discussion
#1

From what I’ve read on the forum, using physics.stop() can bring a lot of bugs, if you don’t manage to track all the physics items, especially when using the storyboard / composer API.

Here are the topics in question :

I did track each of my physic item, and remove them everytime I change the scene, but I had several bugs : app crashing on device, weird placement of items when creating the scene, etc.

And then, I did replace physics.stop() by physics.pause(). Now, it seems to work ! No more crash, no more bugs. Even though I’m not 100% sure since I’m gonna need to test a lot more.

And there comes my question : is it actually safe to simply use physics.pause() ? It does work, but then, on what occasion would we need to use physics.stop(); ? And by using physics.pause(), does it means we don’t need to remove all of the physical bodies every time (like when we’re creating newJoint), especially if storyboard removes each display objects ?

#2

if you are absolutely rigorous about removing each and every physics object (bodies, joints) then it seems to be safe to call physics.stop()

(personally i wish physics.stop() were written to “soft fail” if it can’t succeed for whatever reason, rather than crash)

joints are almost always the culprits - particularly if using the sample dragBody() like as given in ragdoll.  are you?

#3

It does seem that joints are the one causing crashes, even if I do try removing them properly… 

I’m using pivot and touch joint, without using dragBody().

Now, nnowing that those objects are inserted into the scene group, and now that I’m using physics.pause() : do I still need to remove and nil every physics object ? Or is there a risk of having a memory leak or something else ?

#4

i like to manually remove/nil everything anyway, i like to KNOW what’s being done, and when, and i reference count everything - just personal preference.  so i’m the wrong guy to ask “should i let the scene clean it up for me?” :smiley:  if there’s a problem you probably won’t notice it if just using physics.pause(), but if you need physics.stop() then it seems you’d want much tighter control.

i think that’s in part why joints are usually the problem, because they’re not display objects, and so scene can only remove them “indirectly” by removing the involved bodies.  so if that were to fail, for whatever reason, then you’d have a stranded joint just waiting to crash physics.stop().  it appears that’s not impossible, but it’s very hard to debug, as usually these are 1-in-a-1000 type situations.

fwiw:  double/triple-check your touch joint event code.  any chance you might overwrite and abandon an existing touch joint in “began”?  any chance you’ll try to reference a nil joint if you got a “move” after “ended”? (can happen on a real device)  any chance you might strand a joint if fail to get ended or cancelled?  (again, real device, say a phone call comes in mid-swipe and you suspend - any guarantee you’ll ever see the end of that event?)  any chance, if using multitouch, that you can’t handle the following event pattern:  begin1-begin2-move1-ended2-move1-ended1, et al?  (that is, did you handle those two begins and their out-of-order ends?)  etc

#5

Well, thank you for all the advices :wink:

#6

if you are absolutely rigorous about removing each and every physics object (bodies, joints) then it seems to be safe to call physics.stop()

(personally i wish physics.stop() were written to “soft fail” if it can’t succeed for whatever reason, rather than crash)

joints are almost always the culprits - particularly if using the sample dragBody() like as given in ragdoll.  are you?

#7

It does seem that joints are the one causing crashes, even if I do try removing them properly… 

I’m using pivot and touch joint, without using dragBody().

Now, nnowing that those objects are inserted into the scene group, and now that I’m using physics.pause() : do I still need to remove and nil every physics object ? Or is there a risk of having a memory leak or something else ?

#8

i like to manually remove/nil everything anyway, i like to KNOW what’s being done, and when, and i reference count everything - just personal preference.  so i’m the wrong guy to ask “should i let the scene clean it up for me?” :smiley:  if there’s a problem you probably won’t notice it if just using physics.pause(), but if you need physics.stop() then it seems you’d want much tighter control.

i think that’s in part why joints are usually the problem, because they’re not display objects, and so scene can only remove them “indirectly” by removing the involved bodies.  so if that were to fail, for whatever reason, then you’d have a stranded joint just waiting to crash physics.stop().  it appears that’s not impossible, but it’s very hard to debug, as usually these are 1-in-a-1000 type situations.

fwiw:  double/triple-check your touch joint event code.  any chance you might overwrite and abandon an existing touch joint in “began”?  any chance you’ll try to reference a nil joint if you got a “move” after “ended”? (can happen on a real device)  any chance you might strand a joint if fail to get ended or cancelled?  (again, real device, say a phone call comes in mid-swipe and you suspend - any guarantee you’ll ever see the end of that event?)  any chance, if using multitouch, that you can’t handle the following event pattern:  begin1-begin2-move1-ended2-move1-ended1, et al?  (that is, did you handle those two begins and their out-of-order ends?)  etc

#9

Well, thank you for all the advices :wink: