Collisions against sloped surfaces

Collisions against sloped surfaces
by tokumaru on 2010-04-25 (#60374)

In this post tepples mentioned he was looking for an efficient way to test this kind of collision, and then UncleSporky thought this was worth discussing, so I made this topic to share my findings in this area.

Games objects usually collide with everything else in the game (other objects and surfaces) through the use of a bounding box that represents its solid area. However, when you respect the object's bounding box and put it on a slope, it doesn't look very good:

The object will appear to be standing on air rather than on the ground. Some games compensate that with art, by drawing the ground above the logical collision surface:

This solution is quick but will probably make the levels hard to edit since the art is so different from the collision data. Also, it's not an optimal solution because depending on how wide the objects are they will still look like they are floating (too wide) or sunk into the floor (too narrow):

To fix this, the best solution I found was to use a central point (or a small segment between two points, but one point is simpler and appears to work OK) for collision with the ground:

Now the width of the bounding boxes don't matter, all objects will be adequately positioned on the floor. There is one big problem though: here's what happens when the object walks off a ledge:

Yup, it will fall while half of its body is stuck into the wall. Not good, huh? So you either let that ugly side effect happen or you suddenly push the object away from the wall to fix it, causing jerky movement. Both options suck, so I came up with a 3rd one: When the central point (or line) is not making contact with the floor, then you use the corners of the bounding box to check for collisions:

But the secret is to not allow the bounding box's corners to collide with slopes, they only collide with completely solid blocks (while the central point collides with solid blocks AND slopes). In the image above, it's like the slope has "guided" the game object to land on the solid block, and then it's like the slope doesn't exist anymore, because there's nothing below the central point. If the object keeps moving left, it'll eventually fall, but it won't be stuck into the wall.

To me it seems like this would work perfectly for all kinds of games. There are a few limitations though. For example, the slopes have to start and end connected to solid blocks. I mean, you can't use the side of a slope as a wall, because things like this would happen:

You can't have the end of a slope leading to nowhere like that. If you want your slope to lead to a pit, you have to add some "trimming". Something like this would do the trick:

All sorts of crazy slopes will work fine, as long as long as the complex shapes start and end on solid blocks. I like to think of the slopes as "decoration", something that makes the otherwise blocky areas more interesting, but the basic shape of the levels is still made of solid blocks:

I tried looking for existing games that behave like what I just described and the closest thing I found was Mega Man X (SNES). It doesn't have many slopes, and I have no idea of how they are actually implemented, but all the features and limitations I mentioned here seem to apply: After going down a slope that leads to a pit, Mega Man will move horizontally for a few pixels, like he was standing on a flat block, before falling (that's the "objects don't get stuck in the wall" feature). All the rising slopes that lead to pits I could find in that game have a flat area before the pit (that's the "the sides of slopes can't be used as walls" limitation).

Even if this isn't exactly what Mega Man X or any other game does, I still think it's a pretty good solution. I don't think the few limitations are deal breakers by any means, and the whole idea seems very simple to me, and easy to implement on top of an already working "bounding box to solid blocks" solution. Nothing about a working engine like that would have to be changed, only a new collision point and a new type of block (a block with a height map) would have to be added.

Please let me know what everyone thinks, if you have suggestions on how to improve this idea or if you can see potential problems I might have overlooked.

by Disch on 2010-04-25 (#60376)

I dunno.. having a collision system that explodes if you arrange your map a certain way isn't ideal, IMO.

I'm working on something like this right now, although it's for a PC game and not for the NES, so I don't have to be as limited in my calculations.

One idea I've been kicking around is having a 'V' bottom on the rectangle. So the rect actually has 5 points instead of 4.

My pictures aren't as pretty, but here's the basic idea:

I haven't worked out the details on how to actually make it work, though =x

by tepples on 2010-04-25 (#60377)

I'm still at the point where I'm trying to decide whether point (x, y) is within the terrain. What's the best way to represent a slope? Sonic 2 uses a set of n pixel heights, one for each column of a metatile. But I think some other games use a more "vector" method: represent it as a height at the left side and a height at the right

by tokumaru on 2010-04-25 (#60379)

Disch wrote:
I dunno.. having a collision system that explodes if you arrange your map a certain way isn't ideal, IMO.

Yeah, but I couldn't think of a good way to allow the sides of the slopes to be used as walls. If you look around you'll see that several commercial games had problems with this, so they either avoided the situation or left the bugs in. Take a look at what happens in Sonic 1 in a situation like this. Here's Sonic about to walk towards a pointy ledge:

It appears that a collision point close to the tip of his shoes is being used, as you can see as he goes up the slope:

But once that point has no floor below it, Sonic falls, and and a point at the back of his shoes makes contact with the floor and keeps him from falling further:

Now if you keep walking you can make Sonic go up the slope again, now using the other collision point:

When that second collision point is about to go off the ledge Sonic starts his balancing animation:

And after that he falls for real. Now look how Mega Man X 2 appears to avoid situations like this, by putting flat areas at the top of the ramps:

I have the impression that this is a notoriously hard thing to get right, and that programmers have always had problems implementing this on limited hardware. If anyone else can find examples in other games, please post them.

Quote:
I'm working on something like this right now, although it's for a PC game and not for the NES, so I don't have to be as limited in my calculations.

Yeah, you idea is very interesting, and OK for a PC game, but colliding with angled lines is probably too slow for the NES, possibly even for the SNES or the MD/Genesis I think.

by tokumaru on 2010-04-25 (#60381)

tepples wrote:
Sonic 2 uses a set of n pixel heights, one for each column of a metatile.

That is my approach, because it allows for more interesting surfaces than just straight lines.

Quote:
But I think some other games use a more "vector" method: represent it as a height at the left side and a height at the right

This might be doable, but I think it will be kinda slow if you have to trace a line (possibly with bresenham's algorithm) to connect the points. One thing that might be easy to do is specify how much the height changes from column to column using a fixed-point number. That way you can multiply that number by how far into the block your column of interest is to get the height of that column.

I really prefer to simply have a table with all the column heights though. Is it space you are worried about? If instead of hardcoding the height maps to the blocks that use them you make them reusable (have each block indicate what height map it uses), they will not take so much space. And you can probably use a single set of collision maps for the whole game, because different levels usually share many similar slopes.

by kuja killer on 2010-04-25 (#60382)

it's like that on my game too, about how mm and enemies will barly even be standing on the slopes at all, like just a pixel of their feet and no more.
a japanese person named Rock5easily coded the slope mechanics before that i could use in my rom hack well over 2 years ago, but i have no idea how to even modify it cause it's way too complex to me.

It sucks that it looks like that ..about barly standing on the edge like that, looks worse when walking though. I can't ever fix it on my own, as well as this very annoying issue when sliding on slopes, there's a small rare chance mm gets stopped immediately only when sliding. It's pretty annoying

by Kasumi on 2010-04-25 (#60383)

Here's how my system works.

I have "hard" and "soft" tiles. Hard tiles impede progress (0 your X velocity and eject you from the wall horizontally) when the left/right points are touching them. Soft tiles don't. (so you can move up slope tiles without being ejected horizontally)

You can land on hard tiles with your left/right points. You can't land on soft tiles with your left/right points.

Slope tiles are always soft unless they are VERY steep, so the middle point is used to land on them. They're also used to eject the character vertically. Flat areas are usually hard unless they lie next to slope tiles (for reasons described further below), so you can have your middle point off them and still not fall.

I have a special case where if a soft tile is DIRECTLY above a hard tile you can't land on it with the left/right points. (But it will still impede left/right progress if you run up against it or jump to the left or right of it) This special case is for when a when a slope ends over a pit.

In my diagrams, purple is a hard tile, yellow is a soft tile.

Here is the above special case. You can't land on that hard tile, but it would still eject you horizontally if you were jumping next to it, or falling through it.

Right now my game ejects the character from the wall in the above case if they have no velocity, or velocity that would put them further in the wall. This is so they don't fall halfway through the wall. If they have velocity away from the wall, well... no ejection occurs since they're moving out of it anyway.

That ejection looks kinda silly, but you have to really be trying to trigger it. The plan that I have, though it's not programmed yet, is to just add velocity in that case, so it's like the slope pushes the character out of the wall with the X velocity it gives the player. Actually landing on a slope would give you some horizontal velocity, so it would be like you landed on it for a frame and got its velocity, then started falling.

And it checks the pixel above the tile. So this doesn't trigger that special case. The character would just be ejected horizontally here:

That's the basics of hard and soft tiles. But a tile can be both soft and hard. For instace. What do we do in a case like this?

The character's right point is in a hard tile so by game rules he should be ejected to the left. But... that wouldn't make any sense to the player who thinks he should be able to continue up the slope.

If those tiles were made soft, the player could fall through on the other side with half his body inside.

So the tile is made soft for the right point and hard for the left point. Problem solved.

Even this breaks in this case Tokumaru posted.

But I've yet to come up with anything else this doesn't handle.

by tokumaru on 2010-04-25 (#60385)

They didn't fix it in Sonic 2:

->

I couldn't find places like this in Sonic 3 (& Knuckles), but I didn't look much.

I guess that the only way to fix this is to check all the column heights below the object in case the primary point isn't making contact, as opposed to checking just the secondary points. Not the fastest solution, but it will allow for the sides of slopes to be used as walls.

by Dwedit on 2010-04-25 (#60386)

Mr. Gimmick appears to just let you fall off a slope as your midpoint leaves the slope.

Then wall ejection kicks you out of inside the wall.

by tokumaru on 2010-04-25 (#60388)

Yeah, I mentioned some games do that. Kasumi seems to handle it like this as well. I don't like it, I think it's a very sudden movement that looks weird.

by Disch on 2010-04-25 (#60389)

Let's look at this from a different angle.

We know what the problems are, but what would be the desired behavior? Part of the reason why I'm having a hard time visualizing a solution is because I don't know what I'm aiming for.

I think the "top of the slope" desired behavior is pretty straightforward. Once the object gets to the top, he should move horizontally until his hitbox completely clears the topmost point, at which point he falls.

But what about the bottom of the slope behavior? Is it the same? Once you go past the bottom of the slope, we want to move horizontally until the hitbox clears, right?

With that in mind, here's my new idea:

1) Use the center point first and foremost. If the center point is grounded, the object is grounded. If the center point is on a slope, the object is on a slope.

2) If the center point gives the impression that you're going to fall, you instead check the entire lower surface of the rect.

3) If no point on the lower surface finds any floor, you fall

4) Otherwise, you remain grounded as if you were on a flat surface (no slope).

It'd work like this:

The problem is this only works if you're grounded. If you're falling, this poses a problem:

The same problem persists if you walk from a flat surface to a downward slope (or from a downward slope to a steeper slope):

So what's the solution here?

My first incling is to check a few pixels beneath the center point. If the center point is "almost" grounded:

- "snap" to the floor if you're already grounded
- or resume falling and ignore the floor overlap if you're airborne

This logic seems to cover every angle I can think of. What do you guys think?

by tokumaru on 2010-04-25 (#60390)

Disch wrote:
1) Use the center point first and foremost. If the center point is grounded, the object is grounded. If the center point is on a slope, the object is on a slope.

Yeah, that's how the idea I presented in the first post works.

Quote:
2) If the center point gives the impression that you're going to fall, you instead check the entire lower surface of the rect.

Yup, instead of using a secondary collision point you have to check the whole width of the object.

Quote:
This logic seems to cover every angle I can think of. What do you guys think?

What about ejection from the side of a slope?

Do you think it can work the same way it does with regular walls?

by Disch on 2010-04-25 (#60391)

Quote:
What about ejection from the side of a slope?

Well I'm doing X and Y movement seperately, so that's not really a problem for me.

For example, Y movement is done first, and since the rect was originally outside the wall, it would fall as normal.

Then when you try to move left, the side of the slope would appear as a solid wall.

by Kasumi on 2010-04-26 (#60398)

tokumaru wrote:
Yeah, I mentioned some games do that. Kasumi seems to handle it like this as well. I don't like it, I think it's a very sudden movement that looks weird.

The insta ejection is only how my game works for now. The plan should be easy to implement, I just can't say I have it working right this second. I've got something bigger to solve that factors into this.

In Sonic, jump over a sort of steep slope, then try to 0 out your horizontal velocity before landing. (How about trying on the first slope going down to the right |\ in angel island act 1?) Upon landing, some of Sonic's vertical momentum becomes momentum to the right. My game will do that sort of thing in that case. Character has "landed" his left point in a slope pit. Character should fall because his middle point is not in a wall, and his left point is in a hard wall, but there is a soft wall above it.

But... because it's a hard wall with a soft wall above it... character gains some momentum to the right, so he's moving outside the wall, that would match the momentum he'd gain from landing on the slope with his middle point. No insta ejection occurs. It's like he landed on the slope for a frame, but was unable to jump on this frame. I might prohibit increasing movement to the left until he's safely out of the wall, but I don't think it will look too strange. Maybe on really shallow slopes, but I think I can compensate that somehow. Or... just design my maps around that. I'll need to get it working before I know how bad they'll look. If 30 degree slopes and below look strange, I'd take care not to put those next to pits. If I only have to avoid that and the rising slope ending in pit case, I'm not too worried.

Disch wrote:
2) If the center point gives the impression that you're going to fall, you instead check the entire lower surface of the rect.

You check 15 points for collision if your character is 16 pixels wide? (You already checked one, of course) If that's what you're describing, I definitely can't check that many points quickly enough to not lose frames, considering I also multidirectional scroll and such. My game does not store an array of bytes for each slope, so it's not a simple lda slopetilenumber,x compare for me.

Disch wrote:
4) Otherwise, you remain grounded as if you were on a flat surface (no slope).

This would then allow you to stand like this?

I don't like that. My game uses slopes to add momentum, so being able to land on a slope with a left/right point with no effect to your horizontal velocity is strange behavior compared to landing on one with your middle point and having it add some.

Disch wrote:

My first incling is to check a few pixels beneath the center point. If the center point is "almost" grounded:

- "snap" to the floor if you're already grounded
- or resume falling and ignore the floor overlap if you're airborne

This logic seems to cover every angle I can think of. What do you guys think?

Here's a problem my own game has. How many pixels is a few? I think it runs into a "what's the difference" sort of thing. Green is where the sprite was horizontally last frame. Blue is where it is now.

Can the program tell the difference between the left and right case? How? Granted that's an extreme case, but if your character can move fast enough that his center point might move far enough along for a steep slope below him to be confused for a vertical drop, it can be a problem.

Of course... something moving that fast would probably fall instead of going down the slope anyway. But this sort of thing is another problem for people dealing with slopes to solve. Any input on this one? Right now I've got my max speed capped a tad lower than I want it to be because the character can "unstick" from a slope if he's going fast enough.

My first idea is to just adjust the characters height based on how steep the slope is, rather than "move X pixels", "adjust y position to top of slope at X location". If there was some vertical pixel movement in between those two steps it would keep the character close enough to the slope for this case to be a non issue even at the highest speeds. It may work, but I've yet to really stress test the idea. Any input on this one?

And one more case while I'm at it. How about floating slopes?

The issue is, gravity has pulled your character through a slope, and neither of the y positions register a "hit" on the left/right points so the player keeps falling.

Disch's method would handle the exact case above well, but checking all the bottom points is too CPU intensive for me. I already find how far a floor is beneath a point by checking two tiles, but I haven't tested quite how that works with this case. I need to update my map editor a bit before I do.

Feel free to discuss that or not. I may already have it solved. I like this topic

by 3gengames on 2010-04-26 (#60399)

I'm just going to throw my 2 cents into here, it probably won't matter but here it goes....

It's apparent that other games ran into the same problem and solved it different ways, I'm sure they did their homework, too. Since they all used a semi different way to "fix" (or avoid) it, it's clear that we'll just have to pick one of these methods and run with it.....

by tepples on 2010-04-26 (#60405)

65024U wrote:
Since they all used a semi different way to "fix" (or avoid) it, it's clear that we'll just have to pick one of these methods and run with it

Or do what we're doing in this topic: synthesize them all.

Frankly, I think Gimmick has the right idea. If the center of mass is past the slope, this means the actor's going to fall off.

by Banshaku on 2010-04-26 (#60408)

More or less on topic file searching for a software in my temp folder, I ended up on an a copy of Neotoxin, written 2004-02-15. I don't remember why I(?) wrote the date on it.

The demo allowed you to beat some kind of boss. When you go later in the demo, there is some slope. In general the top of the slope contain a flat surface. The slope were handled very well in this demo. When jumping on a slope the character was fine too.

by Disch on 2010-04-26 (#60413)

Kasumi wrote:
You check 15 points for collision if your character is 16 pixels wide? (You already checked one, of course)

Well you wouldn't check all 15 points individually. Instead you'd just take the "highest" point that has an X position that puts it underneath the character.

This is easier with linear slopes. If you have tokumaru's slope system where each column can have its own height, then yeah it's not very practical.

by UncleSporky on 2010-04-26 (#60420)

I've been thinking about what the ideal method for this would be, if collision wasn't so resource intensive. A lot of what you're talking about is with regards to how natural it looks, whether we're intersecting the ground, and not how the physics are behaving.

I think in the most extreme situations, where the midpoint is off the slope but the character shouldn't fall yet, it would be ideal if we could detect this state and modify the sprite so it looks like we're still on the slope. It shouldn't be too hard to detect since the back corner is still intersecting the slope tile.

As a case study, I don't remember any parts of Kirby that have a slope that isn't connected to a normal block, but it's interesting to see how they did it. They actually have different standing frames for two different "steepnesses" of slopes, a climbing animation for the steeper one, and it doesn't look too bad at transitions...

by tokumaru on 2010-04-26 (#60429)

Kasumi wrote:
Upon landing, some of Sonic's vertical momentum becomes momentum to the right.

Yeah, when landing on a slope, the speed is distributed differently depending on the angle. The opposite also happens when jumping from a slope, you will not always go straight up. It's a nice feature.

Quote:
Disch wrote:
2) If the center point gives the impression that you're going to fall, you instead check the entire lower surface of the rect.

You check 15 points for collision if your character is 16 pixels wide? (You already checked one, of course) If that's what you're describing, I definitely can't check that many points quickly enough to not lose frames, considering I also multidirectional scroll and such.

Yeah, I was worried about this as well, it might be too CPU intensive for the NES. I thought of a variation that might work though. The middle point is always used first when looking for the floor:

Once this point is off the ground, we look for ground using the other 2 points (much better than 15). If there is no floor, the object falls. If there is, instead of using the height of the column exactly below the point, like Sonic does, we use the height of the rightmost column:

The same thing happens when walking down a slope:

Once the first attempt to find the floor fails, we try the other two points. The point at the right detects floor, so we use the height of the leftmost column of the slope tile:

Quote:
This would then allow you to stand like this?

I don't like that.

It's not ideal, but I like that much more than instant wall ejection. If the slope is too steep, you could just detect that and make the object slide down, preventing it from standing there.

IMO, there is no perfect solution that can be used on slow 8-bit (and even 16-bit) CPUs. Every game I studied has its limitations and rules, none of them use completely arbitrary floors. As players we most likely never noticed those limitations, because they were well hidden.

It would be foolish to think there is a perfect method that can be used on the NES. We should all be worrying about picking the method whose limitations don't interfere with our game mechanics and hide them as best as we can.

by Kasumi on 2010-04-26 (#60431)

tokumaru wrote:
The opposite also happens when jumping from a slope, you will not always go straight up. It's a nice feature.

Indeed, my game will do that as well.

I also have an alternate sprite for steeper slopes like Kirby. I'm not sure how it looks in game. I've been so busy getting the best collision rules I can think of I haven't done much graphically.

65024U wrote:
I'm just going to throw my 2 cents into here, it probably won't matter but here it goes....

It's apparent that other games ran into the same problem and solved it different ways, I'm sure they did their homework, too. Since they all used a semi different way to "fix" (or avoid) it, it's clear that we'll just have to pick one of these methods and run with it.....

Indeed, tokumaru and I already have one point we'll go seperate ways on, but it's still nice to discuss various ways of solving the same problem. And seeing this topic with so many ways to make this work as a new person wanting to make a NES game with slopes might help them make decisions and solve these problems for their own game.

by BMF54123 on 2010-04-26 (#60466)

This reminded me of an interesting article by Gregg Tavares, one of the programmers of MC Kids, part of which explains how they dealt with slopes in the game.

I found it interesting how Super Mario Bros. 3 actually changes the collision rules based on whether a level contains slopes or not. That seems pretty sloppy to me.

by tokumaru on 2010-04-27 (#60473)

BMF54123 wrote:
This reminded me of an interesting article by Gregg Tavares, one of the programmers of MC Kids, part of which explains how they dealt with slopes in the game.

Very badly, I must say. IMO, the ideas presented in this thread are much more interesting.

by Drag on 2010-04-28 (#60528)

In actuality, if anything less than a whole foot is on a ledge, you're going to topple off, whether the ground is sloped or not.

Anyway, here's my proposal:

Project the slope.

Edit: Yeah, that doesn't have the best results 100% of the time, so here's an addendum:

For the upper edge of the slope, you can just project the height of the edge, since theoretically, when your corner point enters the tile to detect the collision in the first place, you will already be sunken past the projected slope's surface, and popping up a few pixels when you land probably isn't going to look incredibly pretty.

On the lower edge, you can just simply project the slope, because when your corner intersects the tile, the actual physical surface of the tile is much lower than the top edge of the tile's square boundaries, so you can tell exactly where you'll hit the slope's surface.

In essence, when you walk off the top of the slope, when your middle point crosses out of the tile, it'll "pretend" that you're walking onto a flat tile until your corner point crosses out of the sloped tile.

When you walk off the bottom of the slope, you'll just keep walking lower and lower as though that slope is continuing, until your corner point crosses out of the tile.

Of course, if your middle point crosses out of the sloped tile and onto another tile that's actually solid, you'll just check against the new tile's surface, unless it's lower than the corner point still in the old tile.

Edit:

This is how the midpoint would react, if the bottom edge of the object were 32 pixels long. The vertical red lines represent areas where the midpoint can't cross (since the collision detection would prevent the object from walking into the walls)

The highlighted lines are where the midpoint would be when you collide with the ground and stop falling.

The dark green is the actual physical landscape, everything else is just open air.

by tokumaru on 2010-04-28 (#60543)

The problem is how much you're supposed to project the slopes. It has to be half the width of the object colliding with it.

If that projection is hardcoded in the collision data, this idea will not work very well because it will be done according to a single width of your choice, and it will not work the same for objects of different widths.

On the other hand, calculating those projections dynamically could be tough. Specially when going down a slope, since the projection must have the same angle as the slope. What if the slope is more complex than a simple ramp? There is no way to guess the shape of the extended surface.

Re: Collisions against sloped surfaces
by thefox on 2014-07-17 (#131241)

It's unfortunate that so many images in this thread have disappeared. Is there any way to restore them?

Re: Collisions against sloped surfaces
by Kasumi on 2014-07-17 (#131245)

Blast from the past. It's actually quite amazing how many of the problems I mentioned in my post I've since solved. I probably don't even still have those images locally, though.

edit:

Quote:
Mr. Gimmick appears to just let you fall off a slope as your midpoint leaves the slope.

So I still have it so you still fall off slopes from your mid point. But the airborne wall ejection will only be run if traveling at speed 0 or toward the wall. Since running off a slope would typically mean your speed is away from the wall, this ejection rarely occurs. Even trying to force it to happen is tough, because jumping on a slope changes your X speed, and then you have to try to get it to slightly above zero just to see the odd effect.

My game currently has a glitch where if you manage to land (on flat ground even) while still inside the wall (and again, you have to manage your speed VERY carefully for this to happen) the thing that detects slope angle will think you're on a very high slope (because the left/right points get an offset, and one is inside the wall) which can cruise you out of the wall as if you were on a slope which is weird. My game has "pixel perfect" slope detection, so it can detect 49 levels of slope rather than just 4 or whatever.

To fix this problem in Sonic that Tokumaru mentioned:

In addition to my pixel perfect slope detection, each slope has a "height" from 0 to 3. 0 is flat, 1 is shallow, 2 is 45, 3 is steep. Then I have a set of offsets. The character is already raised or not depending on how high the slope is.

When his left or right point is above air, it's tough to tell what situation he's in. So at the point, it reads the hard coded slope height (as opposed to the pixel perfect one) from the slope the midpoint is on, and uses that for offsets. (PS, this hard coded slope height is what enemies use, since doing the pixel perfect check for everything would be pretty CPU intensive.)

And to access that table is exceptionally simple. Just and the low byte of his position with 8, and use that number as an index in the table. (There are separate tables for left and right.) I also have indexes for walking off flat ground since the character is somewhat egg shapes, and walking off flat ground would mean left parts of him would float above flat ground without them.

Anyway, there's really nothing left except that one land in wall glitch that I'm unhappy with. I even have ideas to fix it, it's just whether or not it will be too CPU intensive. Running the main character is already quite CPU intensive, and my game support co-op.

Re: Collisions against sloped surfaces
by tokumaru on 2014-07-17 (#131246)

I probably don't have my images either, since I replaced my laptop around 2012 and I'm not very good at backing up small files like these.

Re: Collisions against sloped surfaces
by psycopathicteen on 2014-08-06 (#132160)

Is it easier to do slope collision with LUTs, or should I use arithmetic? I'm trying to figure out a nice looking algorithm that most people would be able to read.

Re: Collisions against sloped surfaces
by rainwarrior on 2014-08-06 (#132163)

psycopathicteen wrote:
Is it easier to do slope collision with LUTs, or should I use arithmetic? I'm trying to figure out a nice looking algorithm that most people would be able to read.

Aren't they both equally easy? The result is the same. The reason to use one or the other is situational. If you don't have a reason right now to use one or the other, just pick one.

Re: Collisions against sloped surfaces
by tokumaru on 2014-08-07 (#132181)

psycopathicteen wrote:
Is it easier to do slope collision with LUTs, or should I use arithmetic? I'm trying to figure out a nice looking algorithm that most people would be able to read.

Will using arithmetic for slopes always result in straight ramps of varying angles? IMO that's a pointless limitation, when you could use LUTs and have curved surfaces and other interesting constructions, as well as everything you could have with the arithmetic approach.