Confusion about scanlines

[bigjt_2]

Hello,

I'm confused on the very principle of what's meant by "scanlines." I think part of my problem is I come from a video background rather than a computer science background, so when I read "scanline" I've been envisioning something similar to a "scan line" on a CRT screen. In other words, for the NES I'm envisioning a horizontal scanline being a line of pixels 1 pixel high by 256 pixels wide, and there would be 240 of these sequentially layered top to bottom of the screen.

However, the more I read the more I'm starting to think it's something a bit different. Mostly, it's the "8 sprites per scanline at one time" rule that's really throwing me. I understand that each sprite is 8x8 pixels (or, rarely, might be 8x16). But as I look at screenshots of various NES games, it seems there are way more than 8 different sprites on the same line, even counting the many that get repeated.

Again, my first conclusion is that I do not properly understand what a scanline is taken in the context of the NES display output. But if I do, could someone please tell me what I'm missing with the "8 sprites per scanline rule"? Perhaps there's some trick I'm not aware of? Or perhaps extra hardware on the cartridges allows there to be more? Perhaps I'm not looking at the my these screenshots correctly?

I'm reading Patrick Deskin's NES System Doc and these forums and just barely getting my feel wet (as everyone can tell). I haven't found a thread discussing a basic definition of scanlines yet but if there is one 1. I apologize and 2. please point me to it.

And thanks folks for what you do on this site. It's all really fascinating.

[tepples]

for the NES I'm envisioning a horizontal scanline being a line of pixels 1 pixel high by 256 pixels wide

That, plus 24 side border pixels that have the background color. Emulators ignore these; they mainly figure into the calculation of pixel aspect ratio, which turns out to be exactly 8:7 on NTSC.

and there would be 240 of these sequentially layered top to bottom of the screen.

That is correct.

However, the more I read the more I'm starting to think it's something a bit different. Mostly, it's the "8 sprites per scanline at one time" rule that's really throwing me. I understand that each sprite is 8x8 pixels (or, rarely, might be 8x16).

And each sprite spans 8 lines or 16 lines. For example, a sprite whose Y coordinate is 25 will span the 8 lines below 25: lines 26 to 33.

But as I look at screenshots of various NES games, it seems there are way more than 8 different sprites on the same line, even counting the many that get repeated.

Not all graphics on the screen are sprites. A lot are background tiles.

But if I do, could someone please tell me what I'm missing with the "8 sprites per scanline rule"?

There is a display list of 64 sprites. On every scanline y, the PPU reads through this list and looks for the 8 frontmost sprites that are on this scanline. (Any further sprites on this line are ignored.) At the end of a scanline, in the horizontal blanking interval, the PPU copies information about these sprites to a buffer that the PPU uses on line y+1 to draw these sprites.

[tokumaru]

I'm envisioning a horizontal scanline being a line of pixels 1 pixel high by 256 pixels wide, and there would be 240 of these sequentially layered top to bottom of the screen.

That's correct.

Mostly, it's the "8 sprites per scanline at one time" rule that's really throwing me. I understand that each sprite is 8x8 pixels (or, rarely, might be 8x16). But as I look at screenshots of various NES games, it seems there are way more than 8 different sprites on the same line, even counting the many that get repeated.

There are never more than 8 sprites in the same scanline. Unless you are mistaking background tiles for sprites. Some games draw items using background tiles (such as the coins in SMB), so they have nothing to do with the sprite limit.

