Questions about NES Graphics Limitations

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.

Your NTSC definition is a little loose; see our measurements on the wiki of real-world sets.
54. It's 14×4=56-2, because 1 is invalid (blacker than black) and 1 is redundant (two whites)
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.
Pixel aspect ratio. Pixels are 8:7 w:h; just slightly wider than square.
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.
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
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.
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.
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.
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?
I'd be interested in seeing that.
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.)
If the edge is in that blanking period, though, then the shaking wouldn't be a problem?
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?
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.

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.


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.

For scrolling artifacts, see the wiki page about nametable mirroring.


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.


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.


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


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.


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.


Yes.


Different games use different flicker patterns.

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

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.

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.
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.
Correct.
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.
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)
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.

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.
Then, am I to infer that there are limitations to how many tiles can be changed at once?

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?

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.

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.

Also, if you want to make NES backgrounds that you can be certain obey the NES limits, I highly recommend playing with Shiru's NES screen tool: http://shiru.untergrund.net/files/nesst.zip

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.

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.


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.


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


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?


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.

Ah, that isn't exactly what I meant. Switching palette colors would compromise one of my scanlines with a rainbow of colors; I was wondering just what that would look like.
But Super Mario Bros 3 doesn't do that, then? Were mid-screen palette changes done in many commercial games?
I might be better off assuming one of my background palettes is globally dedicated to the status bar. Especially if I chose colors for it that were also useful in drawing scenery.

For example, the following games changes palette for status bar:
-Wizard & Warriors.
-Fantastic Adventurers of Dizzy.
-Dizzy the adventurer.
-Tom and Jerry.

And I'm sure there's are other games that do that too.

As for SMB3- It do not do that, not for Status bar, at least.

I think you should be able to update up to 6 palette entries without any visible rainbow of colors.

If you want to see what the spray of colors looks like, in its most extreme form, the demo Tepples mentioned by ccovell (Sayoonara!) is here. But as tepples also mentioned, it's mostly invisible because ccovell uses the greyscale bit in the NES, which converts all 54 colors to one of three greys.

edit: grammar

Yeah, if you don't need to restore the scroll then you can change a few colors per scanline without visible glitches. The real problem is when you want to do this in the middle of the picture and can't afford any blank lines between the areas with different palettes.

Thanks a lot for all your help, guys. I'm making a lot of progress, and I've learned a lot from this thread:
-Some games have four-direction scrolling without artifacts by adding extra memory.
-Pixel aspect ratio is 8:7.
-Scrolling can be changed between scanlines
-Color emphasis can be changed between scanlines. Incidentally, I've discovered that I can imitate color emphasis almost perfectly in my game by applying some combination of pure red, green or blue to my image, each at 25% opacity in the Darken blending mode.
-While background tiles are 8x8, tile palettes apply to 16x16 areas (without special hardware.)
-Sprites can be partially dropped when the sprites per scanline limit is exceeded.
-The color limit in sprite palettes can be circumvented by stacking sprites on top of each other. While I noticed this in Mega Man a while back, I hadn't known if it was a common practice. Alternatively, the top half of a character can use a different palette than the bottom half, like in Final Fantasy 1.

Unfortunately, I think I'm still a little fuzzy on changing tilesets. Apologies for my confusion on the topic. You guys have told me a lot about it, but I'm still kind of cunclear (it doesn't really help that I'm not entirely familiar with all of the technical terms.) If I'm understanding correctly, I could normally swap out up to 64 tiles at a time. Is this between scanlines, or just between frames? Are there other limitations on what tiles I can swap out or swap in? Other mappers would allow for more flexibility... do those involve special hardware? Of course, if lidnariq's raster display is any indication, I could draw pretty much whatever I want, hypothetically...

I'm also concerned about my status bar still. For the status bar I need to change tilesets, palettes AND scrolling, all between scanlines and at the same time. Is that plausible? Lidnariq indicated that I might be able to keep the multicolor artifacts from palette changing offscreen, as I'm only changing four colors. As it stands, the first scanline of my status bar would require two color changes, the second would require a third and the fourth color change wouldn't be needed until the third scanline, if it makes a difference. Also, sometimes the upper screen would scroll vertically instead of horizontally.

Between scanlines.
Effectively, no.
You have enough time to change 6 things invisibly per scanline; after that it'll start happening during the visible portion. Specifically in the case of palette changes, the first and last three are lost to overhead. Fortunately, those last three writes involve a coarse scroll change, so setting scrolling after a palette change is mostly free. Therefore, rendering has to be disabled for a palette change, so any tileset changes or fine scrolling changes done during this blank time will be invisible and so don't count against the limit.
The overhead involved in changing a color is large enough that it's best to change them all at the same time, and regardless you will need a blank line in which to do so.

It's also possible to get rid of these artifacts without extra memory, but that usually involves some sort of sacrifice (e.g. a column of sprites at the right of the screen - which wastes sprites and effectively drops the sprites-per-scanline limit to 7 - or a total of 16 blanked scanlines distributed between the top and bottom of the screen). I guess it's probably better for you to go with the extra memory explanation. =)


That's perfectly safe to do between scanlines.


The only real limitation is that the finest chunks an existing mapper can swap are 1KB (i.e. 64 tiles). If you don't want to change 64 tiles at once, you'll have to repeat the tiles you don't want to change across different 1KB chunks, wasting memory. Also, since the registers are 8-bit, they can only index 256 1KB chunks, so you're limited to 16384 tiles for the entire game. Technically this could be circumvented by wrapping the mapper with a second mapper (many pirate games do this), and then you could pick different sets of 16384 tiles, but that wouldn't be very typical.


Tilesets and scrolling could easily be done from one scanline to the next without any glitches, but palettes aren't so simple. If you can afford a few blank scanlines (2 or 3 should do it) between the status bar and the game window, you could pretend to be spreading the color updates across multiple HBlanks, which would make the color changes more plausible.


That's always tough when a status bar is present. There are software-only solutions to fix this though (which involve dynamically relocating the status bar in the name tables according to the vertical scroll) so it's certainly plausible. A bit annoying to code, but you don't have to worry about that, right?

So if I grab one tile from the rom, I have to grab the next 63 tiles along with it. Now I finally understand why Mario 3 always loaded that jellyfish. Can I start swapping in tiles at any point in the tile memory? Or should I think of that as being divided up into eight sections?

That should be plenty, but I'll start keeping track.

If I can switch 64 tiles between scanlines, then could I hypothetically switch all of the tiles between frames? Or would that impede on other important processes? Also, I think I read that I don't have to dedicate half of my tile memory to background tiles and the other to sprites, but that they are interchangeable; could I pick and choose which is which at my leisure?

Yes. The FME-7 mapper divides the pattern table into eight windows.


Yes.


You can swap any tile data you want into the four background tile windows or the four sprite tile windows.

It was common for games to group CHR-ROM animations in the same banks to avoid wasting space, so when you look at the pattern tables in a debugger you often see tiles that are never used in the level you're in.


When using CHR-ROM, switching tiles is practically instantaneous. You just need to make a mapper write for each switch and the mapper will take care of making the CHR chunk you selected visible in the window you requested. It's pretty quick. CHR-RAM on the other hand requires the program itself to send each byte of CHR data to VRAM, so the amount of tiles you can change from frame to frame is very modest. You should probably stick to faking CHR-ROM and switching as many tiles as you want.


