Position of the actor at the moment collision starts..?

anchorson

Actor1 has linear velocity x =100
Actor2 is stable
I have set actor1 to display its own position.x and to stop when it collides with actor2.

So when actor1 collides with actor2, it displays its position.x at the exact moment of collision.

But every time i preview the collision, the position.x displayed changes slightly between 347.457 and 349.123.

Is there anyway to ensure the collision starts at the same position?

RThurman

The collision spot will be actor2.x - actor2.width/2
The position of actor1 when the collision happens will be: (actor2.x - (actor2.width/2)) - (actor1.width/2)

Hope that helps!
RThurman

anchorson

That's right RThurman, as long as the collision is of rectangular type. In theory the "actor1.x" should be "exactly" what you said. But the position changes at every trial. The range of change is;

[(actor2.x - (actor2.width/2)) - (actor1.width/2) -1.5] < actor1.x < [ (actor2.x - (actor2.width/2)) - (actor1.width/2) +1.5]

Now the problem is, there should not be a " range".

RThurman

I agree that there should not be a range. But when movement is based upon linear velocity -- there it is. I suspect that the GS linear velocity formulas use some form of Euler integration to calculate positions.

Since we can't have what we want, the above equation gives what we are looking for -- every time.

If there is another way to do it, I hope someone speaks up!

RThurman

anchorson

I guess you're right RThurman. Somehow GS misses the collision. Thanks for at least showing an interest.

MotherHoose

have you tried changing the density and friction of the actors?

or trigger velocity by state/condition of the overlap/collide rule (???)

Rule: when
Event: overlaps or collides with Actor2
--changeAttribute: self.Motion Linear Velocity.X   To:  0
Otherwise:
--changeAttribute: self.Motion Linear Velocity.X   To:  100

===
have our actors acquired kinetic energy ??? :-?

@};- MH

RThurman

have our actors acquired kinetic energy ???

No (and yes). My guess is that the imprecision is probably due to three interacting factors; 1)how GS determines position during any given clock update (probably uses Euler integration), 2) where in the clock cycle (and/or the event stack) the collision occurs, and 3) the formula that GS uses to determine that a collision should have occurred.


We all know that GS does not have pixel level collision. They are simply using a distance formula to determine that a collision should have occurred. For square collision, they are using something like:

if (actor1.x + actor1.width) - (actor2.x - actor2.width) < 0 then
....collision = true
else
....collision = false

For circular collisions they are using the same kind of calculation, but with radius in place of width.

All this adds up to just enough imprecision be noticeable. (And frustrating.)

RThurman

anchorson

@motherhoose

I have tried many ways to make sure. In my experience, every method yields a different result. Some larger and some smaller, but there is always a "range of positions". And density and friction should not effect detection of a collision (although I've checked for that too and yes it doesn't)
And by the way, I have experienced inconsistent collisions with the "Collide" behavior too. The starting velocities and positions of two actors are the same but resulting paths after collision are not always exactly reproduced. But this might be a problem with Box2d ( I don't want to blame anyone I'm just saying it could be )

@RThurman

I don't see how clock update or movement is related to Euler integration. It is quite simple in my mind. If you have an actor with say 100 pixel/sec velocity, you use a function where you update the position of the actor every frame or "Timedelta" and increase it's position 100*(Timedelta/sec).
You also check for a collision every "Timedelta" and if a collision is detected at a frame, you simply stop the movement function. But of course this is possibly a very primitive way of updating position. I wouldn't know. Yet if you could elaborate as to how Euler integration fits in here I would be more than glad to learn.

Thanks in advance

RThurman

@anchorson
The steps you describe are what I meant by "some form of Euler integration". I did not mean to imply that GS is using the Euler formula. (Just some form Euler integration.) I just did a google search for "euler" and found the following explanation that might be relevant: http://gafferongames.com/game-physics/integration-basics/

You might find the RK4 method will give you more accurate results. (But you'd need roll your own using GS behaviors.)

However, despite whatever position integration scheme is used by GameSalad, there are still two other factors that I think might be influencing less than exact x positions for collisions; 1)the update cycle and 2)how GameSalad determines collisions.

RThurman

anchorson

@RThurman
Thank you RThurman. The explanation you have pointed was simple yet quite insightful.

RThurman

@anchorson
Glad you found it useful.

RThurman