It is currently Wed Oct 17, 2018 6:13 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 10 posts ] 
Author Message
PostPosted: Thu Oct 27, 2005 11:06 pm 
Hi, everyone.

If i was a graphics designer/artist for the NES back in the day, what kind of limitations would i have on my images? I've read the basics - Y0SHi's NESTECH.DOC, Michael Martin's NES 101, the boards here, etc

I'm coming at this from a visual background, not a emu/coding/dev one. I understand the appearance of the graphics is caused by the design of the hardware. I understand, too, that skillful coding can work around these limitations, but i'm interested in the spec - what's the minimum?

Here's what i know, please correct...

256x224 NTSC
52 color "master" palette
25 colors max at any one time broken into two groups
1 sprite palette (12 unique colors) - 4 subgroups of 4 with the first color as transparent (same color in each subgroup)
1 background palette (13 unique colors) - 4 subgroups of 4 again with the first color mirrored again, but now as the visible "background color"
any single sprite (foreground or background) can only use one of the 4 color palette subgroups at a time
sprites are 8x8 or 8x16 pixels
color and appearance of each sprite is separate, allowing for palette swaps and color animation
64 different sprites max at any time
there are two planes - the foreground and background layer

what i don't know...

1. how do the 8x8 screen tiles and the attribute table work with the background sprites? How are background tiles different from foreground sprites?
2. are there any limitations on the color choices in the sprite and background palettes inside the 4 subgroups? Is the sprite transparent-color and the background "first-color" always the same color?
3. 8 sprites max per scan line, but how many can I layer on top of each other? Look at the intro screen for Zelda 1. The logo, sword and plant are all different sprites but are layered seemingly three deep - what about the two planes only?

Any advice is appreciated.


Top
  
 
PostPosted: Fri Oct 28, 2005 12:37 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20662
Location: NE Indiana, USA (NTSC)
me wrote:
Here's what i know, please correct...

256x224 NTSC

The NES generates a 256x240 pixel image; TVs may cut off the top and bottom 8 to 16 lines depending on how they're adjusted.

Quote:
1. how do the 8x8 screen tiles and the attribute table work with the background sprites? How are background tiles different from foreground sprites?

Four 8x8 tiles in a 2x2 square make up each attribute tile, selecting which palette to use with those 8x8 tiles. If you've played Super Mario Bros. or Super Mario Bros. 3, each tile is the size of a Image block.

Quote:
2. are there any limitations on the color choices in the sprite and background palettes inside the 4 subgroups? Is the sprite transparent-color and the background "first-color" always the same color?

The transparent color of the sprite will always show up as whatever pixels are behind it.

Quote:
3. 8 sprites max per scan line, but how many can I layer on top of each other? Look at the intro screen for Zelda 1. The logo, sword and plant are all different sprites but are layered seemingly three deep - what about the two planes only?

All 8 sprites on a line can be layered on top of one another. The "two planes only" seems to refer to the fact that a sprite can be drawn on top of or behind the background.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Oct 28, 2005 12:54 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1849
** NOTE **

I had typed this all up a while ago... but for some reason the boards weren't letting me reply. tepples already answered most of this, but I figured I'd still post it anyway since it still might help:





- 256x224 NTSC

That is typically what is visible on most NTSC displays, yes. However the NES still renders the full 256x240. Just the top and bottom scanlines are usually "cut off" from view.

You have the right idea with the palette from a programming standpoint... however if you want to get really technical $3Fx4,3Fx8, and 3FxC do NOT mirror 3Fx0... they each contain their own unique color.. however that color cannot [normally] be used. $3F00 is not really the "transparent color"... it's just the color which is used to fill the screen when no other pixel is supplied (see below).


To answer your Qs:

1) sprites with background priority will be drawn "underneath" the background. To put this in a diagram which may help:

Code:
Foreground sprites <-- top layer
------------------
Background (name/attribute tables)
------------------
Background sprites
------------------
Background color ($3F00)  <-- lowest layer


