sprite collisions?

All aspects of programming on the Commander X16.
Post Reply
jimbo
Posts: 12
Joined: Mon Oct 09, 2023 11:23 am

sprite collisions?

Post by jimbo »

I've read the documentation and various tutorials on sprites and sprite collisions plus played with all types of code .. but can't seem to figure out a simple way of doing what I want. Any help or pointers in the right direction would be much appreciated:

A simplified scenario of what I am doing is that I have some alien sprites (eg say 10 active at once) and a bullet sprite (ie 1 active). Sprite collisions is activated, mask for alien sprites is 0011xxxx and mask for bullet sprite is 0001xxxx.

Am I right that a sprite collision interrupt is triggered:
(i) when any of the aliens collide (Collisions in ISR will be 0011)?
(ii) when a bullet collides with alien (Collisions in ISR will be 0001)?
(iii) when both of the above happen at the same time (Collisions in ISR as 0011)? [Edit: Actually is 0001 per note below]

My question is - is there a way to distinguish between scenario (i) and scenario (iii) without doing a full "row/column overlap" search between the bullet and all aliens? I simply want to ignore scenario (i) (ie it's ok if the aliens "overlap") but of course for them to be "hit" when a bullet hits them.
Last edited by jimbo on Wed Jan 03, 2024 3:36 pm, edited 1 time in total.
Johan Kårlin
Posts: 292
Joined: Wed Jun 03, 2020 11:33 am
Location: Kalmar, Sweden

Re: sprite collisions?

Post by Johan Kårlin »

I have also had reasons to test and implement this. This is what I have learned:

The two first assumptions are right, not the the third I think because colliding sprite masks are AND:ed together which will result in 0001.

Unfortunately, there are no other way than iterating over all aliens to decide which one(s) is/are hit by the bullet.

Worth noticing is that there are no separately triggered sprite interrupts, the Collisions in ISR is updated at the start of the vertical blank. This no disasvantage though, it just makes it simpler, you don’t have to check each time in your ISR if it is a sprite or a vblank interrupt.
Last edited by Johan Kårlin on Wed Jan 03, 2024 4:48 pm, edited 1 time in total.
jimbo
Posts: 12
Joined: Mon Oct 09, 2023 11:23 am

Re: sprite collisions?

Post by jimbo »

Thank you Johan. Yes confirmed re my error above on scenario (iii), and noted re the interrupt triggering (there is one tutorial online that suggests the sprite collision interrupt occurs independent of the vertical blank interrupt which was something else I couldn't seem to replicate).
mgkaiser
Posts: 54
Joined: Sat Dec 02, 2023 6:49 pm

Re: sprite collisions?

Post by mgkaiser »

You still need to implement specific logic to see what is hitting what. The interrupt just lets you only run that logic when you know for sure that something has hit something.
Johan Kårlin
Posts: 292
Joined: Wed Jun 03, 2020 11:33 am
Location: Kalmar, Sweden

Re: sprite collisions?

Post by Johan Kårlin »

jimbo wrote: Wed Jan 03, 2024 2:10 pm A simplified scenario of what I am doing is that I have some alien sprites (eg say 10 active at once) and a bullet sprite (ie 1 active). Sprite collisions is activated, mask for alien sprites is 0011xxxx and mask for bullet sprite is 0001xxxx.

Am I right that a sprite collision interrupt is triggered:
(i) when any of the aliens collide (Collisions in ISR will be 0011)?
(ii) when a bullet collides with alien (Collisions in ISR will be 0001)?
(iii) when both of the above happen at the same time (Collisions in ISR as 0011)? [Edit: Actually is 0001 per note below]

My question is - is there a way to distinguish between scenario (i) and scenario (iii) without doing a full "row/column overlap" search between the bullet and all aliens? I simply want to ignore scenario (i) (ie it's ok if the aliens "overlap") but of course for them to be "hit" when a bullet hits them.
I am very sorry, it turns out I was wrong. I am right now dealing with the exact same scenarios as you are. You’re assumptions were right from the beginning. You can say masks are simply AND:ed together when two sprites are colliding, but when there are more than two it is not that simple. See this thread: https://www.commanderx16.com/forum/view ... 232#p31232

I also wish to ignore the first scenario, but I cannot se that there is a way to discern the first from the third using only hardware detection.
Post Reply