When sprites are set to the size of 8x16 pixels they can use any of the 512 tiles, but the top tile is always even and the bottom one is always the odd one following that. The background can't possibly address more than 256 tiles (unless the "rare" MMC5 mapper is used, then you can address 16384 tiles in the same frame), but you can change which half of the pattern tables is used for what at any time during the frame (you can even use the same 256 tiles for both sprites and background, while the other 256 are left unused), or you can bankswitch new background tiles halfway across the screen to simulate having more than 256 background tiles.

Are those windows dedicated to their purpose, though? Could I take tiles in my background windows and use them to draw a sprite?

Another question that's come up: Does the NES have drawing functions other than placing its tiles? Could it, for example, draw a filled rectangle of arbitrary dimensions somewhere on the screen?

The NES cannot do arbitrary graphics, but there are many attempts to do things like this by various means. You can use some combination of tiles and sprites to produce shapes that you couldn't do with tiles alone.

If you wanted an arbitrary rectangle with tiles alone, you need somewhere between 0-9 extra tiles for the edges of the rectangle and 1 tile for the interior.

There are two sets of 256 tiles. Sprites or the background can each chose which of those two pages to draw from individually. So yes, you can use background tiles for your sprites, if you want. This is a global setting so the sprites will only come from one tile set or the other for an entire screen (or you could split them per-scanline if you get fussy with it). There is also a mode that uses 8x16 sprites instead of 8x8 sprites, and this mode turns the two sets of tiles into a single set of 256 8x16 tiles that can be used by sprites only. (The background is always 8x8 tiles.)

Yes. There are 4 windows on the sprite side and for windows on the background side.


Like I said in my last message, if you use 8x16 sprites you can have access to all 512 tiles. The opposite is not possible, the background can't access more than 256 tiles, unless you use the MMC5 (a somewhat uncommon mapper that has a special graphics mode that gives you access to 16384 tiles) or bankswitch halfway down the screen to load new tiles into the background windows.


NES graphics are exclusively composed of tiles, but if you use CHR-RAM you can simulate a traditional pixel array. With a few bankswitches you can have the screen display 960 unique tiles from CHR-RAM, and since it's RAM these tiles can be modified at will. I's a slow process though, and it would take several frames to update a whole screen, and palette attributes would still be limited to 16x16-pixel areas, so you wouldn't be able to color all pixels freely.

I can name a couple of NES games that do this, in case you want to see how it works: Videomation and Color A Dinosaur. Notice how they don't even bother trying to give you more than 4 colors to work with? A regular person just wanting to draw/color something would never understand the 16x16-pixel attribute area thing. Pictionary is different, it has a set of primitive lines and shapes that can be combined to create limited drawings.

Sorry, tokumaru. I missed that earlier post somehow.
Right now I only have thirteen animated tiles, and I think I've been assuming I'd simulate CHR-RAM for that, but I may need to reconsider.

I've included an image of my status bar. The icons for the NES buttons have been replaced with icons for keyboard controls (my game's control scheme uses the same number of buttons as the NES controller.) More relevantly, I've adjusted it a bit so that the topmost line is entirely black (or should it be a different color?) If this isn't enough to change four background palette colors, scrolling and a set of background tiles, I could conceivably add another blanked scanline on top, eating one scanline from the play area. Blanking scanlines like this doesn't change the position of the tiles below, does it?

Under my status bar is a set of tiles to be swapped in. But you might notice that it doesn't contain the skill icons present on the status bar. There will probably be quite a few icons, so the status bar could actually require up to three sets of tiles to be swapped in. Would I have to do each one on a different scanline? One set could be changed before the status bar, and then the second after the blank scanline, but by the second scanline the tiles for the icons have started being drawn. If I'm not mistaken, there would need to be an update to the nametable, is that right? (Either that or sacrifice as many as three tiles from any set that I might be swapping out at the time.)

Swapping tile sets in tile windows can be done in the scanlines that you're already blanking for the palette change.

About use of Z and X: German and French keyboards move Z far from X, and a lot of people prefer to play using a USB joystick. You'll want to make keys configurable.

13 tiles is 208 bytes, quite a lot of CHR-RAM data to update in a single frame. If you do update that many tiles during VBlank, there won't be any time left for other VRAM updates. Also, you can't really mix CHR-ROM and CHR-RAM (although a couple of obscure mappers do this, there are limitations), you're gonna have to pick one kind or the other to simulate.


It should use the global background color, because that's what's displayed when rendering is off. If the global background color (i.e. "color 0") has to be changed as well, do it before or after the blanked scanlines, so that both are the same color.


I'd go with 2 blanked scanlines, in order to have 3 HBlank periods to perform palette and scroll updates. CHR-ROM swaps can be done even outside of HBlank, so there's plenty of time for that. CHR-RAM updates are out of the question though, as the time of 2 scanlines isn't enough to update even 2 tiles.


Not if you don't want to.


No, CHR-ROM swaps are incredibly fast... during the 2 blanked scanlines you could easily swap, say, 20 chunks of CHR-ROM without problems.


What? I don't see the need for a name table update halfway through rendering. All name table updates, for the playfield and the status bar, should take place during VBlank.

Ah, that's a good idea. I'll start looking into that.

I was thinking one of the colors changed would be the background, to black.

If I can change three sets of tiles before any of the tiles start drawing, then it's a nonissue.

So, if I have drawing turned off for two scanlines, then does that mean that any sprite wandering into those scanlines would lose two rows of pixels, like in the attached image?

I also have a question that may not directly relate to graphical capabilities. I've noticed that in some games, out of sight is out of mind. In Mega Man, for example, once an enemy falls offscreen, the game forgets that it exists (or, more importantly, that it doesn't.) Other games, like Super Mario Bros. 3, do the states of offscreen enemies, but I think Zelda only bothers to remember selective information about them. Does the handling of offscreen enemies have something to do with system limitations, or is it completely up to the whims of the developers?

Both. Mostly it has to do with how much CPU time and RAM the developers want to spend on offscreen enemies.

Well, you could disable sprites after the edge to make it moot.

Actually, we haven't figured out how to disable rendering midframe without corrupting the sprite data, but if we had, there wouldn't be a pause of N scanlines: instead, sprites would resume as though the lines had never been disabled.
The NES only provides 2048 bytes of RAM for the entire state of the game, for every purpose. While some games provide more memory, it cost more money, and so most games decided that keeping track of what things were in what state just wasn't worth it unless it was obviously problematic.

In that case, sprites would appear to go behind the status bar, right?

Oh, wow. So for each onscreen enemy, I'd imagine the game would need to track the enemy's ID, animation frame, X and Y position and possibly X and Y velocity, as well as any relevant stats. For games with simpler enemies that might include just a handful of flags tracking the state, but other games might need to track things like health, damage output, weaknesses and resistances, et cetera. And for offscreen enemies, a lot of this becomes irrelevant; I'd imagine some games could even get away with only a single flag indicating whether the enemy was alive (if even that.)

Does the game have to keep track of an enemy's static, or can it get by with just dynamic stats, and read the static ones from the ROM as necessary? If every Hammer Joe is weak to the Hard Knuckle, does that weakness have to be stored in RAM, or could the game grab a list of weaknesses from ROM based on the enemy's ID every time an attack hits it? If Goomba's walking speed is always the same, could its X velocity be replaced by a flag indicating which direction its pointed?

These 2048 bytes of RAM, of course, must also store game-wide information, like how many Triforce pieces you've collected, right? In an RPG, would the game have to track a flag for every single treasure chest in the entire game? Or, could it hypothetically get away with keeping track of the treasure chests in the current dungeon, and then reading treasure chest data from the save file whenever you change maps? (Not that I expect to discover an NES save file can be particularly large.) Does this RAM also store much audio channel information?

