3
\$\begingroup\$

I've been looking into adding 'sloping' tiles into my platform game and my first attempt at collision detection with these tiles has produced some promising results (considering it's a first attempt), however, there is something that I just can't work out.

First, some background.

My tiles (on my dev device which is a Google Nexus 10 tablet) are 102 pixels wide by 100 pixels tall (this was done on purpose so they fit better to the screen).

So, my 'slope tile' looks something like this:

enter image description here

Not being a perfect square, the slope isn't quite 45 degrees but that shouldn't really matter I don't think.

Now, in order to find out the vertical 'centre' for collision purposes, I'm doing the following:

  • Find out where the sprite is in relation to the X Coordinate of the tile. (So, if the tile is at 100 and the sprite is at 110, then I am 10 in from the X of the tile.

  • I then multiply that by my slope (slope being height/width or 100/102 in my case)

  • I then divide by 2 to get the centre

  • Finally, I subtract that result from the height of the tile (to invert it)

This gives me the vertical center which I can compare with the centre of my sprite to check for collision.

So, my code looks like this:

VertTileCentre=Math.round(tileYCoord]+tile.quadHeight-((slope*(spriteX-tileX))/2));

Results

When I run this, although my sprite can slide up and down the slope it doesn't follow the (visible) path of my tile so I get something like this:

enter image description here

So when moving down the slope it moves in a jagged line and when trying to move up, it moves up the slope until it hits the next tile along, then gets stuck

Would appreciate if someone could point out why my sprite path is not following the slope correctly or anything else I may be doing incorrectly.

Edit 1 - results from further experimenting

I've noticed that the sprite when at the top-left of a slope tile sinks into the tile slightly, this is why the sprite was 'getting stuck' when moving up - because it was hitting solid blocks behind (which have their own collision detection)

Strangely, I've also noticed that if I remove the 'divide by 2' from my above calculations the path of the sprite is pretty much OK although the sprite itself still sinks into the tile slightly (But now throughout the whole slope) - therefore if I remove the solid blocks, it works OK.

So I have no idea why not dividing by 2 makes sense and also why my sprite is not correctly sitting on the slope!!

\$\endgroup\$
5
  • 3
    \$\begingroup\$ Very well written question, of the few actually worthy for this site. \$\endgroup\$
    – Shotgun Ninja
    Commented Dec 31, 2013 at 15:40
  • 3
    \$\begingroup\$ Your equation appears to be correct, it's more likely the sprite is falling in between the tiles or something similar. How are you detecting the tile that's under your sprite? Maybe some visual debugging of highlighting the tile you're colliding with (and even keeping data points to you can actually draw the line of the sprite) would be helpful. \$\endgroup\$
    – House
    Commented Dec 31, 2013 at 15:57
  • \$\begingroup\$ Related: gamedev.stackexchange.com/questions/64069/… gamedev.stackexchange.com/questions/23312/… \$\endgroup\$
    – House
    Commented Dec 31, 2013 at 16:03
  • \$\begingroup\$ Thanks @Byte56 I did have a read of those questions (plus other on other forums) I've updated my question. I was colliding with solid tiles under my sloped ones. I've removed them but oddly, it still follows this strange path. Even more odd (as in my edit above) if I don't divide by 2, then the path looks consistent (even though my sprite falls slightly into the tile) \$\endgroup\$
    – BungleBonce
    Commented Dec 31, 2013 at 16:11
  • 1
    \$\begingroup\$ I've had a similar issue in my platformer, ended up being a "one off" error. Actually it was an unnecessary one off somewhere else that I accounted for everywhere else but reared its ugly head when it came to slope collision resolve. \$\endgroup\$
    – CodeSmile
    Commented Dec 31, 2013 at 18:05

1 Answer 1

Reset to default
2
\$\begingroup\$

I found the answer and it actually lay in my collision routine. During normal collision detection (between 2 rectangles) I take half the width/height of both objects and compare their sum to the distance between the 2 object's centres at any given time.

Up until now, my objects (for collision purposes) have always been a constant 102 x 100 so the sum of 2 object's half-size has always been the same (100 for height and 102 for width) - however, I failed to take into account the vertical size of the slope is effectively changing every time my character moves so I need to dynamically update it based on the characters position.

I've done that and now it seems to be working - there are some other issues I have for which I will post another question if required. :-)

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .