f precise collision is enabled on the calling instance, won't it produce the wrong results using the sprite instead of the bounding box?
The bounding box is basically
exactly the collision mask of a sprite, but
always rectangular. (You can check rectangle collisions with just 4 less than / greater than maths checks, so it's a lot faster than checking every pixel in a precise mask for overlaps). So the difference is that the bounding box covers the same area as the sprite's collision mask, but
it's less precise. Having precise collision checking turned on will never make your collisions less accurate, only less efficient CPU-wise.
Also, feedback on the blog itself:
You will need to repeat this process every time you add or remove tiles from your tileset! Though if youāve used tiles before, you know that altering your tileset is going to do a lot more damage than make you do this againā¦ especially if youāve already designed multiple rooms with said tileset.
Changing the
height of a tileset won't scramble the tiles (they're numbered from left to right, up to down, and all pre-existing tiles maintain their index after changes to a tileset).
In my approaches to tile collisions so far, I've combined these two things into one: tile collisions are based on the
left and
top coordinates of the tile, so e.g. tiles whose left coordinate is 64 always are slopes and upwards/downwards slopes are in pairs on alternating rows. This approach also makes it possible to reuse tile data with a different tileset easily (since you're forced to make the tiles line up for every tileset) and can speed up your workflow since you always know where each type of tile is located in the tileset, but the main benefit is having less cases to handle in the code.