Like tepples said, the contents of secondary OAM doesn't matter while sprite zero hit detection is taking place. There are eight internal sprite output units (my terminology - can't think of anything clearer ) that handle the actual sprite drawing - the secondary OAM is just a list of sprites with which to initialize them (during ticks 257-320).proxy wrote:So I know that there is some curiosity about why you've observed pixel rendering being delayed about 4 dots. I have a theory which may or may not make sense, but here it goes .
The pattern of behavior for the PPU is basically the following:
dots: 0-64 = clear S-OAM
dots: 65-256 = fill S-OAM with data for next scanline.
at the same time:
dots 0-256 = render background and sprite pixels for the current scanline.
But, as far as I understand that means that there is a possible conflict if this is done naively. If sprite 0's x position is say 32 pixels into the scanline, that means that its data will be overwritten with $FFs well before it is rendered, making it end up as garbage!
My hypothesis is that the 4 pixel delay for rendering is enough to allow an algorithm (which I have not thought of the specifics yet) to avoid this conflict.
Thoughts?
What I suspect is going on is that the first pixel leaves the shifters at h=2. The palette entry for the pixel then needs to be looked up, which takes another two ticks, so that the first pixel is drawn at h=4. (Sprite zero hit detection only needs to know whether the pattern bits are both zero, and so doesn't need the palette lookup.)
Edit: "Sprite drawing units" would be a bit clearer.