The top layer (foreground sprites) will be drawn if it exists. If it is transparent, then the BG is drawn.... if the BG is transparent, the the background sprite is drawn... if that's transparent, then $3F00 is used to fill in the gap.

(there is a quirk involving sprites, though.. sprite priority is determined before the sprite pixel is run through above logic. Therefore:

if sprite 0 has BG priority, and sprite 1 has FG priority, and they're on top of each other, then sprite 0 wins the sprite priority fight -- but since it has BG priority, the background is actually what will be drawn to the screen -- despite sprite 1 having foreground priority)


2) No, you can put whatever colors you want in any of the subgroups. However there is no transparent color. A pixel value of 0 is transparent, regardless of what color happens to be stored in the palette ($3Fx0,$3Fx4,$3Fx8,$3FxC). Transparent pixels are never drawn (if they were drawn, they wouldn't be transparent ;P )

There is some weird mirroring with those color 0 palettes:
$3F10 mirrors $3F00
$3F14 mirrors $3F04
$3F18 mirrors $3F08
$3F1C mirrors $3F0C

so you can use either $3F10 or $3F00 to set the background color... however 3F04 and the others set their own entry in the palette (which again... is never normally drawn)

If you don't care about being all that... just know that:
- $3Fx4,3Fx8,3FxC don't really matter, since they're never drawn. They're always transparent, no matter what color you put there.
- $3F00 or $3F10 sets the background color -- whichever you write to last


3) As far as I know you can layer all 8 on top of each other, and the highest priority one will be picked out for each pixel


Top
 Profile  
 
 Post subject:
PostPosted: Sat Oct 29, 2005 5:12 pm 
tepples & Disch – thanks! This helps a lot. Now that it's clearer, I also see most of this is right there in the NESTECH.DOC (sheepish grin)...

So, basically, what I'm seeing (visually) on screen at any moment is the result of the Name Table, Attribute Table/SPR-RAM, Pattern Table and Image/Sprite Palettes.

A Name Table is a 32x30 array that defines the arrangement of elements in the Background (in a grid). Each entry in a Name Table refers to the tile number of a 8x8 pixel element (thus 256x240 NTSC) in a Pattern Table.

A Pattern Table consists of 256 8x8 pixel elements made of the lower two bits of the 4-bits of color possible. It's like defining the “areas of different color” and what pixels not to draw (color 0). The NES can hold two Patterns Tables in the system RAM at a time. It collects entries from these two Pattern Tables to fill out the 64 sprites possible at a time. The actual runtime appearance of any element is determined in the Sprite RAM (SPR-RAM) or an Attribute Table (for the Background).

Each byte in an Attribute Table holds the remaining two bits of color information for 4 2x2 sections (16x16 pixels each or 32x32 pixels per Table) of the Name Table. Thus, I can only assign different Background (Image) “sub-palettes” in 4x4 tile (16x16 pixel) groups – like a single “brick” in Super Mario Bros.

Each sprite gets its' remaining color bits plus it's x,y position, tile index, horz/vert flipping and Background priority from what's loaded into the SPR-RAM.


1.The 64-sprite limitation of the SPR-RAM doesn't effect the elements used in the Background Image tiles? If I had no sprites (ie, no mario, koopas, goobas, etc), i could use the entire 512 entries in the two Pattern Tables to create the Background Image?

2.(Back to Zelda 1...) I see in the Pattern Table that Link is built from 4 sprites. His on-screen “wholeness” is created at runtime by the code (very smart - lets you swap out just one 8x8 pixel sprite to create a walk-cycle). Because he's a sprite and not a Background tile, I could use a different Sprite sub-Palette to color each of his “quarters”?

3.No “transparent colors”, but how are semi-transparent effects created? Like after Mario gets “hurt” and shrinks in size.

Thanks again.


Top
  
 
 Post subject:
