35

The solution is actually simpler than expected. The trick is to use Minkowski subtraction before your hexagon technique. Here are your rectangles A and B, with their velocities vA and vB. Note that vA and vB aren't actually velocities, they are the distance traveled during one frame. Now replace rectangle B with a point P, and rectangle A with rectangle C =...


34

I think you'll have to take the box's movement into consideration. That is, only crush if the box is moving towards the player. This is similar to other problems in platformers, where the movement is important. E.g. for platforms that you can jump through and onto from below, don't check collision if the player is moving upwards. So a block can crush the ...


17

First of all, in the case of axis-aligned rectangles, Kevin Reid's answer is the best and the algorithm is the fastest. Second, for simple shapes, use relative velocities (as seen below) and the separating axis theorem for collision detection. It will tell you whether a collision happens in the case of linear motion (no rotation). And if there's rotation, ...


15

Independent of feasibility (yes, depending on scale) there are often better or easier ways. For instance, in your typical MMO, the server really only needs to know about the coarse navigation map used by AI and player pathfinding. Instead of storing the location of a tree, you can instead just cut a hole into the navmap at the location of the tree. Likewise ...


14

Scenario It seems your pathfinding and collision detection have different ideas of what's OK, when it comes to walking around corners. Say your pathfinding plans out this path (brown squares are walls, yellows are empty space, green is an enemy character, arrows are the planned path): The enemy character then moves directly toward each point from the ...


11

There are three general approaches to dealing with stairs in video games: The "Mario" approach is that you must jump to get up stairs. The "Castlevania" approach is that moving up/down stairs is a different sort of movement; you must press 'up' on the controller, and a special "stair-climbing" animation is played to traverse the stairs. A variant of this ...


10

If you're able to rotate the boundingboxes, I would've put a 45 degree rotated box at the player's feet and combine it with one non-rotated box to represent the rest of the body. That could make the player automatically slide over anything small enough. Though, that would probably cause some clipping with the player model and the stairs. Another idea is to ...


9

Generally the way most physics engines handle this problem is by separating the intersecting objects. So if your objects are represented by rectangles (also known as "Axis Aligned Bounding Boxes"), and they collide on a given frame like so: You would then measure the amount of interpenetration on each axis. Then select the axis with the smallest ...


9

Have the "crush test" points be inside the gray box shown in your image #1 - i.e. kill the player only if you detect a hit on one of the pixels there.


8

( Edit : the method above works only for square AABB, i'll have to think on how to improve it, sorry ) Fastest way is to : - A) test circle against rect's outer bounding circle -> reject if too far. - B) test circle against rect's inner bounding circle -> accept if near enough. - C) test that the outer point of the circle (on the line joining both centers) ...


7

Your solver needs multiple iterations (aka sequential impulse) over its contacts. Treat each contact point independently and calculate the impulse to resolve its contact constraint for that iteration. This may cause previously resolved contact points to be pushed back into the colliding object, but not by as much as the initial penetration. Perform ...


7

What you have here are two constraints that need to be resolved. On one hand, you need the sphere to stay outside the wall, by pushing it along the normal. On the other hand, you have the constraint that the sphere needs to stay attached to the ground. If you don't want to try writing fancy solvers, the easiest way to do this is to use an iterative solver. ...


7

Yes - it is feasible. MMOs often split the game world into multiple areas, as this makes the job easier, but you can still do it with 1 massive area - you just need to use a good spatial partitioning scheme. Because most objects in MMOs don't move, you can also perform a preprocessing pass where objects are used to create collision checking trees. Memory ...


6

The problem The problem lies in your method of collision resolution. Your method goes as follows: Move the player. Check for collision. Determine the shortest collision depth. Resolve collision. The problem with this, is that it can easily move the player in the wrong direction. You can see how this might happen in the image below: Because the player is ...


6

As someone who grew up with 80s platformers, my first comment is that the contact points must be exactly on the sprite, not anywhere outside it. There were few experiences more frustrating than dying when a weapon/crusher/enemy was clearly several pixels away from your character - and that kind of experience is what stops people playing. With that in mind, ...


6