Also, some emulators are configured to ignore the sprite limit (since it's easy for a PC to draw tons of sprites), so that there isn't so much flickering. Make sure you are not looking at screenshots made using this feature.

Again, my first conclusion is that I do not properly understand what a scanline is taken in the context of the NES display output. But if I do, could someone please tell me what I'm missing with the "8 sprites per scanline rule"?

The NES processes the picture one scanline at a time. This is a complex process, that involves checking all background tiles that are supposed to be displayed and what palette they should use, reading the graphics of said tiles and coloring them... and also calculating which sprites have visible parts in that scanline.

Every scanline the NES checks the Y coordinate of all 64 sprites looking for the ones that are visible in the current scanline. When it finds them, their graphics have to be fetched and colored. This takes time, and the video processor in the NES only has time to do this for 8 sprites. This is why after it finds 8, it stops looking, as there is no time to draw more than that.

The programmer can place more than 8 of them in the same scanline, but the ones with lower priority will just not show up, because the NES favors the ones with high priority.

Perhaps there's some trick I'm not aware of?

The only "trick" used is called sprite cycling. Since the sprites with lower priority are dropped, games usually randomize the priorities of the individual sprites every frame, so that a sprite that was dropped in one frame is displayed on the next. This causes sprites to flicker (sometimes they may look transparent) when there are more than 8 sharing the same scanlines, but the player can still recognize the objects and know where they are.

Or perhaps extra hardware on the cartridges allows there to be more?

This limitation can't be bent with cartridge hardware, since all the sprite logic is internal to the PPU.

Perhaps I'm not looking at the my these screenshots correctly?

Maybe you are mistaking background tiles for sprites or you are looking at screenshots from emulators that disabled the sprite limit, like I said above.

If you have more questions, keep them coming. =)

[Memblers]

Your understanding of a scanline is fine.

It sounds like you may have the background confused with the sprites. With a still screenshot it's not always obvious which tiles are background and which are sprites. Sometimes they can use the same set of tiles. Like a tetris block hitting the ground, changes from a sprite to background. There are 64 sprites that can be put anywhere, but the PPU doesn't have enough memory to display them all at once (on the current line). The background of course is a separate layer and covers the whole screen.

[bigjt_2]

tepples
“Not all graphics on the screen are sprites. A lot are background tiles.”
Tokumaru
“Maybe you are mistaking background tiles for sprites or you are looking at screenshots from emulators that disabled the sprite limit, like I said above.”
Memblers
“It sounds like you may have the background confused with the sprites. With a still screenshot it's not always obvious which tiles are background and which are sprites.”

Yep, this is exactly what I wasn't understanding. It's now a lot more clear to me how the "8 sprites per scanline" rule works. For whatever reason, I was actually thinking ALL graphics were generically classified as sprites.

Folks, you have no idea how satisfying it was reading your responses. You didn't just answer my question, but a whole slew of questions I'd had in the back of my mind playing the NES over the last 25 years. Most notably, the "flicker" effect. It's really cool to now know what exactly causes that. I know for you guys that's probably pretty basic knowledge, but seriously this is the first time I've found out.

So "sprites," as in other video game programming, are basically graphics (in this case 8x8 or 8x16 tiles) that animate, move, or may require some collision detection. And background tiles would basically be everything else. Am I correct in my understanding of that?

Also, I'm assuming "8 sprites" means no more than eight completely different sprites per scanline. In otherwords, if the same sprite is repeated on one scanline but at a different x position, the PPU could handle it. Is that correct? For instance, in Galaga you have all the little spaceships moving around at the top of the screen, but they're also the same tiles repeated over and over again on the same horizontal line.

Or, as Memblers mentioned, are those enemy ships at top really background tiles that become sprites when they move toward the player's ship?

And does that mean (though I think I know the answer to this) that background tiles on the NES can be animated? Ex. the waterfall in the Bubbleman stage in Mega Man 2?

[tepples]

I was actually thinking ALL graphics were generically classified as sprites.

They are on PC or Neo-Geo or Nintendo DS's 3D mode, but not on NES.

Also, I'm assuming "8 sprites" means no more than eight completely different sprites per scanline.

False. Even if they have the same pattern, you only get 8.

For instance, in Galaga you have all the little spaceships moving around at the top of the screen, but they're also the same tiles repeated over and over again on the same horizontal line.

Or, as Memblers mentioned, are those enemy ships at top really background tiles that become sprites when they move toward the player's ship?

At least some of them are probably background, at least on the NES port of Galaga. Some emulators, such as PocketNES when run inside VisualBoyAdvance, have a display option to hide all sprites, so you can easily see what's a sprite and what's a background tile. The arcade version of Galaga used a vertical monitor, which measured scanlines vertically, and its PPU was probably engineered with more sprite slots per line.