That, plus X and Y having multiple bytes of precision for moving a fraction of a pixel per frame.


Super Mario Bros. 3 uses such flags. Super Mario Bros. 2 and Kirby's Adventure and Mega Man series do not, instead choosing to respawn an enemy when the enemy's spawn point leaves and reenters the camera's field of view.


The latter.


Some games do that, but other games just load the velocity to simplify coding. There are often tradeoffs among time, ROM space, and RAM space.


The save file is mapped as an extra 8192 bytes* of RAM. Some of this is reserved for actual saved games; the rest is used for the current state of the game, especially before the player reaches a save point.


A music engine might have about 32 to 256 bytes of state, including information as to which instrument and which sound effect is playing on each channel, the current position in the instrument data, which phrase is selected on each channel, the current position in the phrase, how many frames until the next note, etc.

* About a dozen games had more than that, but 8192 bytes was by far the most common size.

Yup.


I like this approach. In only 32 bytes you can store the alive/dead state of 256 enemies... not many games have levels/rooms with that many enemies. In my designs, I also save a few more bytes (128 or so) for objects that need to remember more than whether they're alive/dead. Objects that need this have pointers indicating where in those 128 bytes their memory begins, and they can use as many bytes as they need as long as there are no overlaps and it all fits in 128 bytes.


Everything that doesn't change should be in ROM. Even things that do change sometimes stay in ROM if the possible states aren't too numerous. In this case you'd have a pointer/index in RAM indicating which is the current state.


Games that need to keep track of tiny details in ridiculously large worlds (as opposed one level at a time) most likely have extra RAM on the cart (in most cases, 8KB of RAM). Carts that are able to save games keep this same extra memory always powered on with a battery.


Actually, since the most common RAM expansion size is 8KB, save data is typically 4 times larger than the built-in memory in the NES! It doesn't have to be entirely used for saving though, games are free to use as much of it as regular RAM as they see fit.


Yeah, audio state has to be kept in RAM (the amount of RAM depends on how complex the music/sound engine is: how many channels it can handle, haw many effects each channel can have, etc.), but the actual data (notes, instruments, etc.) should remain in ROM.

Does every game with a save function have added RAM? Maybe I'm wrong but some games seem like they wouldn't need that much extra memory. Zelda 1, for example, seems fairly minimal, at least for its genre.

A few Japanese carts used EEPROMs (reprogrammable chips that retain data when not powered, but can't be used as RAM) for saving, but the vast majority used extra RAM powered by a battery.


It may not have needed if, but the fact is it does have this much extra RAM. 8KB may sound like overkill in some cases, but that was probably the size of RAM that could be obtained for cheap at the time (as larger memory becomes more popular, sometimes the smaller chips become more expensive). This game was originally released on the Famicom Disk System though, in the form of a floppy disk, so the saves probably occupied less than 8KB of the disk.

I believe that Zelda had just a counter for each room in the dungeon, so it used log2 n the number of bits (e.g. a room with 7 enemies only used 3 bits). If you defeated a weaker enemy and re-entered, the strongest enemy would be gone, so this was also an easter-egg.

Thanks again for all your help. I have an eclectic assortment of questions now.

How does the dialogue box in Final Fantasy 1 work?

Why does SMB3 have scrolling artifacts even in areas with no vertical scrolling

Dragon Warrior 1 has some dark dungeons that include a halo of light effect. This was done by making most of the background tiles black (which is why the halo is square-shaped and also gridlocked) right? Does that involve changing the nametable a lot?

Earlier on, Grapeshot mentioned that black outlines became a common element of the NES aesthetic to avoid dot crawl. Would dark colors other than black work for that?

Also, I checked out the various demos that you guys have linked me to, and those are some pretty awesome effects. Stuff like that probably didn't show up much in commercial NES games though, I'd assume... Do those kinds of fancy effects largely monopolize the NES' resources? Or could other things be going on at the same time in a game?

If you want to see what's going on in SMB3, open it in FCEUX, go to the debug menu and open the Nametable viewer. It will show you visually exactly what is happening with the scrolling better than I could describe it to you.

The short answer is, though, is that all horizontal levels are two screens tall, even if the camera doesn't go up. This limitation makes it easier to implement the status bar while still allowing the vertical camera motion, but of course it means no level is more than 2 screens tall (except the vertical-only areas like in 5-2).

Check out the first fortress. Even though you can't see the hidden door to the whistle onscreen, it's there in the nametable for the upper part of the level.

Actually most of the things you're asking about can be seen visually in FCEUX's Nametable and PPU viewers. You should really take a look. For instance, I just looked, and Final Fantasy 1 appears to create a copy of the current screen on the currently not-visible half of the nametable space where it overlays the dialog box. Then it gradually displays that copy screen with the dialog with a scanline scroll split.

Never played it, but from looking at a YouTube video I guess you mean how they smoothly scroll in and out? I'd have to debug the game to be sure, but I would just draw the text box to the hidden name table (along with the background that remains visible around it) and use timed scroll changes to switch from the name table with the text box to the name table without the text box during rendering, moving the switch point down every frame.


Because it uses the same engine regardless of the height of the level. Developers would hardly code a different scrolling engine just to get rid of the glitches in some levels.


Man, RPGs are really not my thing... time to check YouTube again! =) Well, it's such a small area that it could very well be updated completely every frame, or even use the traditional scrolling technique, which is drawing only the new row/column of tiles and moving the camera (in big 16-pixel increments), with the added step of erasing the row/column that was left behind. Either way it requires less name table updates than regular scrolling, because the area is so small.


We'd have to tear apart each effect individually, but a lot of amazing effects I've seen require big look-up tables (which eat away space otherwise used by actual game content), intensive CPU-PPU synchronization (keeping the CPU busy with things other than game logic for long periods) or are very controlled and hard to pull off dynamically (upon player input instead of being scripted), so yes, many effects are impractical in actual games. I'm sure some of them could be utilized in games, but I bet they'd be more like gimmicks than integrated gameplay elements.

I took a peek at the nametables. It took me a bit to figure out what was going on, and I'm still not entirely clear on it (like everything onscreen apparently appearing twice), but I think I get the gist of it now. The camera borders move around and only a row or column is updated. Final Fantasy and Dragon Warrior have movement that snaps to the grid so it only needs to update on one axis at a time. And, indeed, the text boxes are drawn onto the offscreen half of the nametable. Looks like there's a delay of several frames as it puts it all down before it even starts to appear onscreen.

The hidden door is certainly visible in the first fortress of Super Mario Bros. 3. So, even if all the action is happening offscreen, does the terrain still have to be in the nametable for the player to interact with it? I also noticed that, in the nametable, SMB3's status bar was kind of a mess...

Dragon Warrior's dark dungeon was different, though. As tokumaru suggested, the borders don't move around, and the visible area is small enough to update the entire thing every frame. I think there's a spell that creates a wider halo of light, but maybe it's still small enough to be handled the same way. How much of the nametable can be updated in a frame?

How would a similar Halo of Light effect handle in a game with a bit more freedom of movement? Even if the player doesn't snap to the grid, the aura would have to, since it's actually part of the background, right? Could it move around by eight pixels at a time? Would it make a difference if the halo followed the player, but the camera only moved on one axis, or not at all? I'd guess that at least some of the sprites would have to go behind the scrolling layer, which would mean the walkable floor would have to be completely transparent.

That's a side effect of mirroring. The NES can address 4 screens (name/attribute tables), but it only has memory for 2. This means that the other 2 have to be clones/mirrors. Carts get to pick whether this mirroring is vertical or horizontal. The extra name table we talked about before is so that no mirroring takes place, and the NES actually sees 4 different screens.


