Page 1 of 1
Sprite collision test
Posted: 17 Apr 2021 12:34
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.
Re: Sprite collision test
Posted: 02 May 2021 11:42
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!
Re: Sprite collision test
Posted: 04 May 2021 22:01
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).
Re: Sprite collision test
Posted: 07 May 2021 06:31
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
- code sample.jpg (64.14 KiB) Viewed 4479 times
- 8 by 8 sprite scrolling in from the bottom
- on 8x8.jpg (29.63 KiB) Viewed 4479 times
- 8 by 8 sprite the active dot is 1 pixel off the screen
- off 8x8.jpg (30.57 KiB) Viewed 4479 times
- 16 by 16 magnified 1/2 dot visible in the reflections!
- half top.jpg (37.98 KiB) Viewed 4479 times
- 16 by 16 magnified 1/2 dot visible
- half bottom.jpg (32.4 KiB) Viewed 4479 times
The 5th sprite seemed to be permanently set to 2, possibly from how Basic sets up the innactive sprites ?
Re: Sprite collision test
Posted: 09 May 2021 17:27
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.