Sprite buffer.

[Muhammad_R4]

Hello NES DEV

I have a question may be somehow strange.

I have implemented successfully , both of sprite rendering and BG rendering blocks in the PPU ( in vhdl )

each of them works the right way when tested alone , the problem comes when integrating both and using the priority MUX

as far as I knew , the bit 5 in the attribure byte of the sprite is used as a selection for this mux , my problem is that after the sprite is

drawn , no background again is drawn till the end of the scanline, I knew the reason , this is because that after the sprite , the priority

logic still sees the same data ( i.e.: 2 pattern register , attribute register) so for sure the background won't be drawn in this line


I think there is a logical problem in the priority calculation I did so what I want to know the right logic and what is done when the sprite in the current scan line is rendered ?

what I implemented is :

Code: Select all

N.B: & = concatenation
attribute bit_5 of the sprite being rendered =
  sprite0.attribute_byte.bit5  if ( (iam rendering now) and (sprite0_x has reached 0) and ( upper 2 palette bits & patter plane1 bit & pattern plane0 bit = "00"     ) )

else : the same but sprite1 till reaching 7 




I use the " attribute bit_5 of the sprite being rendered " as the selection of the mux 

[Dwedit]

Editing post to ensure consistent terminology.. (Priority bit that sprites have vs higher priority due to lower sprite number)

Sprites are drawn so that the lower-numbered sprite takes precedence over a higher-numbered sprite. Higher-numbered sprites aren't drawn if pixels from a lower-numbered sprite have already been drawn.
For each pixel drawn, it will emit a pixel, and a priority bit for that pixel. If a pixel from a lower-numbered sprite has been drawn, no pixels from higher-numbered sprites will be drawn in the same place.
This is why the sprite-on-sprite masking trick works, the lower-numbered sprite will be drawn as low priority, and will prevent the pixels from the higher-numbered sprites from being drawn.
Only pixels present in the lower-numbered sprite will give a priority bit for that pixel. Transparent areas don't affect later sprites.

Sounds like your issue might be due to priority flag being computed once, and not separately per pixel?

[Quietust]

More concisely, the PPU first determines which sprite to display in a particular pixel (taking the first nontransparent one it finds), and only then does it check where to display it (i.e. in front of the background or behind it).