Well programmed games will separate the graphics (view) from the logic (model) entirely, so this shouldn't be the case.


Since games are allowed to change the scroll, palettes and tilesets during rendering, the debugger window is drawn based on the state of a specific scanline. Look for it and you'll see a field where you can type scanline numbers. If you put an scanline where the status bar is rendered, you'll see it with the correct tiles but the playfield will be a mess, because that point comes after a CHR bankswitch.


You can update around 200 bytes of VRAM (although that number starts to drop as you also have to manage addresses and stuff) and perform a sprite DMA under normal VBlank time. Using a few tricks to speed up the code, it's possible to update a row and a column of metatiles (128 tiles + their attributes).


We had a whole thread about this recently.

Thanks for that link, it cleared things up. I hadn't realized so many games did that kind of thing, and I also hadn't considered smoothing the effect by sacrificing some sprites.

The link also prompted me to do a quick search of these forums for Bucky O'Hare. That game seems to have a lot of "how'd they do that?" moments. But now that I think about it, I'd guess several of them used similar techniques to the halo of light effect: small updates to the nametable, with leading sprites to smooth the transitions. That's probably how they did the bit with the giant snakes? And maybe that part where those walls close in on each other was done the same way? It almost seems like a shame that the average consumer would probably never realize what a monumental achievement some of these games represent.

I went back and looked over that article on Mirroring again, and this time I actually understood some of it. With fceux's debug tools, it really helps when I can see what's happening in action, too. So I can see now that Mario 3's artifacts are whatever's going off the other side of the screen, but I'm not sure where the color palettes in these artifacts are coming from; that still seems a little arbitrary. I also peeked at some older games, like Zelda and Metroid, to watch them switch mirroring every time you walk through a door. I'm still a little confused about what's going on in FF1, though... If a game has a memory expansion for the save file, can this extra memory be used to avoid scrolling artifacts?

True.


Yup. Along with CHR-ROM animations to make it look like their body is constantly moving.


Yeah, one of the sides is drawn with horizontally repeating patterns, so that you can move them by updating only the edge(s), and sprites are used to make the edge move smoothly. There's also some CHR-ROM switching going on to cancel out the background movement (The background pattern repeats every 8 pixels, but the moving parts move in 4-pixel increments).


True again. I watched a review of it on YouTube where the guy said the graphics were "adequate", but nothing to write home about. That hurt me a little bit! =)


The fact that color attributes are applied to 16x16-pixel regions combined with SMB3 only having an 8-pixel wide hidden area where to do updates results in an 8-pixel wide area with the wrong attributes applied. The actual colors you'll see will depend on which colors are actually used in the tiles. I mean, tiles aren't forced to use all colors of a palette, so a tile going off the screen at the left might look green because it uses a palette that contains green and orange, while the object scrolling in from the right might use the index that's mapped to orange in that palette, in which case a green object scrolling out might result in an orange object scrolling in.

Anyway, some games try to put part of the glitch on each side of the screen to make it less prominent, others try to put it on the trailing edge of the screen (which players are less likely to be looking at), and games like Alfred Chicken and Felix the Cat go out of their way to completely hide the offending area with a column of black sprites.


No. The NES has 2 separate addressing spaces, one for the CPU and one for the PPU. The save memory is attached to the CPU addressing space, while extra name table RAM must be attached to the PPU addressing space, so you can't use the same chip for both purposes.

The extra memory isn't the only way to get rid of scrolling artifacts. A handful of games do have glitch-free 8-way scrolling with just the stock 2KB of VRAM, because the programmers went out of their way to fix it. Like I said above, Alfred Chicken and Felix the Cat use sprites to mask the glitches. Jurassic Park uses IRQs to bankswitch black tiles at the top and bottom of the screen. Big Nose Freaks Out disables rendering early (although it has a small glitch at the bottom left corner of the screen, which is necessary for it to know WHEN to turn rendering off).

You don't see scrolling glitches in Final Fantasy because it uses vertical mirroring. With vertical mirroring, your virtual screen is double-wide so there's no reason to have any horizontal glitches on the left or right side. There are glitches at the top or bottom, but this part of the screen is hidden on an NTSC TV. If you put FCEUX into PAL mode while playing Final Fantasy you will clearly see the glitches at the top and bottom.

Even though vertical mirroring might sound like the way to go, based on this, there are lots of valid reasons not to use it, which might not be intuitive. Think about having to do a scanline split for a status bar, for example.

Crystalis uses vertical mirroring and uses a scanline IRQ to change the scroll just before the PPU is about to hit the status bar, so that rendering skips the status bar. Jurassic Park and M.C. Kids use vertical mirroring and swap a blank pattern table into the background for the top and bottom few rows.

Crystalis does not, it uses horizontal mirroring (and has plenty of glitches at the sides).

What Crystalis does, I believe, is put the playfield on screen 1 and the status bar and dialogs on screen 2. When walking around the screen, it uses an IRQ to split the middle of the screen (variable position) to wrap for the scrolling, and then a second IRQ to switch to the status bar at the bottom of the screen.

I honestly think that vertical mirroring is the best choice for 8-way scrolling. There are several games that handled the status bar issue and can teach us a thing or two. Horizontal mirroring will only help you so far, because when your levels are more than 2 name tables high you have to jump through some hoops for the status bar anyway. vertical mirroring just looks cleaner to me, and the glitches are easier to hide.


True. It uses an IRQ to skip the second name table and force the vertical wrap of the first name table. This is basically a way of simulating 1-screen mirroring. This is not so different from what tepples described (he did get the mirroring wrong), the game is skipping an entire name table after all.

Wow, I just read the whole thread and it's funny.^^

@The author of the thread : If you're worried this much about making your games truthful to the limitations of the NES you'll probably want to do a NES port after it's finished. It should be done in not time if you stick to the limitations.

As for the 2kb of RAM, it's not nearly as limiting as it sound. First "2kb" sounds a lot more than "2048 bytes", doesn't it ? At least I think it does ^^
You just have to think and code very carefully to be as RAM-efficient as possible.

I wrote a action-RPG engine for a project similar to the one you're showing and I still have about 512 free bytes of RAM, plus I don't use most of the stack. In fact that's not a problem because you only have to store the state of the game in RAM, everything else is in ROM. Unless you're doing some self-modifying code or on-the fly decompression (I actually do this in my engine, but it's not polished yet ^^)

Personally I can't refrain to think most games that uses 8kb SRAM without saving could have been done without it if they were coded more carefully / a bit differently.$

As long as you're asking "What are the limitations of the NES", you'll always end up discussing the limitations for various mappers/carts hardware. The limitations of the console itself are very sparse :
1) The resolution is 256x240
2) You can show arbitrary patterns of pixels of the 13 background colours, but each group of 8 has to share the same palette of 3 colours (but fine "scrolling" can be changed every line or even within the line)
3) You can display only 64 sprites of 8x8 or 8x16 of arbitrary patterns, (you can change in the middle of the screen), each sprites has only one palette of 3 colours and they can't be changed during rendering (unlike machines such as the C64 for instance)
4) You can have arbitrary sound (on a famicom by using the expansion port, and on a NES using a coprocessor and the $4011 register)

If you don't bother modifying the console slightly, limitation 2) don't even apply anymore as you could put the PPU in slave mode to show arbitrary 13 colour graphics without the 8-pixel tiles thing at all.

