Collision check on stationary object (only events)

How is it possible to check collisions on a stationary object being bombarded by other objects, but using only events no behaviours.

Also the object that is stationary, is the player and he can be stationary and in motion as well.

I am having trouble figuring out how to work this out in both states - in rest and in motion.

Is it possible to check on which side of the player sprite the overlap of an enemy sprite is happening? (so that the player is not penetrable by the enemy objects).

As the player moves he does not use vector motion (which would be helpful for angule check) to push himself, but a self.X+60*dt and self.Y+60*dt (which is necessary for this situation for certain reasons).

The idea behind this is just to make the player object unpenetrable, no bounce at this stage.

I have been sitting on this one trying certain solutions without success.

All help is appreciated.

EDIT: The Objects are rectangles that are parallel to each other, and not some fancy shapes.

What I am finding is that it is crucial to have the angle from which a box is colliding so it can be pushed back into that angle, which prevents it from overlapping. Is there any other option to implement such collision without having the angle specified, or having the object move per X=self.X*60*dt and Y=self.Y*60*dt and still be able to use the angle to stop the object fron overlapping?

When an object is stationary I assume is that we need to tell from which angle the enemy objects are coming in, and stop them per same solution, pushing them back from the angle they came from in order to stop the overlapping. Again how is this possible without having the angle?

I have been looking through the Seperating Axis Theorem, but it is a little way over my head at this moment.

You mean like rojohounds first example?

I have manged to get something going on but only for 1 axis.

LittleStain

Thanks for the link, my mind is blown.

However I see at first glance that there are angles being calculated here and there in the example, and as of now Im not sure if I can discard those.

I have to try and figure this one out, and try to implement it at least in some way.

Im off to try and make something of it.

You do have the vector though. If you're moving with:

Set X to self.x+60*dt

Set y to self.y+30*dt

The the velocity vector would be (60,30) and the displacement vector in one frame would be (60*dt, 30*dt). So the angle of motion would be angle(0,0,60,30).

The two ways to avoid collisions is either:

A. Use the displacement vector with the "overlaps at offset" condition to check if the object won't collide before moving it.

B. Move out of the object after it is found to be overlapping. I mentioned this in your other topic. The two common ways are to either move backwards till it's out or find the closest direction to move the out.

Their are pros and cons of each. With A you have to ensure that objects don't start overlapping, and you need to close the gap if the velocity is high. B is more common and reversing the motion is good for stopping whereas using the closest direction makes wall sliding easier.

Here is a simple collision resolver. All that's required is the X and y velocity the object is moving.

While

Sprite is overlapping wall

--- Sprite: move -1 pixel at angle angle(0,0,self.velocityX,self.velocityY)

The example in that link does a circle vs box collision resolution using sat with voronoi regions. If you've heard of the flash game N or N+, their website has a write up on the technique. It basically boils down to the distances between between the player and each corner and edge of the box is measured and the shortest distance is used. The distance() expression is used when comparing the distance to the corners and a vector cross product is used to find the distance to the edges. On a side note the motion is done with verlet inergration instead of Euler but that is a different topic.

Another advantage I like about using sat like in the link is I can calculate the exact position on the edge of the box to place the player. Whereas the example above is an iterative approach that can cause a gap up to a pixel between the objects, but you do get to use the object's collision polygon instead of treating it as a circle. I usually handle the gap by first moving out by pixels and then move back by tenths of a pixel till it's just shy of a overlap.

R0J0hound

After about 15 something hours I managed to implement a collision system based on your information. For now it will do, but I will be back

Once again my big thanks and a tip of my hat towards you.

You are one of the few people, thanks to whom this forum is running but you already know that

Ps. There needs to be a +rep system on this forum along with C3.