Physics during transitions

Games
#21

Thanks Mike… I do understand what you are saying. I was moving away from transition.to to setLinearVelocity, and the object seemed to move to the location on the screen where I tapped. It kept moving past the tap point (naturally), so I can check to see when to stop the object and set velocity to 0

That being said, using velocity, how do I move the object a consistent speed? If I tap far away from the object, the object rushes to the point. Closer taps, and the object crawls towards it. [import]uid: 114363 topic_id: 30265 reply_id: 121265[/import]

#22

Do you apply the same linear velocity to the object no matter what the distance is? If you want the same time in transit, you have to make the linear veocity directly proportionate to the distance (that is, multiply it by the distance). [import]uid: 160496 topic_id: 30265 reply_id: 121268[/import]

#23

Yes, I did apply no matter what the distance. I need to play around with my math a bit, it seems.
Thanks… I think this will help me quite a bit. [import]uid: 114363 topic_id: 30265 reply_id: 121271[/import]

#24

Do not use transitions with physics objects unless you first (a) turn off the physics properties by setting isBodyActive to false or (b) make the object a static bodyType.

[EDIT] Using transitions on dynamic physics objects creates a situation where you are trying to force your will upon the physics world. It’s the classic “immovable object meets irresistible force” catch-22. You will experience objects which might disappear but still have an effect in the physics world - among many other very odd side-effects.

If you want a regular, dynamic body to move from one point to another and still have all the regular physics world interactions, simply create an invisible display object (which is not a physics object) and use a transition to move it from A to B.

When you create the display object (eg: a circle) create it in the same place as the body you want to move. Create a touch joint at the same location on the physics body object. Then, set either a timer to fire once every 100 milliseconds (play with the value) and call setTarget on the touch joint when the timer fires.

When the transition’s onComplete event fires, remove the touch joint and the non-physics display object.

The above should create a similar effect to a very steady hand moving the physics object across the screen using a regular touch joint. You will definitely need to play with the values though.

Please post the code when you get whatever solution you eventually find working. [import]uid: 8271 topic_id: 30265 reply_id: 121290[/import]

#25

that’s a lot of work if you want to move things around and see if they bump each other. A game I’m currently working on has a car that drives around a city map (over head view). It’s a royal pain to try and map all the places the car cant drive when the physics editor lets me click on non-transparent areas and it figures out all my collision shapes for me. To use these collisions I have to use physics even though there is absolutely no other physics going on.

I was touch-dragging the car, but ended up switching to a joystick. So I’m moving my dynamic physics body outside of physics just so I can get collisions.

Hopefully Corona Labs is watching this thread. This is why we need a solid non-physics based collisions engine.
[import]uid: 19626 topic_id: 30265 reply_id: 121292[/import]

#26

@horacebury,
Thanks so much for your post… I never considered using a touch joint but after going back to the documentation and reading about touch joints, it looks like this would work in my situation.

I am going to read a bit more, and then will implement this to see if this solves my problem. I knew transitions were not the correct method but couldn’t figure out an alternative.

I hope to get something working in the next day or so and will post my results.

Thanks to all who responded… This really helped me learn quite a bit.

–John
[import]uid: 114363 topic_id: 30265 reply_id: 121299[/import]

#27

Hi John,

I agree with the touch joint method. This will move your object around really nicely, with a sort of “fast to slow” movement based on the joint parameters you set (like a rubber band is pulling your object to the exact location it needs to be). And it will ensure that your collisions remain intact and sensing. I’m basically positive this is the best method for your scenario.

Brent
[import]uid: 9747 topic_id: 30265 reply_id: 121314[/import]

#28

Collision detection can be done many ways. IMHO, to ask Corona to implement a collision system which simply equates to “make it easy for me to detect when my images overlap (or get close)” is asking them to spend time away from tasks we really need.

If you don’t want to use physics objects per se but still want physics style collision detection, set your bodies to be static and set isSensor=true while moving them with transitions etc.

Yes, it still uses the physics engine, but you’re also utilising a low-level (ie: below lua) engine for complex polygon collision detection, instead of using a custom method. It’s not a bad trade off. If Corona were to provide a collision system which was effectively the above but without the Box2D library being loaded, what should it be? [import]uid: 8271 topic_id: 30265 reply_id: 121317[/import]

#29

Personally, I’m fine with the current collision detection method(s). I don’t know how much “weight” it adds to an app to include the physics engine (performance-wise and also compiled app size), but in my experience, it’s worth the slight penalty for what is gained overall.

Perhaps what many Corona devs expect, or assume should be present, is a pixel-based collision system versus a “body-based” system. I think this would be useful in some apps, i.e. if you’re making a “tiled maze game” with tons of individual boundary blocks or something. Using the current system, you need to draw a body for every block (or place complex bodies spanning around many blocks, and they can’t be concave or greater than 8 points, of course!). From a developer’s standpoint, that can be alot of extra work, especially if you have dozens of levels or if levels are randomly generated.

That being said, when Corona Levels (the level designer tool) becomes available, it should help streamline the physics body setup and allow for drawing physics shapes in “real time”.

At this point I can’t say that I feel strongly either way. I haven’t yet needed a “pixel-based” collision system, but maybe in the future I would find that very convenient, and I’d be urging Corona to add that in. :wink:

Brent
[import]uid: 9747 topic_id: 30265 reply_id: 121359[/import]

#30

I never considered using a touch joint but after going back to the documentation and reading about touch joints.home tutor [import]uid: 176241 topic_id: 30265 reply_id: 122780[/import]

#31

I never considered using a touch joint but after going back to the documentation and reading about touch joints.home tutor [import]uid: 176241 topic_id: 30265 reply_id: 122780[/import]