It is currently Sun Dec 17, 2017 4:33 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 12 posts ] 
Author Message
 Post subject: PPU rendering
PostPosted: Wed Jun 29, 2016 2:46 pm 
Offline

Joined: Sat Jun 25, 2016 5:33 am
Posts: 66
I have some questions about the way PPU render both sprites and background

I knew that for every scanline , the 256 px is feed from the sprite and background buffer ( after being multiplexed on priority ) such that a px come out each PPU clock

here I have two questions :
1 - Does the rendered graphics in both buffers are fetched in the same 341 PPU clock of the same scanline ?
i.e : does the rendered graphics appearing now on scanline M are fetched immediately before rendering or they are fetched at the end of scanline M-1 and rendered on the screen on scanline M ( who comes first rendering now then fetch the next or fetch now and render now )

2 - Does both Image rendering engine and Background rendering engine work in parallel ? or sequentially ?

I hope I explained my questions well.

Thank's in advance


Top
 Profile  
 
 Post subject: Re: PPU rendering
PostPosted: Wed Jun 29, 2016 3:20 pm 
Offline
User avatar

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 950
Most of the information you want is here. Here's a (too-)brief summary/interpretation.

Rendering is fetched eight BG pixels at a time, as follows:
  1. Nametable fetch
  2. Attribute table fetch (which palette)
  3. Pattern table fetch, plane 0
  4. Pattern table fetch, plane 1

Quote:
Every cycle, the 8 x-position counters for the sprites are decremented by one. For each sprite, if the counter is still nonzero, nothing else happens. If the counter is zero, the sprite becomes "active", and the respective pair of shift registers for the sprite is shifted once every cycle.


Sprites are checked to see which eight (the first eight found) should appear on the next scanline. This happens concurrently with the BG fetches. This covers this in detail. Note that, as they don't do this on the pre-render scanline, sprites get 1 added to their Y position and can't appear on line 0.


Top
 Profile  
 
 Post subject: Re: PPU rendering
PostPosted: Wed Jun 29, 2016 4:03 pm 
Offline

Joined: Sat Jun 25, 2016 5:33 am
Posts: 66
Sorry I didn't get it

I know how render stages flow for both BG and sprites, but I am confused how if they are parallel they access the memory both in the same time

also if now I am in scanline 4 , do I in the last steps in 4 fetch graphics for scanline 5 ( next scanline ) then start scanline 5 by rendering
or when I am in scanline 5 I fetch then Render to screen


Top
 Profile  
 
 Post subject: Re: PPU rendering
PostPosted: Wed Jun 29, 2016 4:33 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1393
They don't access the same memory at the same time - background memory fetches happen during cycles 0-255 and 320-335 (and go into a 4x16 shift register), and sprite memory fetches happen during cycles 256-319 (and go into eight separate 2x8 shift registers).

_________________
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.


Last edited by Quietust on Wed Jun 29, 2016 4:35 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: PPU rendering
PostPosted: Wed Jun 29, 2016 4:34 pm 
Offline
User avatar

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 950
Sprite OAM (where sprite priority, flip, and positions) is on its own bus, so can happen in parallel with the BG rendering.

Sprite pattern fetches…I had to look it up. It's in this diagram ("sprite tile fetch", each scanline, cycles/dots 257-320)


Top
 Profile  
 
 Post subject: Re: PPU rendering
PostPosted: Wed Jun 29, 2016 5:26 pm 
Offline

Joined: Sat Jun 25, 2016 5:33 am
Posts: 66
As I understood from you now and from search ( and tell me If I am right or not )

- sprites for scanline 4 was ready in the buffers by the end of scanline 3 and the shift registers out them from clock 0 -> 256 in scanline 4

- sprites memory has its own bus so both background and sprites can be fetched in parallel.

That's OK but there is another confusing matter

I have read here ( page 19 ) ( http://ece545.com/F15/reports/F07_NES.pdf ) that rendering to screen occurs in clocks form 0 -> 256

that is very nice with sprites as they were ready in the buffers from the previous scanline
but what about the backgrounds ?

It will be very nice if the fetched background bytes in scanline 3 will be used in scanline 4

Am I ture ?


Top
 Profile  
 
 Post subject: Re: PPU rendering
PostPosted: Wed Jun 29, 2016 5:32 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19354
Location: NE Indiana, USA (NTSC)
With backgrounds, the bytes fetched during scanline 3 are used during scanline 3.

With sprites:
The OAM is scanned for sprites that intersect scanline 3 during scanline 3.
The corresponding pattern bytes are fetched during the horizontal blanking between scanline 3 and scanline 4.
The pattern bytes are used during scanline 4.
This 1-line delay between scanning OAM and actually displaying the sprites is responsible for sprites appearing a line below their actual position.


Top
 Profile  
 
 Post subject: Re: PPU rendering
PostPosted: Wed Jun 29, 2016 5:33 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6538
Location: Seattle
No, background tiles are fetched just in time, approximately 16ish pixels before they're displayed.


Top
 Profile  
 
 Post subject: Re: PPU rendering
PostPosted: Wed Jun 29, 2016 5:57 pm 
Offline

Joined: Sat Jun 25, 2016 5:33 am
Posts: 66
So that's why it fetches th 1st two tiles of scanline 4 by the end of scanline 3 ?

Will it differ a lot if I implemented it in a shifted way ( ie : rendering on the screen in the last 256 clock , filling the sprite buffers and fetching background data from clk 0 to clk (340-265 ) ?


Top
 Profile  
 
 Post subject: Re: PPU rendering
PostPosted: Thu Jun 30, 2016 5:15 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1393
Muhammad_R4 wrote:
Will it differ a lot if I implemented it in a shifted way ( ie : rendering on the screen in the last 256 clock , filling the sprite buffers and fetching background data from clk 0 to clk (340-265 ) ?

Some NES games perform mid-scanline bank switching, so changing the times at which background/sprite tiles are fetched will cause graphical glitches in those games.

_________________
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.


Top
 Profile  
 
 Post subject: Re: PPU rendering
PostPosted: Thu Jun 30, 2016 5:39 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19354
Location: NE Indiana, USA (NTSC)
Five games I can think of that perform mid-scanline bankswitching are Pirates, Marble Madness, Punch-Out!!, Fire Emblem, and Famicom Wars.


Top
 Profile  
 
 Post subject: Re: PPU rendering
PostPosted: Thu Jun 30, 2016 6:49 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1393
tepples wrote:
Five games I can think of that perform mid-scanline bankswitching are Pirates, Marble Madness, Punch-Out!!, Fire Emblem, and Famicom Wars.

The first two, along with Mother (J), are the important ones because their mid-scanline bank switches are cycle-timed - the others (Punch-Out, Fire Emblem, and Famicom Wars, which the MMC2 and MMC4) have their bankswitches triggered by tile fetches, so as long as it happens in the correct order they'll work fine.

_________________
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 12 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group