I am programming a metroid clone in C, and need some help with handling slopes.
A little info:
The player has a top-left origin, and a collision rectangle given as an x, y offset, width, and height. He's about
2 tiles tall and 1 tile wide. The TILE_SIZE is 16 pixels. Only whole pixel movement is possible.
The method I currently have for background collision is taken from what I have read on this forum.
It is the basic step x before y eject if solid algorithm, checking along the edges of the collision rectangle,
though I have included the psuedo-code of the version I use below,
just in case you have ideas for improvements.
BG collision algorithm (pseudo-code)
This algorithm seems to work fine for ordinary solid, rectangular blocks and speeds less than TILE_SIZE.
But whenever I try to introduce 45 deg. slopes I always get buggy / game-breaking results...
Q:
Should I check along x-axis before y-axis if I am adding slopes?
Do I ignore slopes in the horizontal step and snap the y-position if colliding with slope in the vertical step?
What x position should I use as how far up/down the slope you are?
Do I need an entirely new algorithm? (like stepping x and y at the same time with smaller increments?)
Comments:
So far the most stable result I have been able to get is to increment vertical-position during the horizontal step if colliding with a slope,
and skip the vertical step entirely if a slope was encountered in the horizontal step.
However if you stop moving left or right you are just ejected up from the slope this way (floating "in air" over it), and there is
no way to walk down a slope. I have no idea how to do sloped ceilings.
Thank you for your time.
A little info:
The player has a top-left origin, and a collision rectangle given as an x, y offset, width, and height. He's about
2 tiles tall and 1 tile wide. The TILE_SIZE is 16 pixels. Only whole pixel movement is possible.
The method I currently have for background collision is taken from what I have read on this forum.
It is the basic step x before y eject if solid algorithm, checking along the edges of the collision rectangle,
though I have included the psuedo-code of the version I use below,
just in case you have ideas for improvements.
BG collision algorithm (pseudo-code)
Code:
1. Add x velocity to x position.
2. Compute corners of collision rectangle.
3. Define a point p as the top-right (or top-left for neg. velocity) corner.
---4. Is the tile at point p solid? If so, eject the player along x-axis and go to 7.
---5. Otherwise add TILE_SIZE pixels to the y-coordinate of p.
---6. If p is below the collision rectangle snap it to the bottom side then set a flag that this is the last horizontal check. Go to 4.
7. Add y velocity to y position.
8. Re-compute corners of collision rectangle.
9. Define a point p as the bottom-left (or top-left for neg. velocity) corner.
---10. Is the tile at point p solid? If so, eject the player along y-axis and go to 13.
---11. Otherwise add TILE_SIZE pixels to the x-coordinate of p.
---12. If p is to the right of the collision rectangle snap it to the right side then set a flag that this is the last check. Go to 10.
13. Return.
2. Compute corners of collision rectangle.
3. Define a point p as the top-right (or top-left for neg. velocity) corner.
---4. Is the tile at point p solid? If so, eject the player along x-axis and go to 7.
---5. Otherwise add TILE_SIZE pixels to the y-coordinate of p.
---6. If p is below the collision rectangle snap it to the bottom side then set a flag that this is the last horizontal check. Go to 4.
7. Add y velocity to y position.
8. Re-compute corners of collision rectangle.
9. Define a point p as the bottom-left (or top-left for neg. velocity) corner.
---10. Is the tile at point p solid? If so, eject the player along y-axis and go to 13.
---11. Otherwise add TILE_SIZE pixels to the x-coordinate of p.
---12. If p is to the right of the collision rectangle snap it to the right side then set a flag that this is the last check. Go to 10.
13. Return.
This algorithm seems to work fine for ordinary solid, rectangular blocks and speeds less than TILE_SIZE.
But whenever I try to introduce 45 deg. slopes I always get buggy / game-breaking results...
Q:
Should I check along x-axis before y-axis if I am adding slopes?
Do I ignore slopes in the horizontal step and snap the y-position if colliding with slope in the vertical step?
What x position should I use as how far up/down the slope you are?
Do I need an entirely new algorithm? (like stepping x and y at the same time with smaller increments?)
Comments:
So far the most stable result I have been able to get is to increment vertical-position during the horizontal step if colliding with a slope,
and skip the vertical step entirely if a slope was encountered in the horizontal step.
However if you stop moving left or right you are just ejected up from the slope this way (floating "in air" over it), and there is
no way to walk down a slope. I have no idea how to do sloped ceilings.
Thank you for your time.