PostPosted: Sat Oct 29, 2005 6:49 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1437
me wrote:
1.The 64-sprite limitation of the SPR-RAM doesn't effect the elements used in the Background Image tiles? If I had no sprites (ie, no mario, koopas, goobas, etc), i could use the entire 512 entries in the two Pattern Tables to create the Background Image?


They are independent - you can only use 256 background tiles at once because there are only 256 possible values you can store in each tile's memory location. With additional hardware (such as the MMC5), you can bypass this limitation rather easily.

Quote:
2.(Back to Zelda 1...) I see in the Pattern Table that Link is built from 4 sprites. His on-screen “wholeness” is created at runtime by the code (very smart - lets you swap out just one 8x8 pixel sprite to create a walk-cycle). Because he's a sprite and not a Background tile, I could use a different Sprite sub-Palette to color each of his “quarters”?


Correct - each sprite has its own color selection bits.

Quote:
3.No “transparent colors”, but how are semi-transparent effects created? Like after Mario gets “hurt” and shrinks in size.


That's not transparency. That's flickering, which may appear similar to transparency on your television set.

_________________
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:
PostPosted: Sat Oct 29, 2005 10:17 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20662
Location: NE Indiana, USA (NTSC)
me wrote:
2.(Back to Zelda 1...) I see in the Pattern Table that Link is built from 4 sprites. His on-screen “wholeness” is created at runtime by the code (very smart - lets you swap out just one 8x8 pixel sprite to create a walk-cycle).

Hold it. You're not likely to get a convincing walk-cycle by just swapping out leg cels. You need to take the arms into account too, as in Super Mario Bros.

Quote:
Because he's a sprite and not a Background tile, I could use a different Sprite sub-Palette to color each of his “quarters”?

Contra does exactly this for player sprites, splitting at the belt.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Oct 31, 2005 11:43 pm 
okay. i'm beginning to understand. There's a method and order to it.

I read that, on a hardware level, the old atari 2600 worked from the idea that all games consisted of a playing field, two players (paddles) and a single "missile" (the ball) - all games were PONG. Everything that proceeded after was a skillful hack on that original idea. It seems like the NES has its own baseline, too - the sprite and tile side-scroller (Super Mario Bros. and the like). It's amazing how far you can stretch one good idea.

thanks for the feedback.

ps - i make these little movies, maybe you all will enjoy them...
http://www.sunshine.tc/index_winner.html


Top
  
 
 Post subject:
PostPosted: Wed Nov 02, 2005 7:45 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10897
Location: Rio de Janeiro - Brazil
I guess this happens all the time. A console is designed with current games in mind, but new ideas start to pop and the game makers start tweaking the console, working around it's limitations to implement these new ideas. Then, new platforms are designed, with built-in support for the stuff that needed tweaking earlier. This still happens 'til this day.


Top
 Profile  
 
PostPosted: Wed Feb 15, 2006 12:01 pm 
flickering??... yeah, i know that when 9 sprites is on one scanline, you have to making a sprite cicle in ppu..then 8 sprites appears and another dissapears very fast...then it's not notorious... but if i wanna making "2 sprites in width" like super mario bros flickering.. it's the same technique???


Top
  
 
 Post subject:
PostPosted: Fri Feb 17, 2006 12:42 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10897
Location: Rio de Janeiro - Brazil
Well, kinda. The flickering you get from sprite cycling exists because we don't want to to loose any sprites. We'd rather have them flickering than completely invisible, but ideally, they would not be flickering. But in the case of Mario getting hurt, you actually want him to flicker. So you'd just not render his individual sprites to the OAM (or would place them off-screen, whatever). This is the only way to be sure they'll not show up.

The effect you get is basically the same. Subsequent frames with and without the sprite. There fact is that there will be frames where the sprite will not be rendered, be it because you explicitly removed it, or because there are too many sprites in the scanline.


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: samophlange and 2 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