Sprite collision test

Everything about programming, including VDP and Sound programming.
Post Reply
Tony Brewer
Posts: 67
Joined: 08 Jan 2014 20:50

Sprite collision test

Post by Tony Brewer »

I'd like to confirm the range of x coordinates for which the VDP does sprite collision detection. I cannot test this myself in real hardware as my MTX is in the attic. I think the following two extremes will set the sprite collision bit:

1. Use two 8x8 (or 16x16) sprites with same patterns. Pattern byte 0 = 80H, y = -1, x = 0, EC/colour = 80H.

2. Use two 16x16 sprites with same patterns. Pattern byte 0 = 0, pattern byte 16 = 1, y = -1, x = 255, EC/colour = 0. Sprite magnification bit = 0 or 1.

Other pattern bytes not mentioned are not important and could be zero. I'd be grateful if someone could try this.
Martin A
Posts: 529
Joined: 09 Nov 2013 21:03

Re: Sprite collision test

Post by Martin A »

I might not be the only one, but I've not tried anything as I don't really understand the question.

Sorry!
Tony Brewer
Posts: 67
Joined: 08 Jan 2014 20:50

Re: Sprite collision test

Post by Tony Brewer »

Martin A wrote: 02 May 2021 11:42 I might not be the only one, but I've not tried anything as I don't really understand the question.

Sorry!
The aim is to test limits of collision using two sprites with same pattern at same x,y coordinate. Test 1 is extreme left test with one set bit at x = 0-32. Test 2 is extreme right test with one set bit at x = 255+15 (unmagnified) or two set bits at x = 255+30 and 255+31 (magnified).
Martin A
Posts: 529
Joined: 09 Nov 2013 21:03

Re: Sprite collision test

Post by Martin A »

OK, MTX Basic is pretty horrible for this, but...

It appears the coincidence bit is only being set on the active part of the display.

I tested 8x8 unmagnified sprites scrolling up from the bottom of the screen. The results with a pattern of 128,0,0,0,0,0,0,0 and 0,0,0,0,0,0,0,1 were the same. The C bit didn't get set unil the active pizel was visible.

Using 16x16 magnified sprites the something had to be visible to get C to set, I tested both top and bottom of the screen for those. 1/2 a dot was enough to get a coincidence.

I don't think using Basic is influencing the results, it may be clever enough to know the whole sptite is off screen and not position it. It's not smart enough to know there's only transparent pixels on screen and not position it.
One of the 8 by 8 test versions
One of the 8 by 8 test versions
code sample.jpg (64.14 KiB) Viewed 32 times
8 by 8 sprite scrolling in from the bottom
8 by 8 sprite scrolling in from the bottom
on 8x8.jpg (29.63 KiB) Viewed 32 times
8 by 8 sprite the active dot is 1 pixel off the screen
8 by 8 sprite the active dot is 1 pixel off the screen
off 8x8.jpg (30.57 KiB) Viewed 32 times
16 by 16 magnified 1/2 dot visible in the reflections!
16 by 16 magnified 1/2 dot visible in the reflections!
half top.jpg (37.98 KiB) Viewed 32 times
16 by 16 magnified 1/2 dot visible
16 by 16 magnified 1/2 dot visible
half bottom.jpg (32.4 KiB) Viewed 32 times
The 5th sprite seemed to be permanently set to 2, possibly from how Basic sets up the innactive sprites ?
Tony Brewer
Posts: 67
Joined: 08 Jan 2014 20:50

Re: Sprite collision test

Post by Tony Brewer »

Martin, many thanks for your tests. MTX BASIC might be affecting the results. I ought to write a short assembler program for you to try, however there is no urgent need for this info.

My expectation is that parts of sprites on active lines but completely off the display to the left or right will set the coincidence bit in the status register if any set bits coincide. If four or fewer sprites per line then 5th sprite number might be last sprite processed.
Post Reply