I am not an NES developer. I am, however, developing a game that will imitate the visual aesthetic of the NES. I may opt to ignore some of the system's limitations, but I would like to understand exactly what these limitations are before I choose which ones to ignore.

The system's capabilities as I understand them are as follows:-Standard resolution of 256 by 240, NTSC resolution of 256 by 224 with the top eight and bottom eight scanlines cropped.-A built in palette of something like 52 or 54 unique colors. This is not an RGB palette, which means I probably can't use a true NES palette and will likely have to settle for a reasonable facsimile.-Can use up to four different 3-color palettes for tiles plus four different 3-color palettes for sprites plus one background color at a time.-Two sets of 256 8x8 tiles in memory at once.-One scrolling layer.-Up to 64 sprites at once; up to 8 sprites on a single scanline.-Sprites are 8x8 or 8x16, globally. 8x16 sprites use consecutive tiles from their tileset. Thus, if an 8x16 sprite only uses one 8x8 tile, the tileset includes a consecutive 8x8 tile that is blank.-Sprites can be flipped horizontally or vertically. Background tiles cannot.-Offscreen buffer on only one scrolling axis at a time.

Let me know if I forgot anything important.As I learned more about the NES and continued to develop the concept of my game, several questions came up concerning the capabilities of the NES. I was hoping somebody here might be able to help me understand it.

1. As I understand it, several of the limitations of the NES, such as color palettes and the single scrolling layer, can be waived on a per-scanline basis. Are there practical limitations on how this can be done? What kind of techniques would actually be viable in a commercial NES game?

2. I don't know what color emphasis is or how it works. What does color emphasis do, and what are the limitations on its use?

3. Can the NES reload tilesets on a per-scanline basis? If a game makes use of a status bar, do the tiles for the status bar have to come from the same tilesets as the terrain and/or sprite? Another example: Suppose I have a game that scrolls quickly between areas when the borders are approached, like Zelda 1. Can I scroll vertically between two areas that use different tilesets? What about horizontally?

4. Sprite flicker actually feels kind of gimmicky to me in a contemporary game, but, hypothetically, let's say I opt to include it. How could I accurately replicate its appearance?

5. I don't plan on including four-direction scrolling in my game, but as a simple point of curiosity, I'm wondering about the graphical implications of scrolling artifacts. This may become relevant if I include oversized boss monsters.

Thanks in advance for any help. Please remember, I'm not developing for the NES itself, so I'm less interested in the functions of the hardware as I am in their implications on the graphics. A lot of the technical aspects are likely to go over my head. I'm interested in how far the system's graphics could be pushed, but I also want to temper this information with an understanding of what techniques are viable in commercial games, as well as which ones were in common use. Feel free to provide example games. Thanks again.

-A built in palette of something like 52 or 54 unique colors. This is not an RGB palette, which means I probably can't use a true NES palette and will likely have to settle for a reasonable facsimile.

54. It's 14×4=56-2, because 1 is invalid (blacker than black) and 1 is redundant (two whites)

Quote:

-Offscreen buffer on only one scrolling axis at a time.

True but misleading. Some games (e.g. Gauntlet) added extra memory to get arbitrary scrolling without any artifacts. Even for those that didn't, the only side effect would be incorrect colors or patterns in places.

1. As I understand it, several of the limitations of the NES, such as color palettes and the single scrolling layer, can be waived on a per-scanline basis. Are there practical limitations on how this can be done? What kind of techniques would actually be viable in a commercial NES game?

AIUI, it isn't really possible to change color palettes per scanline. The amount of time it takes to change a single palette entry ((6×7-9)CPU cycles, or 99 pixels out of the 341 pixel scanline) is too long to fit in the 85 pixel horizontal blanking period. It would be possible to change most (16 of the 25, one of which must be the background) of the colors in the palette at the cost of a one scanline gap that would show a rainbow of each of the colors that were being replaced.The scrolling offset can be set to an arbitrary value for each scanline, anywhere in the 512x480 pixel space. It would be extremely tricky to change it more often, but is plausible.Any game with a vertically split screen, status bar (not just letters), or raster effects (q.v. thefox's demo High Hopes) uses changing of scroll.Any time spent doing raster effects, however, reduces time for other computation, such as AI or collision checking. This holds for the following two points, as well.

