confused about something about sprite rendering

will the sprite-0-hit set when *the priority of the sprite0 is 1 and the sprite0-pixel and bg-pixel are all not zero*?
is the sprite evaluation performed in pre-scanline?
from http://wiki.nesdev.com/w/index.php/PPU_rendering i read that the ppu doesn't perform sprite evaluation in pre-scanline, so there wtill be no sprite that shows in scanline 0? Outputting of sprites starts at scanline 1? As a result, sprite-0-hit will never be set before scanline1, and sprite-overflow will never be set before scanline0.----is it right?

thanks.

AFAIK, priorities have no effect on sprite 0 hits. If two solid pixels overlap, there's a hit.


I'm confused about this myself. Historically, people used to justify the existence of the pre-render scanline with the fact that sprites are evaluated 1 scanline in advance, but this makes little since since no sprites are rendered in scanline 0.


I'm not sure of the timing details, but I believe the sprite 0 hit flag is set when the sprite is rendered, not when it's evaluated. The sprite overflow flag, on the other hand, gets set during evaluation, so if you have more than 8 sprites in scanline 1 the flag will most likely be set before scanline 1 starts.

Sprite 0 hit is always set during active picture. You can delay it by a cycle by moving the sprite 3 pixels to the right. It couldn't be set during evaluation because at that point, the PPU doesn't know what the background pixel will be.

For sprite 0 hit to happen at a particular pixel (x, y), the following must be true:

• The background must be enabled.
• Sprites must be enabled.
• The pixel must be in range of sprite 0. This allows the CPU to run ahead from the top of the picture to the top of sprite 0 and from the bottom of sprite 0 to the bottom of the picture.
• The pixel in the background must be opaque.
• The pixel in sprite 0, as flipped, must be opaque.
• x must be less than or equal to 254 (no sprite 0 hit on last pixel).
• If background or sprite clipping is enabled, x must be greater than or equal to 8.

The PPU does not consider the following at all:

• Whether the opaque pixels have a value of 1, 2, or 3, as long as they're opaque (not 0). Even if the background pixel is color 2 and the sprite pixel is color 1, that doesn't prevent sprite 0 hit.
• The color palette. A background pixel of color $02 (dark blue) and a sprite pixel of color $20 (white) will not prevent sprite 0 hit.
• The priority bit. Several of my own productions place sprite 0 behind the background.

THANKS! My SMB1 works fine after modified my sprite-0-hit trigger!

I thought the pre-render scanline was so they could get the background ready, even if the first 279 dots are pointless.

That'd probably take up too much memory to cache, I imagine backgrounds are processed on the fly (wasn't it mentioned once that background tiles were processed 8 pixels before they appear, in fact, meaning they aren't cached at all?).

I think Dwedit is referring to the last two sets of fetches of line -1 during x=320 to 335, which are for the first two tiles of line 0.

It's like starting any process. Seeking in an mp3 player is a good example. The simplest way is to seek to some arbitrary point in the file, possibly in the middle of a frame, but slightly before where you really want. Then run the decoder several frames so that any erroneous data's awful sound output will be run past, and the output synchronized and clean. This is simpler than working out how to decode cleanly from any point in a stream. Similar to that, I take it that the PPU runs an extra scanline where it'll have some junk in it, but by the end, everything will be synchronized so that it's as if it had been rendering 100 scanlines before.

at the moment between last dot of pre-scanline and first dot of scanline0, i think the first 2 tiles of scanline0 has been loaded and NO sprites in the latches/shift-registers/counters. right?