It is currently Tue Oct 17, 2017 3:39 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 9 posts ] 
Author Message
PostPosted: Mon Nov 03, 2014 4:44 pm 
Offline

Joined: Mon Nov 03, 2014 4:35 pm
Posts: 17
Can someone please clarify what this means, "Each 16x16 pixel area of the background can use the backdrop color and the three colors from one of the four background palettes."? It's from: http://wiki.nesdev.com/w/index.php/PPU_palettes

I don't understand how you differentiate the 16x16 pixel areas. Do you start in the top left corner and move left to right, top to bottom throughout your entire background?

Thanks in advance for clarification, especially visual clarification!


Top
 Profile  
 
PostPosted: Mon Nov 03, 2014 5:11 pm 
Offline
User avatar

Joined: Mon Oct 01, 2012 3:47 pm
Posts: 152
Location: freemland (NTSC-U)
8BitDreams wrote:
I don't understand how you differentiate the 16x16 pixel areas. Do you start in the top left corner and move left to right, top to bottom throughout your entire background?

Thanks in advance for clarification, especially visual clarification!


That sounds about right... this came up on ROMHacking.net recently, actually, and Proveaux made an image mapping various hex values to what background palette sets they use, found in this post. That image was then used by some guy named contra to create a Windows program for calculating things quickly.

Various other programs (such as Shiru's NES Screen Tool and most likely the nametable editor in tepples' NES tools) might also help you out, if you like seeing things more visually.


Top
 Profile  
 
PostPosted: Mon Nov 03, 2014 5:12 pm 
Offline
User avatar

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1019
Here's an image from a guide I wrote on another forum:

