It is currently Tue Oct 24, 2017 2:47 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 37 posts ]  Go to page Previous  1, 2, 3
Author Message
 Post subject: Re: Background rendering
PostPosted: Thu Jul 21, 2016 12:09 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19122
Location: NE Indiana, USA (NTSC)
Fixing the mux selection will work with games that only ever scroll horizontally to a multiple of 8 pixels. It should suffice if you plan to make your NES emulator or hardware implementation compatible only with non-scrolling games or games that scroll only vertically. Thus it'll probably work with most of my NROM games, including Concentration Room, Thwaite, RHDE: Furniture Fight, robotfindskitten, and the menu of Action 53.

But it will cause games that scroll horizontally other than to a multiple of 8 pixels to scroll jumpily, and the background scrolling will fall out of synchronization with the movement of sprites. This visible artifact will annoy the player. It may also cause games that use the sprite 0 hit feature to crash, as the opaque part of the sprite may end up not overlapping the opaque part of the background, and thus bit 6 of $2002 never becomes true.


Top
 Profile  
 
 Post subject: Re: Background rendering
PostPosted: Thu Jul 21, 2016 6:18 pm 
Offline

Joined: Sat Jun 25, 2016 5:33 am
Posts: 66
so I can say that if I am now implementing background rendering unit without scrolling feature now - only fetches a frame and render it -
this will be good for this right ?


Top
 Profile  
 
 Post subject: Re: Background rendering
PostPosted: Thu Jul 21, 2016 7:33 pm 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 3944
My attempt at explaining the background pixel pipeline...

Let's say we are getting to the beginning of the scanline.
16 pixels were already computed. It's 4 bits per pixel here, so it can pick any color from the background palette.

ppppppppPPPPPPPP

Every time the PPU wants to draw a dot, it picks which dot it wants to draw using horizontal fine X. So if it's 0, it takes the left value, if it's 7, it takes the eighth pixel, etc.
Fine x could take ANY of the first 8 pixels here.

Then after that, they all are shifted one pixel to the left.
pppppppPPPPPPPP_

6 dots later, it has drawn 7 pixels...

pPPPPPPPP _______

then one dot later, it has drawn 8 pixels

PPPPPPPP________

After it has finished with the 8 pixels, the 8 new pixels have been calculated and are ready to be drawn, so the ________ can be filled in with new pixel data.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
 Post subject: Re: Background rendering
PostPosted: Fri Jul 22, 2016 2:38 am 
Offline

Joined: Sat Jun 25, 2016 5:33 am
Posts: 66
Dwedit wrote:
My attempt at explaining the background pixel pipeline...

Let's say we are getting to the beginning of the scanline.
16 pixels were already computed. It's 4 bits per pixel here, so it can pick any color from the background palette.

ppppppppPPPPPPPP

Every time the PPU wants to draw a dot, it picks which dot it wants to draw using horizontal fine X. So if it's 0, it takes the left value, if it's 7, it takes the eighth pixel, etc.
Fine x could take ANY of the first 8 pixels here.

Then after that, they all are shifted one pixel to the left.
pppppppPPPPPPPP_

6 dots later, it has drawn 7 pixels...

pPPPPPPPP _______

then one dot later, it has drawn 8 pixels

PPPPPPPP________

After it has finished with the 8 pixels, the 8 new pixels have been calculated and are ready to be drawn, so the ________ can be filled in with new pixel data.



That's what exactly I am asking about

I can't join the concept of the fine_x which is a part of the first write to 0x2005 register ( i.e. : the horizontal address part of top left tile in the next frame to make scrolling and fine x determine a pixel exactly inside this tile )

I can't join the above with the fine_x used here in BG pipeline

In another words , I understands how it works but don't understand why it is implemented like this , why fine_x is used here

There must be something I can't see and this what I am searching for.

I hope you understand me all :)


Top
 Profile  
 
 Post subject: Re: Background rendering
PostPosted: Fri Jul 22, 2016 10:18 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10068
Location: Rio de Janeiro - Brazil
A total of 34 tiles are shifted through this 16-pixel window during 1 scanline. If you always sampled the same position of this buffer (say, pixel 0), you'd only be able to scroll in 8-pixel increments. In order to be able to scroll the screen smoothly, the PPU uses the fine X scroll to select 1 of 8 possible positions of the window to be sampled.

If I understand correctly, it works something like this:

Code:
          [********] (new tiles)
           |      |
           v      v
[********][********] (16-pixel window)
 |
 v
 01234567 (fine X scroll)

The window is shifted left each time a pixel is rendered, and every 8 pixels, 8 new pixels are read from the pattern tables and put at the top of the window. The fine X scroll determines which pixel of the window will be output to the screen. If the fine scroll is 0, the very first pixel of the first tile will be visible. If it's 1, the first pixel will never be used, because the second pixel will be picked, and so on. The fine X scroll just determines which pixel of the rotating buffer you're gonna use to render the picture.


Top
 Profile  
 
 Post subject: Re: Background rendering
PostPosted: Fri Jul 22, 2016 10:54 am 
Offline

Joined: Sat Jun 25, 2016 5:33 am
Posts: 66
That's my problem , I can understand the relation between selecting a pixels from the BG buffers using fine_x ( which can be changed using first write to 0x2005 )

and its meaning as the pixel in the tile pointed to by the X_Coarse which forms the starting address of top left pixel on scrolling in the next frame.

I will give an example for what confuses me

If first write to 2005 is 001010 001 , this means that - as far as I understood - on the next frame , the top left tile from which scrolling start = the tenth tile , pxl no 001 ( neglecting Y now )

as you all said , this means that in BG pixel pipeline , the mux selection will be 001

my problem now is I can't understand why it works in this way , I want to understand the relation between this write and its meaning as the left top most tile ( fine_X = which pixel inside this tile ) and the selection of this BG pipeline mux.


Top
 Profile  
 
 Post subject: Re: Background rendering
PostPosted: Mon Jul 25, 2016 7:40 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19122
Location: NE Indiana, USA (NTSC)
The SIPO produces eight background pictures on its outputs:
  • A picture
  • The same picture scrolled left by one pixel
  • The same picture scrolled left by two pixels
  • The same picture scrolled left by three pixels
  • The same picture scrolled left by four pixels
  • The same picture scrolled left by five pixels
  • The same picture scrolled left by six pixels
  • The same picture scrolled left by seven pixels

The fine X scroll controls which of these pictures is actually sent to the rest of the PPU.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 37 posts ]  Go to page Previous  1, 2, 3

All times are UTC - 7 hours


Who is online

Users browsing this forum: FrankenGraphics, Sumez and 7 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