Quote:

2. I don't know what color emphasis is or how it works. What does color emphasis do, and what are the limitations on its use?

Color emphasis makes all colors darker, and tilts the hue towards red, green, or blue. With two bits set, the incremental darkening is smaller, but the added hue angle is linear (i.e. CMY); with all three bits set it is just darker. It can be changed at an arbitrary time, up to once every 12-18 pixels or so, but the CPU's slower speed means you cannot rely on more precise positioning than ~4 pixels left to right (it will shake, if the edge is onscreen). You probably want to look at the example by blargg

Quote:

3. Can the NES reload tilesets on a per-scanline basis? If a game makes use of a status bar, do the tiles for the status bar have to come from the same tilesets as the terrain and/or sprite? Another example: Suppose I have a game that scrolls quickly between areas when the borders are approached, like Zelda 1. Can I scroll vertically between two areas that use different tilesets? What about horizontally?

Changing banks is entirely permissible as frequently as desired, as often as color emphasis changes. In practice you probably won't want to change more often than once per scanline basis. See my silly raster display here, which changes color emphasis, CHR banks, and attribute banks every scanline.

Quote:

4. Sprite flicker actually feels kind of gimmicky to me in a contemporary game, but, hypothetically, let's say I opt to include it. How could I accurately replicate its appearance?

For each scanline of sprites, if more than 8 are on the scanline, drop all of but eight of them. For best appearance, which ones are dropped should probably rotate.

Quote:

5. I don't plan on including four-direction scrolling in my game, but as a simple point of curiosity, I'm wondering about the graphical implications of scrolling artifacts. This may become relevant if I include oversized boss monsters.

It depends on what constraints you're working with. For example, SMB3 has artifacts because it uses vertical layout of the two tables, because it stuffs the status bar into one of them. These appear as the tiles on the edge of the screen flipping to the wrong color. On the other hand, horizontal layout would prevent any visible artifacts on NTSC, at the cost of not having a status bar.Or you could just pretend to be using extra memory for nametables and ignore it.

Thank you very much for your help. I've already learned a lot. I had no idea that pixels had a ratio of 8:7. I wonder if I'll be able to find a way to replicate this.

lidnariq wrote:

AIUI, it isn't really possible to change color palettes per scanline. The amount of time it takes to change a single palette entry ((6×7-9)CPU cycles, or 99 pixels out of the 341 pixel scanline) is too long to fit in the 85 pixel horizontal blanking period.

This is the first I've heard of a scanline being 341 pixels or of an 85 pixel blanking period. That blanking period must be where games make most of their dramatic alterations then?

Quote:

It would be possible to change most (16 of the 25, one of which must be the background) of the colors in the palette at the cost of a one scanline gap that would show a rainbow of each of the colors that were being replaced.

I'd be interested in seeing that.

Quote:

