Collisions that aren't AABB

[Mads]

I know how to do a proper sidescroller like the old Mario, where the collisions are just AABB. It's pretty easy.

Now I want to do something different, and have a terrain that's not boring. How would I go about making my character walk on a slope, for instance? I bet there's tons of material on this, but google-fu only returned a low-quality actionscript-riddled solution that's just not feasible in the long run.

Thanks in advance.  

EDIT: I posted this on the wrong board  Sorry! Meant to post in "Newbie questions".

[Cero]

I know how to do a proper sidescroller like the old Mario, where the collisions are just AABB. It's pretty easy.

Now I want to do something different, and have a terrain that's not boring. How would I go about making my character walk on a slope, for instance? I bet there's tons of material on this, but google-fu only returned a low-quality actionscript-riddled solution that's just not feasible in the long run.

Thanks in advance.  

EDIT: I posted this on the wrong board  Sorry! Meant to post in "Newbie questions".

really really depends on how you do it
every part of the slope can be a triangle; then do rectangle triangle collision detection. or just line intersection...
the could also be internally boxes and push you up or down a certain amount...

[Mads]

every part of the slope can be a triangle; then do rectangle triangle collision detection. or just line intersection...
the could also be internally boxes and push you up or down a certain amount...

I know how to detect a collision. I'd like to be able to push my character along it, though. I'd rather not have a million small boxes

I think what I need is a way to pull where on the y-axis my character is, if he's on x10 on a slope going from (0,0) to (30, 30). I still wouldn't know how to push him along when walking though 

Games published by our own members! Check 'em out!

[Damocles]

well, if the endpoint of the x-movement is inside the triangle, and the triangle has a 45degree slope,
the endposition is the hight of the triangle at this point.

Lets say its a slope going upward to the right, and you move right.
First check if the endpoint of the character is on the tile with such a slope.
If yes, check at wich % point of the tile he ends up.
Then do an interpolation how high it is there.

-> if the char is moving right, you need to check this for the lower right point of your collision box...
Or check it for both sides, and apply the highest hight.

(if the tile is 1 wide, and the endpoint is at 0.8, then the hight after pushing would be also 0.8 higher than the bottomline of the tile)
For a 45/2 degree slope (over 2 tiles), it would be 0.4 high.

Cant pull out some example code now. But it should be easy to develop it from here.

Just look at all the side conditions:

if the endtile is "full", but the char is currently on a slope, the char will end up on TOP of the end-tile.
If there is no slope, he would collide already with the edge of the tile.

[Cero]

its easy to code per se, but hard to get really right, without wasting too much performance with pixel iterations
especially with jumping, landing, running down and up - all cases have to work

[UprightPath]

You can easily do slopes that are AABB based!

I mean everything in my platformer is based off of that. It just takes a little bit more finesse.

[Mads]

You can easily do slopes that are AABB based!

I mean everything in my platformer is based off of that. It just takes a little bit more finesse.

Could you perhaps elaborate on that?

[UprightPath]

Well, let's say you have a tile. This tile will have information about the 'relative' heights across the entire tile based on the 'size' of the tile.

1   2   3   4   5   6   7

public class Tile {     public float angle;     public int[] heights;     public int getOffset(int offset) {         return heights[offset];     } }

Then you have your Entity, it's standing a x and y.

1   2   3   4   5   6   7   8

int tileX = x / tileSize;     int offsetX = x % tileSize;     int tileY = y / tileSize;     int offsetY = y % tileSize;     Tile tile = getTile(tileX, tileY);     entity.setY(tile.getOffset(offsetX));     entity.setSpeedX(Math.applicableTrigFunction(tile.getAngle()) * someConstant);     entity.setSpeedY(Math.applicableTrigFunction(tile.getAngle()) * someConstant);

This is a 'basic' method for doing it. If you really want a chunk of source code that manages this, I can probably make one of the older iterations of my platformer's code available. It uses this method (Well, a fancier version that finds the highest point between the character's left edge and right') . Basically, it allows you to turn your tiles into semi-height maps.

[Roquen]

More generally, like quadtrees & uniform grids, the primary role of aligned or oriented boxes (tree based or individual) is to provide a quick rejection prior to performing the "complex" intersection, collision, whatever-else check.

[Mads]

Well, let's say you have a tile. This tile will have information about the 'relative' heights across the entire tile based on the 'size' of the tile.

I see, thank you very much! That helped a lot.

More generally, like quadtrees & uniform grids, the primary role of aligned or oriented boxes (tree based or individual) is to provide a quick rejection prior to performing the "complex" intersection, collision, whatever-else check.

You're right, I should stop thinking in the box so much.

Games published by our own members! Check 'em out!

[Ultroman]

I did a little project and wrote up the way I did it here. I made it so a tile just has a point in each side, and use the line between them to find the Y. It works very well.
Looking at the suggestions here, though, it seems easier to code a collision-system using tiles that have an array of Y-positions for each X, but that also means you have to manually design each tile with different Y positions. Unless you in some clever way generate it by finding the highest point for each X that isn't transparent in the tile image.

[UprightPath]

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24   25   26   27

public enum TileType { // Have a bunch of different tile collision arch types here! Make them enums to be accessed easily. :3 Or, however you want to, but it's important that they're singleton access. private int max; private int[] height = new int[32]; public int getFromLeft(int offsetX) {     int max = 0;     for(int i = offsetX; i < 32; i++) {         max = Math.max(heightTop[i], max);     }     return max; } public int getFromRight(int offsetX) {     int max = 0;     for(int i = 0; i < offsetX + 1; i++) {         max = Math.max(heightTop[i], max);     }     return max; } public int getMax() {     return max; } }

From there, you can manually declare each TileType's Ys and access them quickly. For certain things, it's fairly easy to come up with the height formulas. I mean it's just rise-over-run for the most part. But, it also allows you to have stair based collisions (So that your character will actually 'stand' on the flat portions of stairs, instead of following an incline up them) as well as arbitrarily designed tile configurations. This is important if you want to have relatively large tiles.

[Mads]

I have decided that I'd rather go with tiles. I want to then define only the two top-vertices, and from that I can derive the slope. Then it's just basic line math. Bim bam boom!

I figured I could do it upside down for a roof.

Thanks guys. Cheers!

[Roquen]

Generalized line equation is your friend.

[Mads]

Generalized line equation is your friend.

True I think I'll wait a bit with this, though: