This is a good solution, but a bit wasteful because you ended up checking the solidity of the same block twice. I'd rather calculate the coordinates of the block in the left, then the one in the right, and finally run a "for" loop from one to the other. You could solve this particular case with just 2 checks.Drag wrote:Moving the point by the width of a tile again will exceed the width of the player. So instead, check the bottom right corner of the player, down one extra pixel, and sample the properties of the tile at this point
How do I come about collision detection?
Moderator: Moderators
Re: How do I come about collision detection?
Re: How do I come about collision detection?
The way I explained it, the last sample is the only one that has the possibility of being redundant (because it's not necessarily "tile_size" pixels away from the previous sample), but never the less, it's important. But yes, as Tokumaru demonstrated, there are other ways you can implement this that would avoid redundant checks, but this is the basic idea behind tilemap-based collision detection.
It's also worth noting that you don't need to actually use pixel calculations; if your tilemap is 16x16 (for example), and one byte of ram represents a tile, then moving to the next byte of ram is equivalent to moving 16 (or whatever your tile size is) pixels. I just explained it the way I did because it's the easiest way to visualize it without having to explain bytes and other fun stuff to newbies.
It's also worth noting that you don't need to actually use pixel calculations; if your tilemap is 16x16 (for example), and one byte of ram represents a tile, then moving to the next byte of ram is equivalent to moving 16 (or whatever your tile size is) pixels. I just explained it the way I did because it's the easiest way to visualize it without having to explain bytes and other fun stuff to newbies.