And does that mean (though I think I know the answer to this) that background tiles on the NES can be animated? Ex. the waterfall in the Bubbleman stage in Mega Man 2?

Background tiles are numbered 0 through 255. There are two major ways to change the image associated with a tile: give "bankswitching" commands to hardware on the cartridge, or store the tiles in RAM and rewrite the tile pattern data during vertical blanking.

[Jaffe]

tepples
So "sprites," as in other video game programming, are basically graphics (in this case 8x8 or 8x16 tiles) that animate, move, or may require some collision detection. And background tiles would basically be everything else. Am I correct in my understanding of that?

Yep, that's right

Also, I'm assuming "8 sprites" means no more than eight completely different sprites per scanline. In otherwords, if the same sprite is repeated on one scanline but at a different x position, the PPU could handle it. Is that correct? For instance, in Galaga you have all the little spaceships moving around at the top of the screen, but they're also the same tiles repeated over and over again on the same horizontal line.

I think you're confusing sprites with their graphical representation. There is no such thing as "completely different" sprites. Several sprites can use the same tile as graphics, but they're still independent objects that the PPU can't handle if they're too many on the same line.

And does that mean (though I think I know the answer to this) that background tiles on the NES can be animated? Ex. the waterfall in the Bubbleman stage in Mega Man 2?

Yeah. The tiles themselves can't easily be animated, but one can however change what tile is displayed at a certain position each frame. Thus one can cycle through a set of tiles with different frames of the animation.

[tokumaru]

I was actually thinking ALL graphics were generically classified as sprites.

It's understandable, since many people around the web use the term to talk about any graphic used in 2D games.

Most notably, the "flicker" effect. It's really cool to now know what exactly causes that. I know for you guys that's probably pretty basic knowledge,

We all started somewhere... =)

So "sprites," as in other video game programming, are basically graphics (in this case 8x8 or 8x16 tiles) that animate, move, or may require some collision detection. And background tiles would basically be everything else.

Yeah, kinda. Strictly speaking, the background is a grid of tiles of a fixed size, while sprites are movable entities that can be placed anywhere on the screen. Typically, sprites are used to represent characters, because they can move around freely, but some game objects might be represented with background tiles if there is a good reason for it (this is true for the NES, but almost never happens on systems that can display more sprites per scanline, like the SNES or the Mega Drive/Genesis).

Sprites can also be used to fake background elements, like when you need more colors than the background alone can provide or when these elements need some sort animation that's hard to pull off with background tiles.

It's all about creative use of the few resources you have.

In otherwords, if the same sprite is repeated on one scanline but at a different x position, the PPU could handle it. Is that correct?

No, it's 8 sprites, period. It doesn't matter if they use the same graphics.

For instance, in Galaga you have all the little spaceships moving around at the top of the screen, but they're also the same tiles repeated over and over again on the same horizontal line.

Galaga is a good example of creative use of sprites and background. Note that the "background" is all black, and that there are only a few starts going by. What happens is that the game is using sprites to simulate a background. The stars are sprites, while the background itself is fully black. When the enemy ships move in, they do it in a circular pattern in order to avoid hitting the sprite limit. When they finally line up, the game stops using sprites and starts using the background to draw them. The player can't tell the difference, and that's the beauty of it.

I recommend you grab a copy of the FCEUXD emulator, and use it's debugging features to understand a bit of how the games do their magic. Open Galaga in it and select Tools -> Name Table Viewer. The name table is the background, and whatever you see in it is drawn with background tiles, and whatever isn't there is drawn with sprites. Play around with different games and different debugging features and you'll learn a lot.

And does that mean (though I think I know the answer to this) that background tiles on the NES can be animated? Ex. the waterfall in the Bubbleman stage in Mega Man 2?

There are 3 ways to achieve a waterfall effect, I don't know which one this game uses, but it's surely on of them:

The easiest is to rotate the palette that contains the water colors. This will make the waterfall seem to be moving, but in fact the graphics don't change, just the colors change. The disadvantage is that nothing else can use the same palette, or the colors would change there too.