The angular velocity vector you've computed using the method you've shown gives you two things: The direction the vector points is the axis of rotation The magnitude of the vector is the speed of rotation (typically in radians per second) So, to rotate the object, you can take: // Separate axis and speed into separate variables. float angularSpeed = ...


5

I think the problem is that in one frame the objects move fast enough to pass through each other. Behold my ascii art: Frame 1: a is heading towards b +-------+ +-------+ | A | | B | +-------+ +-------+ Frame 2: +----+--+----+ | B| |A | +----+--+----+ At this point the collision response moves them away from each other but the ...


5

The basic concept, used for many years now, is to just send out ray (really, line segment) queries from your character. If the character has gravity applies or is moving donwards, shoot two rays from the bottom two corners of the character's collision box and see if anything is close. You can react differently depending on which of the two registers a hit. ...


5

So the first thing I noticed was that when you do previousTouch = currentTouch; currentTouch.Clear(); this should also clear previous touch since List is a reference type. The second thing is that there is no space partitioning so your collision check currently runs in O(n^2) as best case runtime. The third thing is that it's weird that you calculate the ...


5

The first problem where the collisions were handled wrong, were solved with this solution posted by David. Instead of solving the two axis at the same time, the solution solves each axis individually. So, instead of sum the velocity at the position and handle the collisions, I sum each velocity and handle the direction: if (_velocity.Y != 0f) { Position ...


5

The "velocity vector" is the difference between the velocities of the two objects. When colliding with a static (unmoving) object (such as the level), the "velocity vector" is indeed its current velocity. Normally, the collision surface's direction will be represented by a "normal" -- a vector of length 1 that points in the direction the surface is facing. ...


5

This is probably the simplest 3D collision check. Distance between sphere centers is length(c1.center - c2.center) Depth is distance - radius1 - radius2 = length(c1.center - c2.center) - c1.radius - c2.radius Normal is normalized(c1.center - c2.center) for c2 and the inverse of that for c1.


5

There are continuous and discrete physics/mechanics. I do not know which one you are doing. Their main difference is in the detection, which you already have done. Thus, I will skip finding candidate pairs, and skim over the detection process, and then explain the response part. With that said, the response has two parts: Find the collision instant Resolve ...


4

An impulse is an instantaneous change in velocity. You can calculate the velocity of a point before and after an impulse has been applied to the body. The velocity of a point is: V = Vcm + omega cross r V is the velocity of a point on a rigid body. Vcm is velocity at the center of mass. Omega would be angular velocity, and r is the vector from center of ...


4

The answer is to not use just SAT and plain physics/collision handling but to add a large mass of character-specific collision-handling code. Platformers are special beasts with special rules. As the player moves, remember that he is on the ground. Adjust along the slope horizontally then snap the player back onto the ground afterward. Otherwise you end ...


4

You shouldn't go through all tiles. Go through all characters instead, and do the collision checks and correction against blocks in there. Moving blocks shouldn't be considered blocks, but rather a character that moves, and pushes other characters. Do the static block collision AFTER the characters moves and collided and got pushed.


4

The minimum y offset can be calculated with the minimum overlap: The blue line is the MTV from the SAT algorithm, the red line is the minimum Y offset. phy::vect2D c = phy::_poly_collision(p1,p2); if(c.y != 0 && c.x != 0) { p1.y_pos += ((c.x*c.x) / c.y) + c.y; } else { p1.x_pos += c.x; p1.y_pos += c.y; }


4

Usually collision that happen due to the result of resolution will be resolved on the next simulation loop. Most games (basically all of them afaik) do this. The only time I would think about solving collisions that are caused by resolution, within the same frame, is if interpenetration is something that is fundamentally banned by the physics simulation. ...


4

Don't set the position explicitly. When you set properties like position and even velocity, you do so outside the physics loop, so it has no chance to correct itself within the current frame, so you see jittering behaviour. In other words, in the current frame you'll reposition the body, possibly colliding into another body, and the physics system must ...


4

I've been thinking about this problem for a long time and looked at some of the answers here and on other forums. I came up with the following idea: Suppose the circle has radius R. When looking at cases where the circle collides with the AABB , the center of the circle has to fall within a certain area around the AABB. The extreme cases are when the center ...


Only top voted, non community-wiki answers of a minimum length are eligible