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.
Sprite collision test
Re: Sprite collision test
I might not be the only one, but I've not tried anything as I don't really understand the question.
Sorry!
Sorry!
-
- Posts: 108
- Joined: 08 Jan 2014 20:50
Re: Sprite collision test
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
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.
The 5th sprite seemed to be permanently set to 2, possibly from how Basic sets up the innactive sprites ?
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.
The 5th sprite seemed to be permanently set to 2, possibly from how Basic sets up the innactive sprites ?
-
- Posts: 108
- Joined: 08 Jan 2014 20:50
Re: Sprite collision test
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.
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.