Commander X16

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

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.

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.

mortarm wrote: ↑Wed Jan 24, 2024 5:15 pm After reading all this, I've come to the conclusion that BASIC really needs sprite-handling statements.

DragWx wrote: ↑Wed Jan 24, 2024 6:28 pm 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.

My guess is that from the beginning the intention was that VERA should have real sprite collision interrupts, which meant the IRQ would always handle collisions between two sprites, which is rather straightforward. The resulting info is in this case just the sprites masks AND:ed together. Then this design was abandoned by some reason, and we suddenly had to sort out what happens when more than two sprites collide. To me the short answer seems to be what you (DragWx) say, this limits the usability. Hardware detection with this design works best when you can ensure that no more than two sprites collide in each frame.

DragWx wrote: ↑Wed Jan 24, 2024 6:28 pm 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.

Seems to be a clever solution!

My problem is that I had a solution that I thought worked. The player is killed when he collides with an enemy. Here I just used hardware detection, nothing else. When an enemy is shot I used hardware detection to know it had happened, then I had code to find which enemy it was. But because I cannot ensure that two enemies are colliding now and then, I have to implement software detection both for the player and the shot that runs every frame. Hardware detection has become useless.

Just for fun, here are some designs that could depend entirely on the VERA's collision detection (in 240p mode):

The P1 cursor is %0011 and the P2 cursor is %1100. Target A is %0101 and Target B is %1010.

4 players shooting one target could have each player be %0001, %0010, %0100, and %1000, while the target is %1111.
This could also be used for one player (%1111) shooting four targets (%0001, %0010, %0100, and %1000).

The enemy ship is %0111 and your ship is %1000. You can shoot three bullets (%0001, %0010, and %0100) while your enemy shoots just one (%1000).

This is actually kind of a neat puzzle to figure out, kinda like trying to figure out various strategies for using the MSX2's multicolor sprite mode.

Yes, it is limited but still useful in certain scenarios : ). I really appreciate that you helped me sort this out!