PPU sprite evaluation question

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Post Reply
User avatar
iOSBrett
Posts: 38
Joined: Wed Apr 18, 2018 1:09 am
Location: Australia

PPU sprite evaluation question

Post 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 ?
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: PPU sprite evaluation question

Post 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.
User avatar
iOSBrett
Posts: 38
Joined: Wed Apr 18, 2018 1:09 am
Location: Australia

Re: PPU sprite evaluation question

Post by iOSBrett »

But won't secondary OAM be full after checking the first 8 sprites?
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: PPU sprite evaluation question

Post 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.
User avatar
iOSBrett
Posts: 38
Joined: Wed Apr 18, 2018 1:09 am
Location: Australia

Re: PPU sprite evaluation question

Post 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.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: PPU sprite evaluation question

Post 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
....
User avatar
iOSBrett
Posts: 38
Joined: Wed Apr 18, 2018 1:09 am
Location: Australia

Re: PPU sprite evaluation question

Post by iOSBrett »

Ahh got it *slaps forehead*

Thanks tepples
WedNESday
Posts: 1284
Joined: Thu Sep 15, 2005 9:23 am
Location: Berlin, Germany
Contact:

Re: PPU sprite evaluation question

Post 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.
User avatar
iOSBrett
Posts: 38
Joined: Wed Apr 18, 2018 1:09 am
Location: Australia

Re: PPU sprite evaluation question

Post 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
WedNESday
Posts: 1284
Joined: Thu Sep 15, 2005 9:23 am
Location: Berlin, Germany
Contact:

Re: PPU sprite evaluation question

Post 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.
User avatar
iOSBrett
Posts: 38
Joined: Wed Apr 18, 2018 1:09 am
Location: Australia

Re: PPU sprite evaluation question

Post 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
Post Reply