yReference and physic colision

try to track colision of rotating objects.

Since setting x and y on enterframe has way too much impact on performance, I tried 2 tricks, both using object:rotate() on enterframe far more efficient.

The first trick is to set a pivot revolution. But this trick is no longer working since box2D update (see this post : https://developer.coronalabs.com/forum/2012/09/05/physic-behavior-between-sdk-840-and-sdk-894)
As nobody can find a solution, it’s a dead end.

The second trick is to do revolution via setting yReference.
As explained in the code below, physics object show rotating, but colision event dos not launched … (even when square reach the center of the screen, real xy of rotating rectangles…)

So, what is the solution ?

[code]
– setup :
local physics = require “physics”
physics.start()
physics.setGravity( 0, 0 )
physics.setDrawMode( “hybrid” )

local center = display.newCircle( 160, 240, 5 )

local function doObjectReference( angle, distance)
– the object :
local object=display.newRect( 0, 0, 5, 30 )
object:setFillColor(200,0,200,255)
– place the object

object.yReference = 240-distance
object.x = 160
object.y = 240

object.name=angle

object:rotate(angle)

– physics for collision
physics.addBody( object, “dynamic”, { isSensor = true, radius=20,density=1, friction=0 } )
return object
end
local objects={}
for i=1, 5 do
objects[i]=doObjectReference(math.random(360), 150)
end

– CHECK COLLISION

local function squareEvent( self, event )
local object = event.other

if ( event.phase == “began” ) then
print(“collision”,object.name)
self:setFillColor(math.random(255),math.random(255),math.random(255),255)

end
end

local square =display.newRect( 160, 90, 50, 50 )
square:setFillColor(0,0,200,255)
physics.addBody( square, “dynamic”, { isSensor = true,density=1, friction=0 } )
square.collision = squareEvent
square:addEventListener( “collision”, square )

– MAIN LOOP
local function mainloop( event )
for i=1,#objects do
objects[i]:rotate(5)
end
end

– PAUSE :
local text = display.newText( “PAUSE”, 0, 0, native.systemFont, 30 )
text.x = 160
text.y = 460
text:setTextColor( 255,110,110 )
local isPause=false

local function pause( event )

if event.phase == “began” then

if isPause==false then
Runtime:removeEventListener(“enterFrame”, mainloop)
isPause=true
text.text=“PAUSE”
square.y=100
else
Runtime:addEventListener(“enterFrame”, mainloop)
isPause=false
text.text=“RUNNING”

print(“run”)

transition.to(square, {time = 2000, x = 160, y=300})

end

end

end

text:addEventListener(“touch”,pause)

[/code] [import]uid: 9328 topic_id: 31459 reply_id: 331459[/import]

… [import]uid: 9328 topic_id: 31459 reply_id: 125784[/import]

Happy to try to help, but could you clarify specifically what your question is? What exactly are you trying to accomplish, and what is the problem you’re facing?

  • Andrew [import]uid: 109711 topic_id: 31459 reply_id: 125797[/import]

Thx.
I explained before my code sample : colision don’t occur (between my square and my rotating rectangles). [import]uid: 9328 topic_id: 31459 reply_id: 125809[/import]

Hi there,

When I run your code, the collision event does fire when the square reaches the “real” x,y of the rotating shapes.

If you change [lua]objects[i]=doObjectReference(math.random(360), 150)[/lua] to [lua]objects[i]=doObjectReference(math.random(360), 240)[/lua] (which makes the yReference 0), you’ll see that the collision event does fire exactly when the square first collides with the circle.

  • Andrew [import]uid: 109711 topic_id: 31459 reply_id: 125823[/import]

“When I run your code, the collision event does fire when the square reaches the “real” x,y of the rotating shapes.”

Yes I know, and that’s the problem :

  1. I wish the colision occur on the “visible” (as opposed to “real”) position of the target
  2. why “hybrid” mode physic shapes are not on “real” x,y ? There are on “visible” x,y, so maybe the colision could behave the same way ?
  3. the colision event fired on “real” coordinates is absolutely useless in my yReference trick for revolution… [import]uid: 9328 topic_id: 31459 reply_id: 125827[/import]

Well, unfortunately, a “trick” is a “trick”, and in this case it unfortunately doesn’t work.

I’d suggest defining the objects without a change in their reference point, and update their x,y positions directly (or by using translate) so that they rotate around your center point. I know you mentioned you think this would have performance issues, but I very much doubt it (unless you have a very large number of objects on the screen).

  • Andrew [import]uid: 109711 topic_id: 31459 reply_id: 125829[/import]

Andrew, thx for the feedback, but difference between setting coordinates on enterframe and just rotate them has a huge impact in my project, from sloppy and ugly to fluid and fast… [import]uid: 9328 topic_id: 31459 reply_id: 125841[/import]

… [import]uid: 9328 topic_id: 31459 reply_id: 125784[/import]

Happy to try to help, but could you clarify specifically what your question is? What exactly are you trying to accomplish, and what is the problem you’re facing?

  • Andrew [import]uid: 109711 topic_id: 31459 reply_id: 125797[/import]

Thx.
I explained before my code sample : colision don’t occur (between my square and my rotating rectangles). [import]uid: 9328 topic_id: 31459 reply_id: 125809[/import]

Hi there,

When I run your code, the collision event does fire when the square reaches the “real” x,y of the rotating shapes.

If you change [lua]objects[i]=doObjectReference(math.random(360), 150)[/lua] to [lua]objects[i]=doObjectReference(math.random(360), 240)[/lua] (which makes the yReference 0), you’ll see that the collision event does fire exactly when the square first collides with the circle.

  • Andrew [import]uid: 109711 topic_id: 31459 reply_id: 125823[/import]

“When I run your code, the collision event does fire when the square reaches the “real” x,y of the rotating shapes.”

Yes I know, and that’s the problem :

  1. I wish the colision occur on the “visible” (as opposed to “real”) position of the target
  2. why “hybrid” mode physic shapes are not on “real” x,y ? There are on “visible” x,y, so maybe the colision could behave the same way ?
  3. the colision event fired on “real” coordinates is absolutely useless in my yReference trick for revolution… [import]uid: 9328 topic_id: 31459 reply_id: 125827[/import]

Well, unfortunately, a “trick” is a “trick”, and in this case it unfortunately doesn’t work.

I’d suggest defining the objects without a change in their reference point, and update their x,y positions directly (or by using translate) so that they rotate around your center point. I know you mentioned you think this would have performance issues, but I very much doubt it (unless you have a very large number of objects on the screen).

  • Andrew [import]uid: 109711 topic_id: 31459 reply_id: 125829[/import]

Andrew, thx for the feedback, but difference between setting coordinates on enterframe and just rotate them has a huge impact in my project, from sloppy and ugly to fluid and fast… [import]uid: 9328 topic_id: 31459 reply_id: 125841[/import]