Understanding the sprite rendering process

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Post Reply
pherrymason
Posts: 4
Joined: Sun Jun 26, 2022 12:27 pm

Understanding the sprite rendering process

Post by pherrymason »

Hi all.
I'm having problems understanding the full cycle of sprite evaluation from here https://www.nesdev.org/wiki/PPU_sprite_evaluation.

The point that confuses me is the first step, clearing the secondary OAM.
It says:
Cycles 1-64: Secondary OAM (32-byte buffer for current sprites on scanline) is initialized to $FF
How is this initialization happennig?
Should I clear all 32 bytes every cycle? Or one byte every two cycles?

What also confuses me is, if each scanline we are looking for the sprites to be rendered on the next scanline, how are we clearing the secondary oam just at the beginning of each scanline?
Doesn't this initialization destroy the information I need to render the sprite pixels on the current scanline?
I know there's also the pattern shifters for the sprites, but those does not contain coordinates nor attribute information... Does this means my emulator should keep a copy of secondary OAM for the current scanline?
User avatar
Dwedit
Posts: 4924
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: Understanding the sprite rendering process

Post by Dwedit »

I haven't looked at the actual silicon, but I think clearing every other cycle sounds right.
That way you can have one cycle of processing dedicated to getting the Write Buffer register ready, then on the next cycle, you can put that value into memory.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
pherrymason
Posts: 4
Joined: Sun Jun 26, 2022 12:27 pm

Re: Understanding the sprite rendering process

Post by pherrymason »

Dwedit wrote: Tue Aug 02, 2022 11:58 am I haven't looked at the actual silicon, but I think clearing every other cycle sounds right.
That way you can have one cycle of processing dedicated to getting the Write Buffer register ready, then on the next cycle, you can put that value into memory.
Ok!
About my second doubt... how does clearing this seconday oam data not interfere with the first 64 pixels of possible sprites being rendered?
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Understanding the sprite rendering process

Post by lidnariq »

Because sprite evaluation goes as:
* [cy 0-63] Clear secondary OAM
* [cy 64-255] Figure out what 8 sprites are the ones that get drawn on the current scanline and fill secondary OAM accordingly
* [cy 256-320] Fetch the picture data for those 8 sprites and put them in separate dedicated hardware for drawing them

On the following scanline, the dedicated hardware is what does the actual rendering. Secondary OAM has to be reset to figure out what sprites are to be drawn on the following scanline.
Post Reply