It is currently Sat Oct 21, 2017 8:01 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 3 posts ] 
Author Message
 Post subject: Sprite buffer.
PostPosted: Sun Jul 31, 2016 2:59 pm 
Offline

Joined: Sat Jun 25, 2016 5:33 am
Posts: 66
Hello NES DEV :D

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:
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


Top
 Profile  
 
 Post subject: Re: Sprite buffer.
PostPosted: Tue Aug 02, 2016 7:00 am 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 3943
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?

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
 Post subject: Re: Sprite buffer.
PostPosted: Wed Aug 03, 2016 4:38 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1389
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).

_________________
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 3 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 6 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group