Hey kaykry,

Can you detect the overlap on the bounding boxes, and then move the opposite of that? For example, if you detect that the bottom right corner of your player is overlapping the top left corner of the house, you'd calculate how far overlapped they are (let's say x = 3, y = -10), and then adjust the players position by x = -3, y = 10. I believe this will cover your diagonal movement with one direction overlapping case.

Hope that helps (and if it works, even better!),
James

okay i got lost on the explanation part of your code. lol But from first glance of your collision code, why not just break down your movement to single directions. If the player moves in a diagonal direction break it into two basic direction.

For example if the player moves upper-left, run your collision code twice. One for up and another one for left. That way you don't have to explicitly handle the diagonal cases.

Does this make sense? I hope this helps.

Also as a side-note, i've made a simple 2d game once. You can check it out here: uslslibrarysimulation.googleco…files/Poring%20Hunter.rar

The collision was pretty basic and i just needed to check for collision of enemy against environment objects; like a tree or rock. But the way i did it was using the Separation Axis Theorem (SAT). What's nice about SAT is that it works on all types of shapes as long as its concave. In the poring hunter game i just made a simplified convex shape that represents the trees and rocks. The guys who developed N made a very good article about SAT here: metanetsoftware.com/technique/tutorialA.html. I don't know if this helps but maybe if you adopt this kind of collision detection it might greatly simplify the way you do collision checks.

You can search for my SAT implementation somewhere in this project: uslslibrarysimulation.googlecode.com/. I can't get a copy of this project right now due to slow internet connection but i'll look it up for you once i have the time.

And also, i forgot to mention, the algorithm automatically handles the overlap and returns a vector for you to move your actor back to avoid the overlapping problem you have.

Assuming your character can always fit into 1 box, what if whenever you have a collision, you check for the nearest box the actor can occupy, and then move them into it? If you're moving diagonally into a corner, the game will end up picking a wall to slide around, but hopefully that's not a big deal? This of course creates a new problem to solve, which is how far do you move them towards that square?

James

I think one thing I would do is find adjacent collision tiles and consolidate them into larger, convex shapes like bigger rectangles and squares. That would be a wise optimization anyway.

The second thing I would do is calculate the angle of incidence between the the center of mass of the moving object and where it would enter a collision shape. The angle of incidence and the collision location would be used to direct your sliding movement.

I hope I haven't completely misunderstood the problem!

I think Rez said this earlier, but if you can make your house into just one polygon, then wouldn't that solve your issue?

James

A closed polygon can cover an L shape just fine, so that should still work for you. You could try looking in to line-polygon intersection. I remember finding a pretty easy algorithm for that, but I don't remember exactly what it was.

As for the door part, maybe have a trigger point (so another collision polygon, except it's passable, it just throws an event) and that could update the other polygon. Or better yet, just always make the door a passable area and have a trigger that automatically makes it open when you get close to it, and another trigger inside that switches levels/rooms/scenes/whatever?

James

Actually there is a good polygon collision algorithm in the 4th edition in the UI chapter, right after it talks about box collision.

Man, that brings back memory from my end of studies project : The Legend of Zelda Revival 2011.

It was a 2D game of Zelda in which I used the assets from the Gameboy games, and I did all of the code with the XNA framework. It could run on PC and Xbox 360. I ran into a similar problem with the colision system.

At first, I tried moving the player when he collided with a Tile that he couldn't walk over, but I would get stuttering or odd behavior around corners. The solution I found was to just not move the player at all. Let me explain, I used a variable called NewPosition, which was set by the movement of the player, then I would check if the movement was valid. When the new position was valid I would move the player, otherwise, he would stay where he was.

The original code was in C#, so here is a Pseudo-code(ish) version:


CollisionPlayerMap():

Of course, this is a simplified version of the algorithm. For example, the "For Each TilesY" only checks the Tiles that the player bounds are touching, not every Tiles in the world.

I'm not sure that I am very good at explaining, and my "pseudo-code" doesn't looks like pseudo-code (I don't like pseudo-code very much). But this was my take on the problem, I hope it helps and I hope it is understandable.

I really like Dude888's point. For being able to move along a wall while attempting to move diagonally, I'm guessing you might be able to do something like he said but with 3 checks. First check the diagonal, and if that fails, just individually check the horizontal or the vertical. If one of those passes, just move in that direction only, otherwise don't move at all. As for which line to check, if you're moving up, the top line of your bounding box, right the right line, up-right both those, etc.

James