nesdev.org

Reading this post from tokumaru: http://nesdev.com/bbs/viewtopic.php?p=4617#4617

I've started to think about my collision system for backgrounds. I'd like to apply the idea of the collision points for every object.
But 1 bit for every tile seems too much, I'm thinking about doing a 16x16 collision map where each bit represents a 2x2 tile zone.
Then translate the object to up to 2 bytes per tile row (no object should be greater than 64pixels wide) and mask BG with the object via AND, if some of the results are not zero, you have collisions. Then drop object velocity (in x if collision was x or in y if collision was in y) and correct its position.

Using this schema, how could I add map zones that can be jumped in from the bottom (more bits)?
How do you do your background collisions?

Wave wrote:Using this schema, how could I add map zones that can be jumped in from the bottom (more bits)?

Well, it's usually possible to jump in from the bottom, because it would be counter-intuitive to have platforms outside of the visible section... If there was something solid, it should be in the visible area. I'd just handle the special case of coordinates outside of the map returning "empty" bits. If you really need the bottom to be solid sometimes, you could program some sort of switch to define the default solidity of areas outside the map.

How do you do your background collisions?

I think that only 2 states (empty vs. solid) is too little, and there's not much you can do in a game with only that. What about water, slippery surfaces, harmful blocks, platforms that can be jumped from below, and so on?

I give each of my metatiles a whole byte to describe their type, and some invoke even more data, such as slopes. When checking for collisions, I use the object's collision points to fetch metatiles from the level map, and then I check their collision info. I don't have a separate collision map.