So in theory you could make an ASIC that does texture 3D rendering with lots of VRAM on a cart, and have part of it which "downgrades" the rendered image to suit the limitations of the NES before "tricking" it into rendering the image, along with virtually boundless sound, and it'd still be a valid NES cartridge.

Yeah, like not being allowed to scroll backwards (SMB1) or by having destruction of terrain be reversed when the terrain scrolls back on (Vice Project Doom). When your game allows the player to destroy terrain, it must somehow remember what has been destroyed. How this destruction is stored in RAM along with the rest of the game state may impose restrictions on level geometry if the game is not using extra RAM. For example, in one system, each column of the map has one bit for destruction, but then only one thing in each column of the map can be destroyed.

I agree with you on this one.


I'm pretty sure Bregalad meant that games could have been programmed differently and still play the same, without such sacrifices.


This again? OK, it may impose restrictions in a few cases, but I agree with Bregalad that in a lot of cases it wouldn't. Think about it: the benefit of using 8192 bytes of extra RAM is that you can place levels there and and modify them as you want. Uncompressed levels typically use 1 byte per metatile (which is often the smallest unit that can be destroyed), so you could have up to 34.133 uncompressed game screens (possibly more if screens are smaller than 256x240). If instead of using extra RAM you used 1 bit of regular RAM to represent the state of each one of those 8192 metatiles, you'd need only 1024 bytes. That's half the stock memory of the NES, and maybe it would be possible to have the rest of the game use the remaining 1KB (The ColecoVision for example had to survive with that amount).

But that's for 34 screens! Most games don't have levels this large, and even if they did I doubt that all of them would be heavily modifiable. I can't think of a single game that works like that. You could have a much smaller number of bitmaps and link them to the screens/areas that actually need them. With 512 bytes you could still describe the existence of metatiles in 17 screens(!), leaving 1.5KB free for the rest of the game state. Wouldn't you say that covers most of the NES games you can think of that have destructible terrain?

It's just harder to code, because it's not as straightforward as modifying bytes in a 2D array. Instead you have to do some address conversions, handle some indirection, perform bitwise operations and patch data for collision and drawing purposes, but it's definitely doable by any competent programmer.

What this solution wouldn't cover are games that need arbitrary metatile replacing, like completely restructuring of the levels (if there are few possible states you can definitely store them in ROM though) but that's hardly a common thing in games, at least in such a global way that would cause you to go out of RAM.

A lot of these fancier games must devote a considerable portion of their space just to animating backgrounds. In games that use CHR switching to simulate paralax scrolling, how many frames is usually needed for a good effect? It seems that CHR-ROM switching isn't as popular for sprite animations...

There they are, I see them now. They seem to be the correct colors, at least on the one map that I checked.

Here's a thought, though. Games like Zelda and Metroid might switch mirroring every time you go into a new area. In a game like Final Fantasy or Dragon Warrior, where the screen scrolls in four directions but only on one axis at a time, why not switch mirroring every time the player changes directions? In a turn-based RPG, latency isn't really a big concern. In fact, the controls in Dragon Warrior already handle as if the game has just woken up after a big surgery.

The more I learn in this thread, the more serious consideration I put towards that possibility. Of course, I'd have to learn how to develop for the NES first....

That's a good point, and I was already considering that some earlier in the thread. But if my game has a save function, shouldn't I assume a RAM expansion is already present?

Well that... that is something. I know I tend to favor software-only solutions, but it is still fascinating that an NES cartridge can have hardware upgrades built right into it. That's something you can't do with contemporary games.

Well, they often have the animated stuff share the same CHR chunks, so it ends up not being that much, at the expense of having less than 256 tiles for drawing backgrounds.


Parallax? You need one frame for each pixel position. If the repeating pattern is 16 pixels wide, you need 16 frame. 32 pixels wide, 32 frames. Since parallax backgrounds move slower than the foreground, you really must be able to move them pixel by pixel, otherwise it'll look jumpy.


Later games with larger characters many times had a few CHR chunks dedicated to the main player, and would switch depending on what the character was doing. This was also popular in games where the main character has different "states" (small Mario vs. big Mario in SMB3, walking Kirby vs. flying Kirby vs. Kirby using different attacks, characters who change clothes, and so on).


Dragon Warrior's mapper doesn't even have mirroring control, but the reason reason games that do have it won't do it is because the screen would get messed up if the scroll wasn't perfectly aligned to one of the name tables. See, if the name tables are arranged horizontally, and the character is walking right crossing the border between the 2 name tables and you suddenly put the screens on top of each other, the screen will look pretty broken. You can't take two pieces whose drawings are meant to fit side by side and put them vertically. The scroll would have to be perfectly aligned to one of the pictures for this change not to be visible.

You can try it yourself in FCEUX, where you have radio buttons to change the mirroring. Make sure the scroll isn't aligned to a name table and change the mirroring type. That's what would happen.


If if you took delayed the movement in order to have time to update a lot of tiles, the areas the need to change are not offscreen, so you really can't do it without the player seeing what you're doing.


Yeah, unless you decide to try some of the experimental FlashROM saves people have been considering for new homebrew games. Theoretically, it would be possible to save to the same FlashROM chip that contains the game program, so the cost for this is much lower than the alternative. Besides price, it has the advantage of being safer than battery saves (which are easily corruptible) and lasting longer (as much or even longer than the game itself) without any kind of maintenance.

In fact as far I remember, your character starts to walk only if the frame counter contains a multiple of 16 (four low bits are '0'). I don't remember why they added such a mechanism, but there probably was a (lame) reason. If you're lucky and are already on a multiple of 16, your character walks right away, but if you're not then you have to wait 15 frames before it starts to move. Yes this is lame and annoying.

You probably meant "Dragon Quest" here. It doesn't have mirroring control, nor does it have extra RAM nor saves. It all works with the internal 2kb of RAM and passwords. Also a major part of the 2kb of RAM is used to store program code which is read from CHR-ROM, and decoded into RAM, in order to have the game fit 32kb of PRG ROM. This is pretty impressive.

Talking about this, if 2kb of RAM REALLY isn't enough, you can of course use VRAM (either nametable or pattern tables, if CHR-RAM is present on the board), to store game state. The major inconvenient is that you can only read/write data to/from VRAM during VBlank, so this is a major issue. I've never seen any game nor demo doing this.

Someone brand new hasn't seen the previous topics on this.


The ColecoVision could also borrow VRAM to store game state more easily than the NES because the TMS9918 VDP had a second address register for access by the CPU during draw (no sharing loopy_v/t) and was able to stall the CPU until a time slot became available.

Oh you're right. But Dragon Warrior is the US version of Dragon Quest though, right? So if the original didn't have mirroring control they'd hardly make use of it in the translated version even if they upgraded the mapper.


At this point things start to get pretty hacky. I understand why they'd do this back then, but now that we don't have to bother about ROM sizes much I'd much rather use more PRG-ROM than deal with a complicated scheme like this.


That's a very good idea. If you think about it, the NES has 4KB of internal RAM when you account for the built-in VRAM. If you use CHR-RAM, that's a total of 12KB or RAM, which is not so bad. Using name table RAM can be hard depending on the type of scrolling you use, but giving up on some tiles is not a big deal at all.


You'd definitely want to use it for data that doesn't need constant access, like data from areas not being played at the moment.

But you're still claiming that sacrifices are necessary, which I disagree. =) I tried to post a better response this time, suggesting alternative ways to implement block breaking madness in just 2KB of RAM.

It's not using it for RAM, but Big Bird's Hide and Speak stored a bunch of sound samples in CHR-ROM for extra room. It reads them into RAM during vblank to play back during the frame, it's rather insane!

