Collision Overlap On Grid [SOLVED]

(Daniel Berg) #1

Hello. I was wondering how to get the overlap/depth on a given axis when a hitbox collides with a tile in a Grid. Pardon if the solution is something I should have gleaned with some experience, but I’m fairly new to flashpunk and actionscript in general.

(Jacob Albano) #2

This doesn’t answer your question, but I think it might help solve the underlying problem.

What I’m assuming is the problem is that you’re trying to move your entity until it collides with the grid, and then stop with the entity flush against the grid. If this is the case, you can use moveBy() to automatically handle collision instead of moving on X and Y directly and doing your collision checks manually.

Here’s an example. This code would go in the update() function of your moving entity, and I’m using “grid” as the collision type of your grid entity.

moveBy(speedX, speedY, "grid");

If that doesn’t solve your problem, or I’m assuming too much about your setup or knowledge, I’ll do what I can to help further. Welcome to the forums!

(Daniel Berg) #3

Thank you for your answer and welcome :slight_smile: Unfortunately this does not solve my problem. Im aware of moveBy() and it is indeed a fine method. My problem is that the entity at this point already collides with the grid, and I wish to move colliding entity out of the grid postmortem so to speak. What happens is that im setting the hitbox for the player entity a new during game, and in some circumstances an overlap is bound to happen. What im trying to do is push the player out of the grid again. Im working on a solution atm that continues to test for an overlap in a given position, adjust the desired position and test again until im clear, resulting in a final value I can give to the player. Problem with this as I see it is that its alot of unnessesary collision checks. In other collsion systems I have used it was based on rectangle collision so that calculating the overlap between two rectangles was fairly simple.

(Daniel Berg) #4

Ok, seems I managed to solve it. Im not wholeheartedly satisfied with the solution but it works for now. Heres x axis method:

    private function alignX():Number
    {
    	var lX:Number = x;
    	var rX:Number = x;
    	while (true)
    	{
    		if (!(collide(solid, ++lX, y))) return lX;
    		if (!(collide(solid, --rX, y))) return rX;
    	}
    	return x;
    }

Did I paste this in correctly? im not a avid forum poster. Anyways, the code is still unfinished and any suggestions on improvement is appreciated. The while loop there is a placeholder until I find something more robust, as its surely gonna cause some manner of trouble.

(Jacob Albano) #5

I was afraid of that. :confused: The problem with grids is that there’s no way that I know of to get the cells you’re colliding with, and obviously a regular hitbox intersection check won’t do any good.

That function looks like it will do the trick, but I agree that the potential number of collide() calls could be a problem. Hopefully someone else has another idea.

Your code pasted in just fine, by the way. If you want to give it syntax highlighting, you can do so like this:

```actionscript
// your code here
```
(Daniel Berg) #6

I’ll continue to post my findings, but I’m on a short timeframe with this project so I got little choice but to move on. I’ll address the problems as they arise. Thanks muchly for your input :slight_smile: Now its time for some much needed sleep.

(Daniel Berg) #7

I marked this as solved, but if anyone have any suggestions on how to improve my solution, I’m all ears. As mentioned in a previous post I’m not satified with the solution. I wish to accomplish this without resorting to doing a continual collision check.

(azrafe7) #8

In AS3 you can easily get the overlapping region between two rectangles by using Rectangle.intersection(). The drawback is that, in your case, you’re using a Grid, so you’ll need to check for intersection with a set of rectangles.

Don’t know if you could benefit from knowing the actual colliding grid cells but… even if Grid gave a way to know with which cells you were colliding (which could be any number from 0 to 9 - assuming your player’s hitbox could grow up to twice the size of a grid cell), you’d have to handle the intersection with all of them and decide if it’s the case to move the player up/down/left or right (if the Entity is colliding on its left and on its right, where will you move it?).

Furthermore you’ll have to consider the offsets (of both the masks and the entities) involved in the collision.

So… depending on the constraints you have (maybe your player Entity is always smaller than a grid cell and will either collide to the left or to the right?), it would be possible to roll down a custom/optimized Grid vs Hitbox implementation (maybe involving hacking the core of FlashPunk - see Grid.collideHitbox()).

Or maybe replace the Grid with single Entities with hitboxes (bah… unlikely).

tl;dr: Unless you’re encountering some performance issues, or bugs in how the collisions are resolved, then I think your method is a nice workaround.

PS: Just out of curiosity… could you explain why the hitbox grows without the entity moving - what’s the game mechanics behind that?

(Daniel Berg) #9

I did find out about the Rectangle.intersection() function in an earlier attempt to solve this issue. I figured If I could get the position of the cell the player was colliding with, I could create a rectangle and test it against the hitbox. I have been flailing abit with this issue but ended up using the solution I posted as it works as intended and took me the least amount of time figuring out. I would go deeper into this but I’m participating in a norwegian game jam/contest so I had to move on due to time constraints.

To elaborate abit on why I need this feature: I’m making a platformer game where you can rotate the level in 90 degree increments.One way the game rotates is that the world is rotated but the player is not. Now in the game I dont actually rotate anything but the screen by setting the FP.screen.angle value. So I when the screen is rotating but the player is not, I actually rotate the player sprite to correspond with what the person playing the game perceive as the correct orientation. Due to this, and the fact that my hitbox is indeed a rectangle, not a square means I need to adjust the width and height of said hitbox. What was the height is now the width and so on. As you can probably gather by now is that when the player is flush against a wall and I rotate towards this wall the rectangle is gonna end up being partially inside the wall. Another issue is that if player is squeezed between two walls and I try to rotate I simple dont allow for any rotation other than the feedback that rotation was cancled. Another thing worth noting is that since I only allow rotation in one direction and increment at a time it allows me to controll which axis needs realignment. I hope this sated your curiosity :smile:

tl;dr: I’m not really seeing any decrease in performance, or bugs for the time beeing (although I might inded encounter something) This is more about the fact that I thought there was another way of doing this that eluded me, since this is only my second game, and first platformer using flashpunk. A previous platformer I coded in C# and collision system was based around collision depth on rectangles, so I couldn’t get my head around where this depth value was. But I soon figured out that grid collision is handled abit differently.

Wow, that got abit winded. I will post a link to the game when its finished (or I run out of time, what beeing more likely) so anyone intrested can see exactly what I’m doing.

P.S: Not sure I understood what you ment by “consider the offsets”