sprite buffer questions after reading the wiki

sprite buffer questions after reading the wiki
by mattmatteh on 2006-05-09 (#12695)

i was reading the sprite evaluation on the wiki and it appears to copy the same 4 bytes from the sprite ram (256 bytes) to the temporary ram (32 bytes). i suppose it copies the y posisiton too? but if its getting copied to the temporary ram, the sprite is already in range, seems like a waste. i was saving the comparision not the y position.

also, brad taylors doc talks about the primary object present bit in the buffer. i do not see that on hte wiki. i also printed the patent diagram for the ppu and didnt see that on it either.

matt

by mattmatteh on 2006-05-09 (#12696)

also, not sure who wrote the wiki and did those test, but anyone interested in writing a test rom for the sprite ram ? i would myself if i could.... maybe someday...

matt

by Quietust on 2006-05-09 (#12697)

Interesting that you can access the wiki, considering the QMT server (on which it is hosted) is semi-offline.

Or are you accessing the outdated (and spam-infested) wiki on http://nesdev.com/wiki?

*ahem*
For what it's worth, I'm the one who determined the low-level sprite behavior by doing carefully timed $2004 reads during rendering. If you're interested, I'll post the ROMs I used later.

The sprite's actual Y-coordinate is being stored in secondary sprite memory - for whatever reason, the PPU does the subtraction afterwards.

by mattmatteh on 2006-05-09 (#12704)

yes i have been using http://nesdev.com/wiki

do those roms test in a similiar way as blarggs test do, where its a pass or fail ? those have been really helpfull.

also, any thought on how the primary object present bit works ?

is the sprite address used by 2004 and 2014, and set by 2003 the same register used in the ppu for parsing the 64 sprites in oam and the 8 (max) sprites in the secondary buffer ? for example at the end of a scanline or mid scanline if the ppu is turned off, would a write to 2004 use the last address used byt he ppu ?

thanks

matt

by Quietust on 2006-05-09 (#12705)

No, they do not "pass" or "fail" - they simply read data out of $2004 and dump it to the screen for analysis.

Regarding the sprite 0 hit enable ("primary object present bit"), it most likely just sets it when the first sprite found in SPR-RAM happens to be within vertical range on the particular scanline, which then allows the sprite 0 hit bit to be set when the PPU renders data from the first sprite slot and generates a collision with the background.

The last value written to $2003 does affect the sprites rendered - the upper 5 bits are used to select which 2 sprites will be evaluated first (i.e. sprites 2/3, 4/5, ..., 62/63) instead of sprites 0/1, which will affect how sprite 0 hit occurs.

by mattmatteh on 2006-05-09 (#12706)

perhaps nintendo added the sprite 0 hit after the patent was filed or didnt include it. oh well.

if you could post your roms for testing that would be great. i would assume you would give the expected or actual nes results ? thanks.

i think i read a while ago about the upper 5 bits effecting which sprites are evaluated first. not sure i understand it though. if 2003 was 0x08, then evaluation would start at sprite 2 and increment to 63, then 0, then end with 1 ? i havent considered this much, as i am still working on my ppu.

thanks

matt

by mattmatteh on 2006-05-09 (#12707)

just searched the forums on that. i would think that i understand it right. would that put sprite 2 at the highest priority ? high 2, 3, 4, 5 ......60, 61, 62 ,63, 0, 1 low priority ?

thanks

matt

by Disch on 2006-05-10 (#12714)

mattmatteh wrote:
would that put sprite 2 at the highest priority ? high 2, 3, 4, 5 ......60, 61, 62 ,63, 0, 1 low priority ?

Yes and no. It will actually draw sprite 2 twice, once for sprite 0 and once for sprite 2. So you'll get:

2, 3, 2, 3, 4, 5, .... 61, 62, 63

Only sprite 0 and 1 are affected by this quirk. The other sprites use their proper values regardless of $2003