It also depends on how much terrain is modified. In my game, the player typically can't destroy or modify any of the level terrain. There may be a case where there's a couple blocks the player can destroy somewhere in a level. My solution to this would likely be to create an enemy object that does nothing but sit there, looking like a block, waiting to be destroyed. Then the small amount of RAM set aside to keep track of destroyed enemies would handle the absence/presence of this block later on. I also have what I call "event code" for each level. It's basically a block of code unique to each level that does things not handled by the engine. I could have the code check for collision between a player weapon and those specific tiles (which would count as destroying the tiles), and keep track of it with just a few bytes in RAM. Then later, when the player goes back to that area, it can replace the tiles with blank ones depending on the status of those bytes. This is far less elegant, but still an option.

I'd recommend following Celius (blocks as enemies) if you have only a few things that can be broken like item boxes, or following tokumaru (destruction bitmap, at the cost of not being able to cache a sliding window around the player) if you have huge fields of breakable or collectible things like coins or the bricks of WORLD 1-2 in Super Mario Bros.

Or just trade programmer time-is-money for replication cost, as the M.C. Kids programmers ended up doing.

Yeah, if we're talking few blocks they should definitely be handled like enemies/objects. In fact, even big amounts of breakable blocks could be handled similarly: create a generic "grid of breakable blocks" object, with configurable dimensions and pointers to the RAM locations where their bitmaps are.

Ideally you'd set aside some RAM for the decompressed part of the level that follows the player, so that you can "patch" the level map using the bitmaps as you decode it, which shouldn't take much CPU time. As soon as blocks are destroyed, you update the decompressed map and the bitmaps, so that they are rendered correctly the next time they scroll into view.

So, every time a game changes mirroring so that it can scroll on a different axis, it should first align the camera to the nametable, right? If movement is grid-based, like in Final Fantasy, though, I would think every step would end aligned to the nametable.

You guys have also talked a lot about storing data in unorthadox places, in particular when dealing with destructible level terrain. It sounds like the best way to handle it really varies with the nature of the game, but I hadn't really thought about it much. When I think of destructible terrain, I think something along the lines of Rampage, but large portions of Mario 3 would classify as well. And I suppose the same things would apply to dynamic terrain, like a lot of puzzle games have.

I understand that background tiles are 8x8 but that their attributes (such as color palette) are held in 16x16 chunks. Is there anything I should know about interacting with tile attributes?

Another question that came to mind: Are there any significant legal issues that come up when dealing with NES homebrew?

No, every step would be aligned to a tile, not a nametable.

You have a grid of four nametables (two are the same). Within them is a grid of 32x30 tiles.

If you're nametable aligned (scroll at 0, 0), and move a tile to the right (8, 0), you're still tile aligned but not nametable aligned. (One column of tiles from one nametable, the other 31 columns from the other nametable.)

If you're nametable aligned, you're tile aligned, but not necessarily vice versa. (Much like a square is a rectangle, but a rectangle is not always a square. )

Edit:
Except for color "glitches" appearing on the left and right (or top and bottom) sides of the screen depending on the mirroring you use, there's not much special about it.

If the scroll is anything but (0, 0), the screen is not perfectly aligned to a name table, meaning that there are parts of at least 2 name tables sharing the screen, meaning players will notice if the mirroring type is changed from one frame to the next.


That goes for most aspects of NES games. You'll always want to arrange your data in a way that's accessible at the rate you need, while occupying as little space as possible. This is why there are no standard solutions for NES game engines... Each game has its own requirements that must be taken into account in the design phase.


Yeah, I guess they are similar concepts, but Rampage and puzzle games have very confined levels, so it doesn't take a lot of RAM to completely represent them. SMB3 on the other hand has pretty large levels, and the programmers went with extra RAM on the cart so that they could place (and modify) the levels there. Our talk was mostly about how they probably could have achieved the exact same effect without the extra RAM.


The color palette is actually the only attribute specified in the attribute tables... =) Many other systems have tile priority and flipping in their attribute table equivalents, but on the NES it's just palette indices. I don't think there's anything else you need to know about this in order to recreate the look of NES games.


I don't think so. AFAIK, reverse engineering is not illegal, and all the development information we have was obtained that way, not from official Nintendo documents. Also, all patents related to the console expired in 2005. I think that as long as you don't use any copyrighted materials (music, graphics, characters, etc.), you're safe.

What an interesting technique for getting a four-cycle auto-incrementing memory read. That could be a valuable in a specialized NES routine or demo that needed to quickly read lots of data faster than 6 cycles/byte (X/Y increment). It can be put into the nametable/CHR RAM. I'll have to make some use of this sometime.

Okay, I get it now. Well, sort of. To tell you the truth, the nametable is still a little confusing, but I understand what you're telling me. And, looking back at my own examples, Zelda only scrolls one screen at a time. And in Metroid, the entire map is composed of screen-sized units, and mirroring only changes when one of said units is on the screen in its entirity (though not necessarily the same quadrant of the nametable?) The camera even nudges a bit first if it's out of alignment.

So let me make sure I have this straight. The nametable can be modified offscreen along one axis. If the camera is scrolling along the other axis, those tiles can't be updated until they are already onscreen. When mirroring is changed, half of the nametable (top or bottom, left or right) is copied to the other half, regardless of where the camera is pointed at the time. Is that about right?

