Hi everyone,
I am in the process of adding sprite support after implementing cycle-accurate PPU rendering for backgrounds - I have a few questions regarding sprites and I'm sure some of you may be able to help.
1) First of all, I saw in the wiki that during sprite evaluation, sprites *in the next scanline* are copied from primary to secondary OAM if they are "in range". I assume this means if (ppu_v + 1 >= sprite_y) && (ppu_v + 1 < sprite_y + sprite_height). I am unsure about the "ppu_v + 1" instead of "ppu_v", could you please confirm?
2) My second question is in regards to the sprite fetching phase. As the circuitry probably does not keep track of how many sprites were actually copied to secondary OAM, I assume it parses all the 8 possible visible sprites no matter what. I saw on the wiki that if the tile number is detected as 0xFF, it fills the high and low registers with transparent data. What about the attributes and the X counter? Does it also fill them as if it was a visible sprite? That would mean both attribute and X counter latches would contain 0xFF. Is that correct?
3) Another issue I noticed is that my sprites are all shifted by 16 pixels to the left. After some debugging, I realized what caused this issue but I'm not sure on how to fix this in a clear fashion. Here's the problem: during sprite fetching, the sprite X counters are reloaded. The wiki mentions that every cycle, a bit is fetched from the 4 BG shift registers. Down below, it also mentions that every cycle, the 8 x-positions counters for the sprites are decremented by one. The obvious issue that I encountered is that the X counters start decrementing on the same scanline as the sprite fetching phase, because I included the decrementing logic "as part" of the background shifting logic (the BG shifters also shift between cycles 322 and 337, which is why I have a sprite offset). If I add a check for only decrementing the X counters between cycles 2 and 257 (included), then the problem disappears. If this is the right way to implement this, then this means that what the wiki considers "every cycle" is actually different for background and sprites. Can you please confirm this?
4) I would also like to understand if the X counter decrementing logic happens *after* checking if the X counter is 0 (and becoming active) or before. Basically, that would mean that if a sprite X counter is 0 after the sprite fetching phase and the decrementing happens before check its value, the X counter would be 0xFF resulting in the sprite never being drawn. Is that correct?
5) Lastly, I would like to make sure that the X counter decrementing logic starts indeed at cycle 2 or if it should start at 0.
That's all I have for now! Looking forward to your responses.
Regards,
Sebastien
I am in the process of adding sprite support after implementing cycle-accurate PPU rendering for backgrounds - I have a few questions regarding sprites and I'm sure some of you may be able to help.
1) First of all, I saw in the wiki that during sprite evaluation, sprites *in the next scanline* are copied from primary to secondary OAM if they are "in range". I assume this means if (ppu_v + 1 >= sprite_y) && (ppu_v + 1 < sprite_y + sprite_height). I am unsure about the "ppu_v + 1" instead of "ppu_v", could you please confirm?
2) My second question is in regards to the sprite fetching phase. As the circuitry probably does not keep track of how many sprites were actually copied to secondary OAM, I assume it parses all the 8 possible visible sprites no matter what. I saw on the wiki that if the tile number is detected as 0xFF, it fills the high and low registers with transparent data. What about the attributes and the X counter? Does it also fill them as if it was a visible sprite? That would mean both attribute and X counter latches would contain 0xFF. Is that correct?
3) Another issue I noticed is that my sprites are all shifted by 16 pixels to the left. After some debugging, I realized what caused this issue but I'm not sure on how to fix this in a clear fashion. Here's the problem: during sprite fetching, the sprite X counters are reloaded. The wiki mentions that every cycle, a bit is fetched from the 4 BG shift registers. Down below, it also mentions that every cycle, the 8 x-positions counters for the sprites are decremented by one. The obvious issue that I encountered is that the X counters start decrementing on the same scanline as the sprite fetching phase, because I included the decrementing logic "as part" of the background shifting logic (the BG shifters also shift between cycles 322 and 337, which is why I have a sprite offset). If I add a check for only decrementing the X counters between cycles 2 and 257 (included), then the problem disappears. If this is the right way to implement this, then this means that what the wiki considers "every cycle" is actually different for background and sprites. Can you please confirm this?
4) I would also like to understand if the X counter decrementing logic happens *after* checking if the X counter is 0 (and becoming active) or before. Basically, that would mean that if a sprite X counter is 0 after the sprite fetching phase and the decrementing happens before check its value, the X counter would be 0xFF resulting in the sprite never being drawn. Is that correct?
5) Lastly, I would like to make sure that the X counter decrementing logic starts indeed at cycle 2 or if it should start at 0.
That's all I have for now! Looking forward to your responses.
Regards,
Sebastien