Yes, that looks correct. The effect is that two sprites with the same mask will collide with each other, which I think limits the usability of this kind of collision detection. This is before we touch on the fact that the collision detection is really bad if you're in 480i mode, because it depends on lines physically being rendered, and only half of them are rendered in each frame in that mode.Johan Kårlin wrote: ↑Wed Jan 24, 2024 2:37 pm If I take my example with a shot and two enemies colliding again, is the following right?
1. Shot has mask 0010, pixel mask is 0000, result for IRQ 0000, new pixel mask 0010
2. First enemy has mask 0011, pixel mask is 0010, result for IRQ 0010, new pixel mask 0011
3. Second enemy has mask 0011, pixel mask is 0011, result for IRQ 0011, new pixel mask 0011
When I wrote a collision detection routine in 6502 a while back, I had a similar strategy where actors had two masks, one to specify which groups they belonged to, and one to specify which groups they collided with. That way, an actor could belong to the bullet group and be "interested" in the enemy group (so the bullet can disappear), and an actor could belong to the enemy group and be "interested" in the bullet group (so the enemy can take damage). The goal of this being, if two actors don't care about colliding with each other, the routine completely skips all of the calculations related to it, so things like enemy vs enemy or bullet vs bullet collisions.