Talk:PPU sprite evaluation: Difference between revisions

From NESdev Wiki
Jump to navigationJump to search
m (→‎Sprite zero with sprites disabled: more appropriate diff in link)
Line 13: Line 13:


:I added a brief definition at the top of the page, and I tried to break up the removed sentence into a couple of ideas that I hope are more clear. ([http://wiki.nesdev.org/w/index.php?title=PPU_sprite_evaluation&diff=12889&oldid=12382 revision 12889]) - [[User:Rainwarrior|Rainwarrior]] ([[User talk:Rainwarrior|talk]]) 11:27, 6 September 2016 (MDT)
:I added a brief definition at the top of the page, and I tried to break up the removed sentence into a couple of ideas that I hope are more clear. ([http://wiki.nesdev.org/w/index.php?title=PPU_sprite_evaluation&diff=12889&oldid=12382 revision 12889]) - [[User:Rainwarrior|Rainwarrior]] ([[User talk:Rainwarrior|talk]]) 11:27, 6 September 2016 (MDT)
::Cool. Again, let me rephrase it. If the emulator (PPU) evaluates sprites at the pre-render scanline (-1), the sprite zero hit test will give an error. Simple. People that don't understand the PPU sprite evaluation proccess should read about it more and more, ever and ever... until it's clear. Crying here isn't good.--[[User:Zepper|Zepper]] ([[User talk:Zepper|talk]]) 15:38, 6 September 2016 (MDT)

Revision as of 21:38, 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)

I added a brief definition at the top of the page, and I tried to break up the removed sentence into a couple of ideas that I hope are more clear. (revision 12889) - Rainwarrior (talk) 11:27, 6 September 2016 (MDT)
Cool. Again, let me rephrase it. If the emulator (PPU) evaluates sprites at the pre-render scanline (-1), the sprite zero hit test will give an error. Simple. People that don't understand the PPU sprite evaluation proccess should read about it more and more, ever and ever... until it's clear. Crying here isn't good.--Zepper (talk) 15:38, 6 September 2016 (MDT)