isSprTile()

Hi!

Is there a way to retrieve the position (x, y), or any other information that would help locate the tile that caused the collision with the specified sprite?

Thanks!

It is very dependent on what information you want to collect and from where. But generally you can convert the sprite position into tile position and lookup the tile from there (either from the tile buffer or from your map, depending on what is your layout).

You divide the sprite position by 32 to get the tile position in screen space. Then add whatever tile position your buffer is currently within your map (if any).

Two things to consider though:

• sprite anchor is on the top-left, not in the middle
• scrolling offsets values

These have to be factored-in when doing the computations.

If you want to index the memory to retreive the tile reference you then convert the 2d position to address: posY * bufferWidth + posX

Note that the tile buffer width is 32 and not 25 if that's where you want to retreive from. If it's from a map, it depends on the map width.

Hope that helps.

Thanks for your reply.

I was indeed planning to calculate the position myself.

That said, it’s not quite as straightforward as it might seem. As you mentioned, you have to take into account any offsets applied to the tiles, but also the position of the sprite’s collision box.

The sprite as a whole (24×21 pixels) might overlap several tiles, while its collision box may actually overlap only one of them.

Anyway, I was wondering if there might be some information buried deep in Micro-8’s internals that could tell me which specific tile triggered the collision detected by the isSprTile function...

Perhaps this could be a useful feature to consider for a future version, if it’s feasible, to make this information available.

Yes looking at the code the address of the first touched tile in the tilemap (a collision can overlap up to 9 tiles) is available. I will have to find a way to return it back to the user in an efficient maneer. At least all the offsets and sprite AABB computations would be out of the Lofi loop.