Talk:PPU sprite evaluation: Difference between revisions

From NESdev Wiki
Jump to navigationJump to search
mNo edit summary
No edit summary
Line 8: Line 8:
::Man, you must be kidding now. It's not my fault if "sprite evaluation" is a vague term to you, sorry. Anyway, the sprite zero test FAILS (plain and simple) if the PPU sprite evaluation starts at scanline -1 (pre-render scanline). It should start at scanline 0, the first visible scanline. --[[User:Zepper|Zepper]] ([[User talk:Zepper|talk]]) 19:39, 5 September 2016 (MDT)
::Man, you must be kidding now. It's not my fault if "sprite evaluation" is a vague term to you, sorry. Anyway, the sprite zero test FAILS (plain and simple) if the PPU sprite evaluation starts at scanline -1 (pre-render scanline). It should start at scanline 0, the first visible scanline. --[[User:Zepper|Zepper]] ([[User talk:Zepper|talk]]) 19:39, 5 September 2016 (MDT)
::http://wiki.nesdev.org/w/index.php/PPU_sprite_evaluation
::http://wiki.nesdev.org/w/index.php/PPU_sprite_evaluation
Sprite evaluation *is* vague. It could mean fetch OAM data into temporary OAM or fetch data from VRAM based on temporary OAM data, and also the setting of sprite #0 and overflow flags. 3 different things. Also if might be mistaken, but sprite zero hit won't work either if sprites are enabled but not BG. You rally need both enabled for it to work. Disabling only sprites or only BG just replace them by blank patterns insternally, but still fetches the pattern in VRAM and internally replace them with all 0s, I guess. (Bregalad)
[[Special:Contributions/128.178.126.68|128.178.126.68]] 07:21, 6 September 2016 (MDT)

Revision as of 13:21, 6 September 2016

Sprite zero with sprites disabled

The article says: "According to the blargg's sprite zero hit tests, sprites are NOT evaluated in the pre-render scanline. Plus, the evaluation occurs if sprites OR background are enabled."

I find the second sentence problematic. I took it to mean that the sprite zero flag will still be set even if sprites are disabled in PPUMASK. But in fact it will not. I was pretty annoyed to find that out the hard way! So what is this trying to say, then? - Furrykef (talk) 01:10, 30 August 2016 (MDT)

I think this is worded very confusingly. Sprite "evaluation" is a vague and unclear term, especially since you've determined that sprite 0 hit won't be caused when sprites are disabled. I think it means that the OAM is accessed and refreshed as long as either the sprites or background are enabled. This is important for OAM decay, at least, but I don't know about other factors. Does sprite overflow still happen is sprites are disabled, but the background is? (Is that what "sprite evaluation" means?) Does sprite 0 hit still happen? (No. Right?) I think the whole sentence is a bit worthless as-is, to be honest. I think I'll delete it. - Rainwarrior (talk) 01:36, 30 August 2016 (MDT)
Man, you must be kidding now. It's not my fault if "sprite evaluation" is a vague term to you, sorry. Anyway, the sprite zero test FAILS (plain and simple) if the PPU sprite evaluation starts at scanline -1 (pre-render scanline). It should start at scanline 0, the first visible scanline. --Zepper (talk) 19:39, 5 September 2016 (MDT)
http://wiki.nesdev.org/w/index.php/PPU_sprite_evaluation

Sprite evaluation *is* vague. It could mean fetch OAM data into temporary OAM or fetch data from VRAM based on temporary OAM data, and also the setting of sprite #0 and overflow flags. 3 different things. Also if might be mistaken, but sprite zero hit won't work either if sprites are enabled but not BG. You rally need both enabled for it to work. Disabling only sprites or only BG just replace them by blank patterns insternally, but still fetches the pattern in VRAM and internally replace them with all 0s, I guess. (Bregalad) 128.178.126.68 07:21, 6 September 2016 (MDT)