I really dont understand when sprite zero hit flag is up. I mean what i do is to check if the sprite pixel is not invisible (sprites), and then i check bk pixel is not invisible too.
Can somebody help me?
Code is welcome.
The sprite #0 strike bit is set when the first non-transparent sprite pixel inhabits a non-transparent background pixel. This sprite #0 tile lies on sprite ram order (or sprite[0]), NOT on 8-sprites temporary buffer.
If the two pixels overlap, then the bit is set immediately, cleared a bit before the VBlank ending.
i still dont understand well, but thanks anyway
Pasting code would be hard, since it's hard to show through code without showing the workings of a big chunk of the PPU =P
Anyway.... you should know that there's 341 PPU cycles per scanline. (On an NTSC system, this works out to 113.6666667 CPU cycles, but to keep things simpler, I'll speak in PPU cycles). When doing the 240 scanlines that actually render pixels... the first 256 cycles of the scanline each render 1 pixel.
When a non-transparent sprite zero pixel is rendered on top of (or below depending on sprite 0's priority) a non-transparent BG pixel, the sprite 0 hit flag is set... and remains set until the end of VBlank on the following frame (when all 3 bits of $2002 are cleared).
So for example... let's say that you have a full solid (nontransparent) background... and a full solid sprite zero. Sprite 0 has a Y value of $0F (to be drawn on the 17th rendered scanline)... and has an X value of $4F (79 in decimal).
On an NTSC system.... to figure out how many cycles from the start of VBlank until sprite zero is hit (all in PPU cycles):
20 * 341 <--- Length of VBlank (20 scanlines of VBlank)
+ 341 <--- there's a dummy scanline between VBlank and the first rendered scanline (note that every odd frame this scanline is 340 cycles, not 341)
+ 16 * 341 <--- there's 16 scanlines rendered before sprite 0
+ 79 <--- 79 pixels into the scanline, it's first hit
= 12958 PPU cycles --- which equates to ~4319.333333 cpu cycles on an NTSC system (from the start of VBlank, until sprite zero is hit)
thanks now i got it better
Hmm I thought a y value of $0F means it would be displayed on the 16th rendered scanline (not including the dummy). Thus there would be 15 rendered scanlines before sprite0.
It's worded weird.
There are no sprites on scanline 0 (first rendered), so if a sprite has a Y value of $00, it will be rendered on scanline 1... which is the 2nd rendered scanline. So a Y value of $0F (15) would be rendered on scanline $10 (16), which is the 17th rendered.
Conflicts between zero-based numbering and 1-based numbering. The scanline numbers themselves are zero based, but when you talk about the order in which they're rendered, you're talking 1-based. (You wouldn't say scanline 0 is the 0th rendered scanline... instead you'd say it's the 1st)