The scrolling offset can be set to an arbitrary value for each scanline, anywhere in the 512x480 pixel space. It would be extremely tricky to change it more often, but is plausible.Any game with a vertically split screen, status bar (not just letters), or raster effects (q.v. thefox's demo High Hopes) uses changing of scroll.

When you say vertically split screen, do you mean that the line dividing the two segments is oriented vertically? I don't think I've seen such a thing. I have seen games that divide the screen into horizontal segments with independant scrolling, sometimes four or more at once, to fairly impressive ends. Unfortunately, I was unable to get High Hopes to run for some reason (I tried it in nestopia.)

Quote:

It can be changed at an arbitrary time, up to once every 12-18 pixels or so, but the CPU's slower speed means you cannot rely on more precise positioning than ~4 pixels left to right (it will shake, if the edge is onscreen).

If the edge is in that blanking period, though, then the shaking wouldn't be a problem?

Quote:

Changing banks is entirely permissible as frequently as desired, as often as color emphasis changes. In practice you probably won't want to change more often than once per scanline basis. See my silly raster display here, which changes color emphasis, CHR banks, and attribute banks every scanline.

I was worried about this, as it seems the limit of two sets of 256 tiles is an obstacle. I've been working on a little mock-up demonstration .swf file, and I've noticed that even the terrain uses more than half my alotted tiles, without considering the addition of a status bar. This is largely because several of my terrain tiles are animated. For animated background tiles, each frame of the tile does have to be accounted for in my tilesets, right?

Quote:

For each scanline of sprites, if more than 8 are on the scanline, drop all of but eight of them. For best appearance, which ones are dropped should probably rotate.

If this is for each scanline, then does that mean a sprite can be partially dropped, if only part of it shares scanlines with other sprites? What is the rate at which they generally flicker? I believe I heard somewhere that the NES usually has an FPS of 60.

-Can use up to four different 3-color palettes for tiles plus four different 3-color palettes for sprites plus one background color at a time.

Each of the four tile palettes applies to one 16x16 pixel area (size of SMB1 ? block). One way to practice using this limitation is to try a nametable editor. This includes Shiru's NESST, which runs on a PC, or mine that runs on an NES.

Quote:

Can the NES reload tilesets on a per-scanline basis? If a game makes use of a status bar, do the tiles for the status bar have to come from the same tilesets as the terrain and/or sprite?

If you have a sufficiently large CHR ROM or a sufficiently large CHR RAM, you can bankswitch CHR between scanlines or even (in limited cases, with about 24 pixels of blank space on each side like in Marble Madness) within a scanline if you time it right. Scrolling vertically between tilesets might work, but horizontally won't unless you use a specialized ASIC used in about a dozen carts.

Sprite flicker is an artifact of the eight sprites limit and comes from alternating which sprite is in front so that the limit doesn't chop off the same sprites each frame.

I had no idea that pixels had a ratio of 8:7. I wonder if I'll be able to find a way to replicate this.

The common way is to render to a 256x240 pixel texture, scale that up to 512x480 by 2:1 using nearest neighbor, then scale that to 584x480 using linear or better interpolation.

Quote:

This is the first I've heard of a scanline being 341 pixels or of an 85 pixel blanking period. That blanking period must be where games make most of their dramatic alterations then?

You can't update video memory during horizontal blanking because the PPU is busy fetching sprite patterns during that time. It's possible to update about five rows or columns of the nametable during vertical blanking.

Quote:

I'd be interested in seeing that.

Chris Covell's Sayoonara demo does that, while turning on the monochrome bit to mask the palette update.

Quote:

Unfortunately, I was unable to get High Hopes to run for some reason (I tried it in nestopia.)

High Hopes is PAL-only. It will not run on a Famicom. It will not run on a North American NES. You have to tell your emulator to emulate a PAL NES.

Quote:

For animated background tiles, each frame of the tile does have to be accounted for in my tilesets, right?

That depends on whether you want to simulate CHR ROM or CHR RAM. CHR RAM can animate tiles, but it takes vertical blanking time away from updating the nametable: two tiles instead of one row or column. CHR ROM can also animate tiles; try running Super Mario Bros. 3 in a debugging emulator such as FCEUX or Nintendulator to see this happen.

Quote:

If this is for each scanline, then does that mean a sprite can be partially dropped, if only part of it shares scanlines with other sprites?

Yes.

Quote:

What is the rate at which they generally flicker? I believe I heard somewhere that the NES usually has an FPS of 60.

Different games use different flicker patterns.

Post a mock screenshot and we'll point out what can and can't be done on NES.

This is largely because several of my terrain tiles are animated. For animated background tiles, each frame of the tile does have to be accounted for in my tilesets, right?

Yes, but you don't need to have all animation frames mapped in at all times. NES games with animated backgrounds typically select new CHR banks every frame to change what the background looks like. The beauty of this is that you don't need to redraw the background at all, since (e.g.) tile $7B is still the exact same part of a bush, only the leaves moved a bit.

This kind of animation is practly "free", because the various animation frames don't need extra tile slots and the actual change of patterns is instantaneous when using CHR-ROM. The only real cost is ROM storage, but in your NES-like environment that's unlimited.

As an example, Super Mario 3 has 1k CHR ROM switching, meaning it can swap out 64 tiles in a bank. I believe all of its animated tiles are packed into one set of 4 1k banks (4 frames of animation) that are used throughout the whole game.

This is the first I've heard of a scanline being 341 pixels or of an 85 pixel blanking period. That blanking period must be where games make most of their dramatic alterations then?

As tepples pointed out, it's rather the 22 scanlines of blanking out of 262 of vertical blanking in which the updates happened. This is enough time to upload approximately 160 tiles without going to herculean efforts.

Quote:

When you say vertically split screen, do you mean that the line dividing the two segments is oriented vertically?

No, horizontally. Terminology, bleh. Top half of the screen is one thing, bottom half is another. Possibly with a third thing making a status bar.The MMC5 supports a mode where you can get a left-and-right split screen, but you cannot change the horizontal scrolling amount on each side, so you are now constrained to only scrolling your active playfield every eight pixels. One side of that can be further split top-and-bottom an arbitrary number of times.

Quote:

If the edge is in that blanking period, though, then the shaking wouldn't be a problem?

Correct.

Quote:

I was worried about this, as it seems the limit of two sets of 256 tiles is an obstacle. I've been working on a little mock-up demonstration .swf file, and I've noticed that even the terrain uses more than half my alotted tiles, without considering the addition of a status bar. This is largely because several of my terrain tiles are animated. For animated background tiles, each frame of the tile does have to be accounted for in my tilesets, right?

As other people have pointed out, not only do you not have to have all the frames mapped at the same time—you can have up to eight separate groups which all update asynchronously—but several other mappers allow for even finer quantization. The MMC2 (PunchOut!!) and MMC4 (first two Fire Emblem games, Japan only) allow the game to automatically switch between entirely unrelated 256 tile banks when a specific tile is fetched, allowing the use of up to 510 tiles for background almost arbitrarily placed. Furthermore, the MMC5 (Castlevania 3) supports a mode where each tile can be chosen from one of 16384 but it takes twice as many writes for the CPU to update it, halving the maximum update speeds.

Quote:

If this is for each scanline, then does that mean a sprite can be partially dropped, if only part of it shares scanlines with other sprites? What is the rate at which they generally flicker? I believe I heard somewhere that the NES usually has an FPS of 60.

Different games have different flicker patterns, with differing levels of annoyance. The higher you get above 8, those harder it is to make it look acceptable. Above 16 is right out.A few games explicitly used flicker intentionally, which does help with the total sprite limit. (e.g. Parodius's laser weapon)

tepples wrote:

Each of the four tile palettes applies to one 16x16 pixel area (size of SMB1 ? block).

The same feature that lets the MMC5 draw up to 16384 randomly-juxtaposed tiles additionally allows it a separate palette for each 8x8 tile. Very few games used it, though, and it doesn't look very NES-like.

Thanks, everyone. The impression I'm getting from many of these posts is that any given horizontal span of pixels represents a certain amount of processing time. This is a really unusual way of thinking for me.

tokumaru wrote:

Yes, but you don't need to have all animation frames mapped in at all times. NES games with animated backgrounds typically select new CHR banks every frame to change what the background looks like.

I had assumed that frames of animated tiles needed to be mapped in at once, but if animation can be done by switching CHR banks, then I may not be over my tile limit yet.

rainwarrior wrote:

As an example, Super Mario 3 has 1k CHR ROM switching, meaning it can swap out 64 tiles in a bank.

Then, am I to infer that there are limitations to how many tiles can be changed at once?

tepples wrote:

Post a mock screenshot and we'll point out what can and can't be done on NES.

I did make a few examples. Maybe they can help clarify a few things.

The example.gif file is an animated mock screenshot. It doesn't use all the background tiles that I've made. It shows how some of the tiles would be animated.

In example tiles.png, different sets of tiles would be used for different sections of the screen. Differentiating between the first two sections isn't strictly necessary in my example, but it could allow for greater detail in backgrounds. It is necessary, though, for the status bar. If I'm not mistaken, this example would require changing CHR banks three times a frame, including twice between scanlines.

Example palettes.png shows what I have in mind for changing the palettes between scanlines. My use of sprite palettes is somewhat uninspired, but it's just an example. If I use only a single palette for the status bar, then I would only need to change four colors maximum, including the background. If I understand correctly, this transition would leave color artifacts on one of my scanlines, correct?

I quickly whipped up an ugly boss monster just for example scrolling.png. Here, the screen is broken into four sections that have different rates of horizontal scrolling. I believe the GI Joe game does exactly this, but I don't know whether that game uses any special hardware. Regarding parallax effects, I understand that some games simulate it using animated background tiles, and I suspect some games may do both at the same time.

Now, let's assume I want to do some of these things at the same time. My boss monster probably doesn't use the same tilesets as the scenery, and it is likely to be animated itself. Furthermore, the status bar is still in place during the boss encounter and has its changed palette. And hey, just for fun, let's imagine I wanted to change the color emphasis of one of these sections, because why not? I could end up with a lot of changes going on at once. Could the NES handle something like this?

By the way, I did get High Hopes to work. It's really impressive. Do those effects pretty much exhaust processing? Or could they be used as a backdrop while something else happened?

As an example, Super Mario 3 has 1k CHR ROM switching, meaning it can swap out 64 tiles in a bank.

Then, am I to infer that there are limitations to how many tiles can be changed at once?

There's not really a limit, bankswitching is a very fast operation it's not directly limited, but in real NES games ROM space was generally at a premium. In general, games that do extensive flipbook animation have a mapper that has 1k CHR banks (64 tiles per bank) and dedicates a single shared set of pages to that flipbook (e.g. SMB3, Sword Master, Return of the Joker). Open these games in FCEUX and go to Debug > PPU Viewer to see what's going on.

Of course, if you're making the game, you'd get to decide how much CHR-ROM is reasonable, and how much to budget for animations, so that's why there isn't really a limit, but what these examples show that it was typical to conserve the banks a bit. See how Sword Master has 4 16-tile flipbooks in the same set of banks, and uses one of them in each level, for example. This way it uses 32 banks to do the parallax flipbook for the entire game. SMB3 looks like it has a 4-frame flipbook made of 128 tiles that contains most of the animated tiles in the game (coins, jellyfish, the scrolling ? block, waterfalls, chomping piranhas, etc.), and this has the important limitation that all tile animations are 4 frames, and also factors into the unique tile budget for any particular level (128 are always occupied by the animated tiles).

I dunno if that's useful in trying to make a mock NES game, but generally animated tiles are implemented in some global scheme that has particular limitations. It's very common for the number of frames in the animation to be a power of two, for instance. Maybe this is kinda non-obvious stuff from the outside, though, might not be important in trying to capture the "feel" of NES tile animation.

Everything you've shown in those screenshots should be possible in a later era NES game, but there would probably be an ugly multicolored flickering line between the main playfield and the status bar from changing the palettes. You could change the bank of background tiles on every line you're splitting the screen if you wanted to. You could also scroll at least one of these sections vertically as well, but that could also cause a flickering line between sections if the lines around the split aren't all one solid color.

Early NES games usually did not split the screen in more than one place, because splitting the screen at a particular spot required polling a PPU register until a flag was set in it on a specific line (from a Sprite 0 hit) or manipulating the frame counter or delta modulation channel in the sound chip to cause an interrupt after a particular number of cycles. Either of these methods would tie up the CPU for a significant amount of time each frame, either polling the register for the Sprite 0 hit flag or running cycle-timed code, where all possible branches need to take the same amount of time, which makes it difficult to do actual calculations for the game state. Also, early games did not have much space for graphics and banking wasn't very granular, so background tiles did not tend to be animated.

Later cartridges (after 1988 or so) could include more graphics memory which could be bankswitched in smaller increments, making animation and fake parallax scrolling possible. More importantly, later cartridges included some type of scanline counter which would count off a certain number of either PPU scan lines or CPU clocks, depending on the implementation. This could interrupt the CPU, so games could include multiple horizontal splits in the screen during gameplay without losing significant amounts of processing time.

Another common feature of later era NES games was that they tended to use different shades of the same hue in each sprite palette, and then stack multiple sprites with different palettes to form the player character or enemies. Also, black lines were usually included around the edges of sprites to prevent dot crawl artifacts around the edges. For a good example of this, look at Mega Man or Shatterhand.

Everything you've shown in those screenshots should be possible in a later era NES game, but there would probably be an ugly multicolored flickering line between the main playfield and the status bar from changing the palettes.

I believe, since he's only changing four colors, that he might be able to time it such that all the multicolor would be offscreen. Each hblank is enough time for six writes + three loads, and only 6+#colors writes are needed.The line would, however, be solid brown or tan, not black.

You could also scroll at least one of these sections vertically as well, but that could also cause a flickering line between sections if the lines around the split aren't all one solid color.

I think Super Mario Bros 3 did this. In level 3-3, the status bar didn't scroll, the water scrolled horizontally, and the stage terrain scrolled in four directions.

Speaking of Super Mario Bros 3, I did take a peek at it in the PPU viewer, as rainwarrior suggested. Nearly half the background tiles were constantly switching. What I also found interesting is that the sprite tiles also switch when you get a power up, as well as every time you jump while in a powered up form. I'm afraid I'm still a little unclear though on why all of the animated background tiles had to be in memory all the time, even if they weren't featured in the current stage. Those jellyfish didn't show up that often.

I also noticed that Super Mario Bros 3 features a flickering color artifact on the left side of the top scanline of the status bar. Most of the time, it's the color of the stage's background and it fluctuates in width between 0, 8, 24 and 32 pixels. In most cases where the background is black, it can't be seen, but there are exceptions. When approaching a stage's goal, it seems that a black flickering section appears on the next scanline up. Does SMB3 only change the background color in this case? In my example, as many as four colors are changed for the status bar. What kind of mess would that make?

An alternative for the status bar is to simply have it change colors in different areas. I can't think of any game that does this with a status bar, but if I remember correctly, Final Fantasy 3 featured NPCs who occasionally followed you around, and they would change colors depending on which map you were on. Since I'm working with imported image files though, and can't do a proper palette swap as far as I know, that would actually take up more time and space.

I'm afraid I'm still a little unclear though on why all of the animated background tiles had to be in memory all the time, even if they weren't featured in the current stage. Those jellyfish didn't show up that often.

The ASIC on the Super Mario Bros. 3 circuit board that controls bank switching and scanline counting is called MMC3. It allows the background half of the pattern table to be split in half (two 128 tile windows) and the sprite half to be split in fourths (four 64 tile windows), or vice versa. Think about this: A game might have five different flipbooks, 24 tiles each. But the mapper swaps 128 tiles at a time, so you just put all five flipbooks into different parts of the 128-tile window.

Again, if you are animating only a few tiles at a time, you can always use CHR RAM.

Quote:

I also noticed that Super Mario Bros 3 features a flickering color artifact on the left side of the top scanline of the status bar. Most of the time, it's the color of the stage's background and it fluctuates in width between 0, 8, 24 and 32 pixels.

I'm pretty sure that's actually a result of setting the scroll position at not exactly the right time. SMB3 was one of the first games to use MMC3, and Nintendo thought getting it out the door to players all across Japan in 1988 was more important than making the transition completely clean.

Quote:

In most cases where the background is black, it can't be seen, but there are exceptions. When approaching a stage's goal, it seems that a black flickering section appears on the next scanline up. Does SMB3 only change the background color in this case?

That's a surefire sign of only setting the scroll.

Quote:

In my example, as many as four colors are changed for the status bar. What kind of mess would that make?

What would happen if you use your water palette for the mountain in the back? In the real world, the reason bodies of water appear blue is that they reflect the blue sky. Nor do clouds move anything like that. And are the tree stumps higher in the back?

Quote:

Since I'm working with imported image files though, and can't do a proper palette swap as far as I know, that would actually take up more time and space.

One of my PC games stores sprite sheets in imported image files but can do a palette swap because the files are stored in indexed color mode and the game rewrites the loaded sprite sheets' indexed palette before blitting the files to the canvas.

Who is online

Users browsing this forum: No registered users and 2 guests

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