Image
The red/blue areas differentiate the divisions between 16x16 pixel areas. The dark/light areas differentiate the tiles. (or 8x8 pixel areas). This is the background map. (It can be larger than 256x240. Another 16x16 pixel column would start to the right or below. It's like you described, it starts from the top left corner but it can be considered to continue infinitely.)

The NES can display any part of this map starting at the screen's top left corner. (So... for instance, the second column and third row could be displayed in the top left of the screen. You can display halfway through a column, or 1 pixel into one. The display can start at any pixel.)

The way to think about it is that what's displayed on the screen is a 256x240 portion of the whole map. Which part of the map we're viewing through the screen can change, but this does not affect the map itself's 16x16 boundaries. Does that help?

_________________
https://kasumi.itch.io/indivisible


Top
 Profile  
 
PostPosted: Mon Nov 03, 2014 7:46 pm 
Offline

Joined: Mon Nov 03, 2014 4:35 pm
Posts: 17
That's a perfect reply Kasumi! Thanks for the image as well, that makes perfect sense now.


Top
 Profile  
 
PostPosted: Mon Nov 03, 2014 8:32 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10046
Location: Rio de Janeiro - Brazil
When I first started programming for the NES (like, 10 years ago!) I had some trouble understanding the alignment between the name and attribute tables. I found it strange that each name table was 256x240 pixels large while its corresponding attribute table had enough bits to color a 256x256 area. Turns out that this is just how it is... the bits responsible for coloring the non-existent 16th row of 16x16-pixel blocks simply aren't used for anything. Though I'd mention this, in case you were wondering.


Top
 Profile  
 
PostPosted: Mon Nov 03, 2014 8:44 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
For what it's worth (to the OP): understanding how the attribute table + pattern table work together was one of the hardest things for me to grasp. In fact, before I wrote nestech.txt, it really never sank in. It wasn't until my roommate at the time explained it to me in a way/with a diagram that I understood it. I was very particular about how I described it in nestech.txt; writing technical documentation is one of those things that some people do well while others don't. Kasumi's explanation (especially since it includes a picture) is highly beneficial too.

Taken from nestech.txt, just for the record:

Code:
  D. Pattern Tables
  -----------------
    The Pattern Table contains the actual 8x8 tiles which the Name Table
    refers to. It also holds the lower two (2) bits of the 4-bit colour
    matrix needed to access all 16 colours of the NES palette. Example:

       VRAM    Contents of                     Colour
       Addr   Pattern Table                    Result
      ------ ---------------                  --------
      $0000: %00010000 = $10 --+              ...1.... Periods are used to
        ..   %00000000 = $00   |              ..2.2... represent colour 0.
        ..   %01000100 = $44   |              .3...3.. Numbers represent
        ..   %00000000 = $00   +-- Bit 0      2.....2. the actual palette
        ..   %11111110 = $FE   |              1111111. colour #.
        ..   %00000000 = $00   |              2.....2.
        ..   %10000010 = $82   |              3.....3.
      $0007: %00000000 = $00 --+              ........

      $0008: %00000000 = $00 --+
        ..   %00101000 = $28   |
        ..   %01000100 = $44   |
        ..   %10000010 = $82   +-- Bit 1
        ..   %00000000 = $00   |
        ..   %10000010 = $82   |
        ..   %10000010 = $82   |
      $000F: %00000000 = $00 --+

    The result of the above Pattern Table is the character 'A', as shown
    in the "Colour Result" section in the upper right.


  E. Attribute Tables
  -------------------
    Each byte in an Attribute Table represents a 4x4 group of tiles on the
    screen. There's multiple ways to describe what the function of one (1)
    byte in the Attribute Table is:

      * Holds the upper two (2) bits of a 32x32 pixel grid, per 16x16 pixels.
      * Holds the upper two (2) bits of sixteen (16) 8x8 tiles.
      * Holds the upper two (2) bits of four (4) 4x4 tile grids.

    It's quite confusing; two graphical diagrams may help:

      +------------+------------+
      |  Square 0  |  Square 1  |  #0-F represents an 8x8 tile
      |   #0  #1   |   #4  #5   |
      |   #2  #3   |   #6  #7   |  Square [x] represents four (4) 8x8 tiles
      +------------+------------+   (i.e. a 16x16 pixel grid)
      |  Square 2  |  Square 3  |
      |   #8  #9   |   #C  #D   |
      |   #A  #B   |   #E  #F   |
      +------------+------------+

    The actual format of the attribute byte is the following (and corris-
    ponds to the above example):

       Attribute Byte
         (Square #)
      ----------------
          33221100
          ||||||+--- Upper two (2) colour bits for Square 0 (Tiles #0,1,2,3)
          ||||+----- Upper two (2) colour bits for Square 1 (Tiles #4,5,6,7)
          ||+------- Upper two (2) colour bits for Square 2 (Tiles #8,9,A,B)
          +--------- Upper two (2) colour bits for Square 3 (Tiles #C,D,E,F)


Top
 Profile  
 
PostPosted: Mon Nov 03, 2014 11:52 pm 
Offline
User avatar

Joined: Sun Oct 12, 2014 11:06 am
Posts: 123
Location: Finland
If this restriction ever becomes a problem, you can use Nintendo's MMC5 memory mapper. One of it's functions is that it allows you to assign different palette for each tile rather than 2x2 tiles.

_________________
UP SIDE DOWN A B A B B A B A Hidari migi
L R L R STOP & DASH & UP & TALK Ijou nashi


Top
 Profile  
 
PostPosted: Tue Nov 04, 2014 12:39 am 
Offline

Joined: Mon Nov 03, 2014 4:35 pm
Posts: 17
Isn't the MMC5 considerably more expensive and harder to find? I'd love to throw that restriction out the window but at what cost...


Top
 Profile  
 
PostPosted: Tue Nov 04, 2014 2:17 am 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6276
Location: Seattle
Yeah, you're not going to be manufacturing any significant number of new games using the MMC5's ExRAM.

On the other hand, there's a UNIF mapper that provides finer palette zones (designed by Quietust), and the various NES multicarts (PowerPak, InviteNES, whatever) contain more than enough RAM to support such extended modes.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 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