Page 1 of 1

PPU sprite evaluation question

Posted: Fri Dec 21, 2018 9:39 pm
by iOSBrett
From the Wiki on PPU sprite evaluation
Cycles 65-256: Sprite evaluation
On odd cycles, data is read from (primary) OAM
On even cycles, data is written to secondary OAM (unless secondary OAM is full, in which case it will read the value in secondary OAM instead)
1. Starting at n = 0, read a sprite's Y-coordinate (OAM[n][0], copying it to the next open slot in secondary OAM (unless 8 sprites have been found, in which case the write is ignored).
1a. If Y-coordinate is in range, copy remaining bytes of sprite data (OAM[n][1] thru OAM[n][3]) into secondary OAM.
2. Increment n
2a. If n has overflowed back to zero (all 64 sprites evaluated), go to 4
....
I can't remember where, but I read somewhere that secondary OAM is only 32 bytes in size. If that is correct then I don't understand how more than 8 sprites are evaluated per scanline. In step 1 we are copying the Y coordinate to secondary OAM even if it is not in range. I am also assuming that we skip the next 3 bytes when doing so. If this is the case then the secondary OAM will fill up after 8 sprites and will never look at the remaining 56 sprites. Which part do I have wrong?

Also I noticed in some other Emulators that the sprite evaluation is all done at cycle 256 and not over the whole visible scanline. Will this cause problems with some games, do they do mid scanline sprite magic ?

Re: PPU sprite evaluation question

Posted: Fri Dec 21, 2018 9:53 pm
by tepples
You don't have anything wrong.

Evaluation reads ordinary OAM (256 bytes, enough for 64 sprites) and writes in-range sprites to secondary OAM (32 bytes, enough for 8 sprites). Each out-of-range sprite in ordinary OAM takes 2 dots to process; each in-range sprite takes 8 dots. This means evaluation takes up to 8 * 8 + (64 - 8) * 2 = 176 dots, finishing on or before x=240.

NES games do not do mid-scanline sprite magic.

Re: PPU sprite evaluation question

Posted: Fri Dec 21, 2018 9:59 pm
by iOSBrett
But won't secondary OAM be full after checking the first 8 sprites?

Re: PPU sprite evaluation question

Posted: Fri Dec 21, 2018 10:03 pm
by lidnariq
No, because
1a. If Y-coordinate is in range, copy remaining bytes of sprite data (OAM[n][1] thru OAM[n][3]) into secondary OAM.

Re: PPU sprite evaluation question

Posted: Fri Dec 21, 2018 10:14 pm
by iOSBrett
Sorry, it still doesn't make sense to me, what does Secondary OAM look like with some in range sprites and some not in range sprites? How do we read it back if some bytes are only Y values and some are the full 4 values (X, Y, Tile, Attributes).

Code: Select all

secondaryOAM[0] = Y
secondaryOAM[1] = index
secondaryOAM[2] = attributes
secondaryOAM[3] = X
secondaryOAM[4] = Y not in range
secondaryOAM[5] = Y not in range
secondaryOAM[6] = Y
secondaryOAM[7] = index
secondaryOAM[8] = attributes
secondaryOAM[9] = X
....
secondaryOAM[30] = Y
secondaryOAM[31] = index
Now we are full and can't write the rest of the sprite information.

Sorry I know I am missing something here.

Re: PPU sprite evaluation question

Posted: Fri Dec 21, 2018 10:19 pm
by tepples
The index into secondary OAM does not increase if Y is not in range.

Code: Select all

secondaryOAM[0] = Y[0]
secondaryOAM[1] = index
secondaryOAM[2] = attributes
secondaryOAM[3] = X
secondaryOAM[4] = Y[1] not in range
secondaryOAM[4] = Y[2] not in range
secondaryOAM[4] = Y[3]
secondaryOAM[5] = index
secondaryOAM[6] = attributes
secondaryOAM[7] = X
....
secondaryOAM[28] = Y
secondaryOAM[29] = index
....

Re: PPU sprite evaluation question

Posted: Fri Dec 21, 2018 10:22 pm
by iOSBrett
Ahh got it *slaps forehead*

Thanks tepples

Re: PPU sprite evaluation question

Posted: Sat Dec 22, 2018 6:40 am
by WedNESday
Don't forget, the PPU still does some form of sprite evaluation even after 8 sprites have already been found on this scanline.

Re: PPU sprite evaluation question

Posted: Sat Dec 22, 2018 7:40 pm
by iOSBrett
Thats for sprite overflow right WedNESday?

Have actually made quick progress on the sprites once I decided to do it the quick an dirty way, everything calculated once in horizontal blank.
Still lots of stuff to fix and implement, but am happy with where I am so far.
Sprites.png

Re: PPU sprite evaluation question

Posted: Sun Dec 23, 2018 5:00 am
by WedNESday
That's correct.

Also, be warned that some games will sometimes show a sprite in the top left corner of the screen. This does not mean that your emulator is wrong. I think that 'Pacman' does it on the title screen.

Also, some games like 'Pinball' will use the background and sprites to render the title screen. Sometimes the sprite that is used to make a selection is not in perfect alignment with the background text. This confused me a great deal early on. Again, this is a programming thing.

You should read the page on the wiki entitled 'Game bugs' for more information on that sort of thing.

Re: PPU sprite evaluation question

Posted: Mon Dec 24, 2018 1:08 am
by iOSBrett
Also, be warned that some games will sometimes show a sprite in the top left corner of the screen. This does not mean that your emulator is wrong. I think that 'Pacman' does it on the title screen.
Oh I never knew that, thanks for the heads up.
Also, some games like 'Pinball' will use the background and sprites to render the title screen. Sometimes the sprite that is used to make a selection is not in perfect alignment with the background text. This confused me a great deal early on. Again, this is a programming thing.
I think even the first pink sprite on Donkey Kong Title Screen is not aligned correctly.

Fixed all my sprite bugs now too. Can't believe how easy that was compared to the rest of the PPU. I just need to implement background/sprite priority and double height sprites.
Sprites2.png