How does the TIA actually do the collision check?

[marienbad]

So when player 0 collides with the playfield the collision register is set such that it can be read and branched on like this (code from Spiceware):

 

bit CXP0FB      		; N = player0/playfield, V=player0/ball
bpl OSwait		     	; if N is off, then player0 did not collide with playfield
		

So the TIA knows the Horizontal location of the player because it has the RESP0 and HMP0 registers, but the vertical location is just a variable in memory, so how does it know the top/bottom/left/right part of the player sprite has collided with the playfield?  Does it need data in GRP0 to do this? Is it or-ing the data, and if so how does it know where the data is?

[+splendidnut]

The TIA does pixel-to-pixel collision checks.  As the screen is being drawn, if any player0 pixel is drawn while any playfield pixel is also drawn, that bit gets set in the collision register.  So, it is essentially AND-ing the player data with the playfield data to set the collision bit.

 

EDIT:  Fixed logic error: Switched OR to AND!

[+Andrew Davie]

8 minutes ago, splendidnut said:

The TIA does pixel-to-pixel collision checks.  As the screen is being drawn, if any player0 pixel is drawn while any playfield pixel is also drawn, that bit gets set in the collision register.  So, yes, it is essentially OR-ing the player data with the playfield data.

Well, a plain OR would have the collision bit set whenever either is set, so... no i don't think that's quite it.

We want a 1 when both are 1, and 0 otherwise.  So it's an AND, right?

 

[+splendidnut]

Lol... yeah... AND!

[marienbad]

4 hours ago, splendidnut said:

The TIA does pixel-to-pixel collision checks.  As the screen is being drawn, if any player0 pixel is drawn while any playfield pixel is also drawn, that bit gets set in the collision register.  So, it is essentially AND-ing the player data with the playfield data to set the collision bit.

 

EDIT:  Fixed logic error: Switched OR to AND!

Thanks for replying with this.

 

So the collision check has to be done in the overscan, after the screen is drawn, is this correct?

Edited March 25, 2021 by marienbad

[+Andrew Davie]

3 hours ago, marienbad said:

Thanks for replying with this.

 

So the collision check has to be done in the overscan, after the screen is drawn, is this correct?

After the very first frame, the overscan and vertical blank are effectively the same thing. They are consecutive, in other words. It generally doesn't matter if you think of them both occurring before the screen is drawn, or after, or even vertical blank before, and overscan after. Really you should check collisions *after* objects are positioned AND there has been a screen drawn. OR, you should check *after* the screen is drawn and before objects are positioned. Both states preserve the collision bits  

[+SpiceWare]

23 hours ago, marienbad said:

So the collision check has to be done in the overscan, after the screen is drawn, is this correct?

 

Has to be checked after the scanline with a potential collision has been drawn, but not necessarily in overscan (or vertical blank). Many games, like Stay Frosty, use horizontal zones:

 

 

In each zone the follow occurs:

1. player1 is repositioned to draw a fireball for that zone
2. STA CXCLR is done to clear all collisions
3. the "air" above the ice is drawn (and the upper parts of the fireballs)
4. the ice blocks are drawn (and the lower parts of the fireballs)
5. the platforms are drawn
6. LDA CXPPMM and LDA CXP0FB are done to capture the collisions that occurred in this zone. Results stored in RAM for later analysis.
7. at bottom zone? If yes then go to draw score routine, if no then go back to #1 for next zone

Once the screen is finished being drawn there are 5 saved values each for CXPPMM and CXP0FB, which makes it faster when trying to figure out what the snowman may have collided with.