I was also taking a look at the way Mega Man 5 handles animated tiles the other day. In particular, in Gravity Man's stage. They don't seem to be grouped together like Mario 3 does (maybe I'm wrong, but perhaps they could have been more efficient with this?) and they also aren't consistant with the way the animations function. Thus, a game could have different kinds of animated objects, different triggers, maybe a different number of frames, so long as they're careful about which objects are onscreen at the same time, right? Strangely enough, Mega Man 5 was NOT very careful about this, and one of the blinking arrows in Gravity Man's stage has its animation tied to the horizontal movement of the camera.

Nothing is "copied" when mirroring is changed. The existing data in the nametables is rearranged. For example, if I put a big A in one nametable and a big B in the other, I'll get this pattern (which in theory repeats indefinitely) in vertical mirroring:

But if I tell the mapper to switch to horizontal mirroring, the pattern instantly changes:

Rad Racer relies on making this instant change halfway down the screen at the boundary between sky (whose scrolling wraps horizontally, for which it uses horizontal mirroring) and road (whose scrolling doesn't wrap horizontally, for which it uses vertical mirroring). But for a normal scrolling game, seamless mirroring changes work only when the scrolling is screen-aligned. For example, if the screen is centered over the first letter on the first row or the second letter on the second row, changing the mirroring won't change the display.

Adding one gate to the cart PCB produces a mirroring mode that allows screen-aligned direction changes without any mapper writes, as the game can just tell the PPU to switch from one B to another.


An OR gate provides L-shaped mirroring. At least one Famicom game is known to use L-shaped mirroring.


An XOR gate provides diagonal mirroring.

A lot of this might be easier if you provide screenshots.

I think you got the terminology wrong. Each name table (which you appear to be calling "quadrant") is 256x240 pixels, and there are 4 of them (although there's only enough memory for 2, hence why mirroring exists). The resulting 512x480 area is simply called "the background".


Yes, it's just harder to manage and will probably need more tiles in the end, but it's definitely possible.


I will have to check the game later.

The way Mega Man 5 does it is efficient, at least to some extent. None other stages has animated tiles in this fashion (they are animated with palettes), and Gravity Man in the only stage with this effect. The game uses 2kb (128 tiles) switching banks for BG, and 1kb for sprites. It relies heavily on the 1kb on the sprites, as this allowed them to cheat and reduce the pattern table space Mega Man takes as opposed to other games in the series, so this allows more varied enemies on the screen at one single time.

Since they had this system no matter what, doing the CHR-ROM animation in gravity man's stage would eat them several 2kb banks. Since those banks are "eaten" anyway, it doesn't cost anything to add non-animated tiles in them as well.

Also Mega Man 5 uses 256kb of CHR-ROM which is very large, very few games uses this much (and many who does stores PRG data in it).



I'm curious, what do you have in mind when mentioning this ?
To be honest, vertical, horizontal and single screen are the most useful. You can do almost anything with them.
Also, even on mappers with switchable mirroring, many game only uses one all the time. Or they use one for the title screen and another for gameplay, or something in the like.
Very few games actually switch mirroring while scrolling. In fact I think Zelda and Metroid are probably the only ones I can think of.

Okay... I think I might have it now. If only two of the nametables are kept in memory for a typical game though, and the other two are mirrored, it might be easier for me to conceptualize it if I just forget the other two nametables exist, and think of the two in use as wrapping around on the other axis. While it might not be technically accurate, wouldn't it amount to the same thing in practice?

(In either case, I need to make a decision in the way I lay out my maps: I either need to limit myself in the way I place barriers at certain borders so that the player can only cross them when the camera is aligned to one "screen" of the map, or I can have free eight-direction scrolling with more freedom in my map design and a more open feel to the game. In the latter case I'd like to try to simulate the scrolling artifacts this would entail. That could be fun.)

Note that the blinking arrows, if I'm not mistaken use both flipbook animation and palette animation at the same time. The arrows in question are at the end of a segment with a flipbook parallax effect in the background.

I have another question: Is there any kind of universal rule to how much of a sprite has to be onscreen before it becomes active?

An aside: I've been working on graphics for the game, and I've noticed that my 8-bit pixel art isn't quite up to snuff, in particular when dealing with backgrounds (I'm used to working in vectors.) I think I've managed to capture the aesthetic of some early era titles, but when compared to later games, it doesn't hold up. Maybe I should take a cue from later Mega Man titles and work with more monochrome objects. I'm open to tips and suggestions.

That's a useful model for mirroring behavior.


A sprite can be partially off the right side or bottom of the screen, but the top left corner of the sprite has to be on the screen in order for any of the sprite to be visible. This means the sprite can't be partially off the left side or the top of the screen, though there is a window register to replace the left 8 pixels of the whole screen with color 0. For example, the wider left border seen in Super Mario Bros. 3 is this window in action. And again, NTSC TVs tend to hide the top few lines of the screen.


Some objects in Super Mario Bros. 3 and Kirby's Adventure are fairly monochrome as well. The palettes typically have a dark outline color, a middle-brightness clothes color, and a light skin color that may double as a highlight color.

Sprites are simply displayed at the location specified. The location specifies the top left corner of the 8x8 tile and has ranges: X [0,255] and Y [1,256]. If part of the sprite happens to be offscreen, it is simply offscreen (there is no wrapping).

Since there's no [-7,-1] range for X, this means if you want to scroll a sprite on from the left it will just pop on fully formed at position 0. You can, however, toggle a rendering flag to hide the 8 leftmost sprite pixels if you want to show partial sprites on the left side. This is best used with the related flag that hides the 8 leftmost background pixels as well.

Others have answered about the individual 8x8 or 8x16 hardware sprites, but could you have meant game objects instead? If so, this is completely up to the programmer. I like to keep objects active even if they are a few pixels off screen (64 or so). If they stop moving as soon as they leave the screen it looks weird if the player walks towards them and notices they haven't moved at all.

So a sprite is visible if its top left corner is onscreen. This applies whether the sprites are 8x8 or 8x16, right? If an object composed of multiple sprites is just a bit off the top or left of the screen, then would only part of it be visible, with a possible gap between the visible portion and the edge of the screen?

I kind of feel that sidescrollers have an advantage over top-down games in terms of artistic freedom. The walkable and unwalkable tiles are essentially reversed between the two, so unless an area is small and enclosed, the bulk of the graphics in a top-down game have to depict objects that a person could plausibly stand on. Sidescrollers though often have wide expanses of background where the artist can draw big pictures of whatever they like.

Pop-on is a definitely a problem. There are a few workarounds I've seen:
1- NTSC TVs already crop off the top 8-13 scanlines, so for an NTSC exclusive game you may simply be able to not care
2- You can also explicitly wait to enable drawing sprites (or everything) such that rather than having sprites suddenly appear, they can scroll on from the top.
3- You can use the 8 sprites per scanline limitation to disable any sprites from appearing for some set of 8 or 16 scanlines, presumably near the top.
And, for "pop-on" on the left, the NES provides a toggle to blank the leftmost 8 columns of pixels.
edit: grammar nit

I'd say "not caring" is also an option for games that target PAL NES, at least that's what many of the commercial games at the time did.

Early games had very flat graphics, there were hardly any textures or shading. Newer games avoided big flat areas, and abused shadows and highlights, even if that meant using colors in unconventional ways. For example, look at how Blaster Master used the same gray to highlight both the grass and the dirt (looks better on a TV, because of how colors blend). You can often shade/highlight with different hues, which allows you to reuse colors more often than you'd think at first.


That works great if you combine sprites using different palettes in the same object, otherwise it may look too dull.

Older characters/objects were almost as flat as the backgrounds. Newer ones are usually outlined and/or have more volume (i.e. shadows + highlights). A common trick is to use different palettes in the same object, which makes them look more colorful than is typically expected from the NES. Ideally you'll find ways to do this without overlaps (for example, the bottom and top halves use different palettes, like in Contra) but some degree of overlapping is acceptable as long as you pay attention to the sprite limit (for example, Mega Man's face is an overlap, but it's just one sprite). The advantage of designing the characters yourself is that you can more easily distribute the colors in ways that are more friendly towards the limitations of the NES (i.e. make a character wearing a blue jumpsuit and an orange helmet, so you can easily use different palettes for the body and the head).

I think the later NES Mega Man games have some pretty stunning background art, which is mostly composed of monochrome objects and given shape with shading and highlights. It also allows them to maintain strong contrast between the terrain and the background, which I think is pretty important, especially in a precision platformer. Of course, stacking sprites would give more colors, and more colors naturally means more options for graphics. Final Fantasy 1 does that bit with characters and townsfolk, where the top half uses a different palette than the bottom half. If a game uses 8x16 sprites, though, this would have the same sprite weight as stacking, at least for 16x16 objects.

And I am leaning towards considering my sprites to be 8x16, the main selling point being more stuff within the 64 sprite limit. Now that I think about it, though, I don't recall seeing many NES games that push the sprite limit through the sheer number of objects onscreen. That is, I don't think I've seen many games that have 32 16x16 guys running around, or that have 40 or 50 bullets flying around at a time.

I always draw my graphics in monochrome, and decide which palette to apply to them at a later point. Well maybe not always but almost always. You get my point.
Luminosity is more important than hue and saturation. When encoding an image in JPEG, they throw more bits at luminosity than colour information.

If you see a green man you'll still recognize it's a man, but if you see a light skin coloured glue of pixels it won't look like a person even with the right colour.

As for games showing 32 16x16 guys there is Fire Emblem (though they're not sprites), and for a lot of bullets you should look into Gradius/Life Force games.

The limit get reached pretty quickly if you want to draw big things with sprites (as the # of sprites is proportional to the square of the object's dimensions). Look at the huge pink robot from Mega Man 5 for example, or the trax driving mettaur in Mega Man 3. They are almost eating all sprites on their own.

Final Fantasy games are a not a good example of how palettes were handled if you ask me. Most of the time you'll have a fighter in your front row, wasting 1 palette as they are both the same. Most of the towns and dungeon uses the same palettes for 2&3 as well. Result : It's as if only 2 sprite palettes were available.
They could at least have provided a way to have NPCs "choose" beteen palette 2, palette 3, or a mix of both instead of hardwiring them to having palette 2 for top and palette 3 for bottom.

Get a spread gun in Contra. Or play Recca. Or just look at the pretty smoke trails in Thwaite.

Not necessarily. You could leave blank tiles above the heads and below the feet to avoid stacking. Of course you'd be wasting sprite space with blank tiles, but something's gotta give.


Really? There's not much you can do in an 8x16-pixel area, artistically speaking. IMO, that would only work if your view is pretty zoomed out and there really are a bunch of sprites active at all times.

I don't know how I missed this, but this is just SO TRUE. It really helps a lot to be at the same time designer and programmer.
Also the nice thing with NES is that even if you're a shitty artist (I am) you still have chances to make decent use of the hardware's possibilities, something that wouldn't be possible even for SNES for example.

Back on topic, there's no point in using 8x16 sprites if you're only making use of 8x8 inside them. With 16x16 characters, it's a reasonable choice to go with both 8x8 and 8x16 sprites. With like 16x24 characters you have to use 8x8 if you don't want to waste tiles, and if you use 16x32 or bigger you can also do with both but 8x16 would probably be more sensible, as it uses less sprites for huge objects.

Personally, I don't mind wasting tiles on sprites. I mean, even if you use all 64 sprites in one frame you will only be using 128 tiles out of the 256 that are available for sprites. If you use CHR-RAM and have a dynamic pattern system that's constantly changing the tiles, the blank tiles will hardly be a problem (and they even compress to nearly nothing, which means almost no PRG-ROM wasted either). With CHR-ROM they'll certainly waste more memory, and you'll need fine bankswitching minimize the impact too, but in some cases I think they're still worth it.

Of course, one problem with a dynamic pattern system on the NES is that unlike the Genesis, Super NES, and Game Boy Color, the NES has only a fixed-function DMA unit that copies a display list to OAM and cannot be used, say, to copy tiles or nametable rows to VRAM. This lack of "blast processing", as Sega referred to the more versatile DMA unit in the Genesis, limits the frame rate. A program running on a Famicom or NTSC NES can update about 160 bytes of CHR RAM (plus OAM) per frame with moderate unrolling. That's five out of 64 16x32 sprites, or four on frames when it also updates a row or column of tiles or animates the palette. If half the sprites on the screen (32 out of 64) have more than one frame of animation (for example, not bullets), that limits animations to just under 10 fps on average. This can be enough for a slower game like an RPG.

I saw a thread down lower comparing the advantages of 8x8 sprites with the advantages of 8x16 sprites, and I think I should take another look at that, but yeah I am leaning towards 8x16. The majority of my objects are going to be 16x16, so that would mean I could have as many as 32 instead of 16 onscreen at a time, right? And the sacrifice is a few gaps in the sprite tiles, meaning slightly less graphical variety. In my case, I think I'd only really take a hit when dealing with some of the weapons and projectiles, and then only when they were pointed right or left. Of course, I should probably evaluate whether or not I actually NEED 32 objects onscreen at a time.


I'd been meaning to ask about sprite animations, actually. You guys have talked about the differences between CHR-RAM and CHR-ROM animations in the context of background tiles, but would the same kind of rules apply to sprites where system resources are concerned? Because I don't see bank switching done to animate sprites quite as much. That is, it does happen - Mario 3 swaps in a new set of tiles when any powered up Mario jumps - but it's a SET of tiles to use for animations. A new bank switch doesn't take place every frame.

In general, one 32-byte update packet can update one row of nametable, one column of nametable, the entire palette, or two tiles in CHR RAM. Battletoads is an example of a game that animates the player character by updating whole frames of animation to CHR RAM, but then it also keeps rendering turned off for the top 16 or so scanlines so that it has time for a larger update. The technique is more common on Genesis, Super NES, and Game Boy Advance, all of which have hardware-assisted copying to VRAM.

The big difference is that for sprites, the CPU has the entire frame to decide and prepare the new values, and then all that data is committed to the PPU during vblank in only ~5 scanlines. So, as long as all the frames can fit in the 4KiB sprite plane at the same time, there's no need to bankswitch out for animation.

@Okk : It's always like this, if 95% of games handles something a simple way and that 5% of them are doing it an "improved" way for which the hardware was not originally designed for, and requires some kind of "trickery", you can bet that all Nesdev regulars (including myself) are only talking about those rare/complex cases because they're more interesting and push the system closer to its limit.

So sprite animation is done like this :
aprox 80-90% of games : Static sprite pages that are only re-loaded / bankswitched when changing the levels (if at all)
aprox 10-15% of games : CHR-ROM, reserve a whole page for the main character and switch it depending on the animation frame
aprox 1% of games : CHR-RAM is updated as the character is animated. I can only think of a great total of 3 games (there's probably more) : Solstice, Battletoads and Prince of Persia.

So tepples and tokumaru were talking as if only the two last alternatives are possible, when in fact the first one is sufficient for the vast majority of cases, but is of course less interesting on the technical plan.

Also please note that I MADE THOSE NUMBERS UP I didn't collect them scientifically, but it is to show the idea.

Oh, sorry, for some reason (I honestly don't know why!) I though you meant you were gonna make the characters 8x16 pixels big, not that they were going to be made of multiple 8x16 sprites. In this case, yes, I totally agree with you. I always use 8x16, because even if you waste some tiles you can have more stuff on the screen.


On a real NES that wouldn't happen so often, because managing that many objects would consume a lot of CPU time and would probably cause slowdowns. Unless they were really simple objects, without complex physics behaviors or the ability to collide with many different objects.


You're correct. Many games that use mappers with 1KB or 2KB CHR bankswitching do have the main character's graphics spread across several banks, but the actual animation is not a direct consequence of the switch. In most cases, the OAM (memory that defines where the sprites are and what colors and tiles they use) is completely wiped and rewritten every frame. Each game implements its own solution, but I assume most have some sort of animation scripting system, with pointers to metasprites (the values that will be processed according to the positions of the objects they represent to generate OAM data) and timing information (how long each animation frame should be displayed).


But also on the Master System and B/W Game Boy, which don't have any hardware assistance (on the Master System this is almost mandatory, since it doesn't have sprite flipping), even if sometimes they have to use double buffering to avoid displaying partially updated sprites. There's one NES game I can think of, The Smurfs, which does take longer than a frame to update player patterns and doesn't do anything to hide it. The problem is clearly visible in this level, because of the bird's wings.


I think it's a bit less.


I think it's a bit more.


The percentage looks about right in this case. One game you forgot is The Smurfs, which I mentioned above. But like you said, there are probably more.

EDIT: I went looking for more games that animate player sprites through pattern table updates, and here are a few names:

-Alfred Chicken
-Asterix
-Bad Street Brawler
-Castelian
-Dragon's Lair
-Indiana Jones and the Last Crusade (Taito)
-Indiana Jones and the Last Crusade (UBI Soft)
-Ironsword - Wizards & Warriors II
-Wizards & Warriors III

Guess this technique isn't so rare on the NES after all. With a little more effort we can probably list at least 20 games or so, which would be more than 1% of all NES games.