Another method is to modify the name table, overwriting the old tiles with the new tiles. This isn't done often, because overwriting tiles can be a very slow process since waterfalls can occupy very large areas of the screen.

Another common method is overwriting the graphics of the tiles. When you modify a certain tile, all instances of it on the whole screen will automatically show the changes. This is often used in games that can bankswitch CHR-ROM, because it takes very little time to switch graphics in that case. Some games with CHR-RAM also use this method, but they have to change the graphics of the tiles byte by byte, which is much slower.

Again, i recommend you look at some games using FCEUXD. Go to Tools -> PPU viewer and you can see how the palettes and tiles change in real time. Look at the Mega Man waterfall you mentioned and I'm sure you're gonna figure out the trick they used.

[bigjt_2]

Awesome! Thanks again for your generous help tokumaru, tepples, memblers, and jaffe. This site is awesome!

Also tokumaru, I'm downloading fceuxd from zophar right now. FCE Ultra has long been one of my favorite NES emulators, but I haven't had a reason to check out this debugger version until now. The more I learn from the Diskin's NES doc and from the forum here, the more I finally understand what's meant by pattern tables and all the other elusive stuff I see on the emulators' debug screens. Woo-hoo!

[WJYkK]

Sorry for hijacking this thread, but:

So "sprites," as in other video game programming, are basically graphics (in this case 8x8 or 8x16 tiles) that animate, move, or may require some collision detection. And background tiles would basically be everything else. Am I correct in my understanding of that?

If a tile is animated yet it is stationary with the scrolling, it could also be in the background instead of being a sprite, right?

[tokumaru]

If a tile is animated yet it is stationary with the scrolling, it could also be in the background instead of being a sprite, right?

Yes, but how easy it is to animate background tiles depends on the mapper.

CHR-RAM games have to rewrite the tile graphics in the pattern table, which takes a good amount of time, so they probably keep this kind of animation to a minimum.

NROM games simply can't animate patterns, they have to replace tiles in the name table, not very simple to implement in a game engine either, and again, time is a constraint.

CHR-ROM games that switch large chunks of tiles (such as CNROM or MMC1) can animate the pattern tables, but it's not practical because of all the tiles that are not animated but must be repeated across the different banks, which is a big waste of space.

The ideal way is to use a mapper that bankswitches ROM in small chunks (1KB or 2KB), like the MMC3, because it takes nearly no processing time to load the new graphics and not many static tiles have to be repeated.

[bigjt_2]

The easiest is to rotate the palette that contains the water colors. This will make the waterfall seem to be moving, but in fact the graphics don't change, just the colors change. The disadvantage is that nothing else can use the same palette, or the colors would change there too.

By the by, I looked into the Megaman 2 Bubbleman stage question and yes, it seems they handled it with a palette swap. Please don't hold me to that though. Interestingly, it looks like the "READY" that always appears at the beginning is borrowing from the same effect as the waterfall, as it's on the same Pattern Table and the fourth color it cycles through is the blue that seems to be used for transparency on that part of the stage.

But the waterfall is definitely background as it shows up on the nametable, and it's not animated because it appears there as one solid non-animating group of repeating tiles. There are, like I said a group of blues that keep swapping on palette. I also noticed that happening with the brown on the "?" blocks in Super Mario Bros. 1.

Very cool stuff.

[WJYkK]

The ideal way is to use a mapper that bankswitches ROM in small chunks (1KB or 2KB), like the MMC3, because it takes nearly no processing time to load the new graphics and not many static tiles have to be repeated.

So this could most likely be the way how in SMB3 the question marks were moving inside the question blocks. Heh, I thought any mapper could do it easily; looks like I learned something new.

[tokumaru]

So this could most likely be the way how in SMB3 the question marks were moving inside the question blocks.

Yup. It uses an MMC3, the most common mapper during the later years of the NES, when several games had that kind of background animation.

Heh, I thought any mapper could do it easily;

Well, if you use CHR-RAM the mapper doesn't matter, but the amount of tile animation you can do with CHR-RAM is significantly less than what can be done with an MMC3.