Sprite collision detection

The Commodore 128 has built in sprite collision detection, but since Commodore Basic 7.0 is so slow, it must be used with some care. To demonstrate this, I have used SPRDEF to create two masterpieces. This is sprite 1:

s1

And this is sprite 2, this is excellent:

s2

I want to demonstrate the level of detail of the collision detection by turning both sprites on at an overlapping position, but not and colliding position, and then read out the collision flags. If you are doing this on your own Commodore 128, you might want to adjust the positions if your sprites are not identical to mine.

s3

The image shows that the sprites share an overlapping position, but they do not collide. There are no overlapping pixels. Yet, the BUMP(1) function will return 3 in this situation. The value 3 means that flag 1 and 2 are turned on, indicating that sprite 1 and  2 are colliding, even though they just share position. However, the size of the sprite is determined by the smallest rectangle that include all pixels of the sprite, which is second best after pixel perfect collision detection.

Game programming in Commodore Basic 7 is futile. Despite this cheating, the sprites moves faster than the Basic interpreter can handle. To see this, you can make the sprites move towards each other, and their positions if they collide. You should see that not all collisions are acted upon.

s4

Bjud mig på en kopp kaffe (20:-) som tack för bra innehåll:

Bjud mig på en kopp kaffe (20:-) som tack för bra innehåll!

Comments

Important information: If you have not commented before, your comment will be reviewed before it is published. This means that you will not see it immediately, but I have received it. This is not because I want to filter comments, but because I want to prevent spam and advertising.

Leave a Reply

Your email address will not be published. Required fields are marked *