Hello World

[tepples]

In addition to the masking modes that Dwedit mentioned, the GBC supports background priority per tile, like the Sega Master System, Game Gear, Genesis, and Super NES. Each background has a second plane of tile attributes, and one bit of these attributes is "top priority". A tile can be placed in front of all sprites, even those with the priority bit off. It's often used for text boxes, or for the first tile of a wall. The NES does not have this; it has to use either A. plain backgrounds surrounding an object (SMB1) or B. the triple-overlap effect (SMB3) to simulate this.

As a side note, while looking at the GBC's specs, I was surprised to find out that it supports 8 palettes each for both the background and sprites (hence my other questions), and that it also has a faster processor (4 times as fast, iirc).

Please be careful not to fall for the megahertz myth, especially when comparing different CPUs with different instruction sets and different microarchitectures. As I understand it, the consensus from the C=64/Speccy wars is that an 8080-family processor such as that in a ZX Spectrum or Game Boy Color typically needs to be clocked twice as fast as an equivalent 6502. So one can treat the original GB's CPU as roughly the same speed as that of the NES, and the GBC CPU is only twice as fast.

[FinalZero]

There's the simple masking where the sprite goes behind everything in the background that's not color #0. Lots of games use this, including Super Mario Bros when you go through a pipe.

So, this is the only way that the GBC can do it, right? (Other than what Tepples said.)

Then there's another masking mode where you put a sprite behind the background, then subsequent sprites in the same place are not drawn. Super Mario 3 uses this 'mode' when you hit a question block and a mushroom comes out of it, it puts a dummy sprite behind the question block. The sprites of the mushroom are covered up by the pixels of the dummy sprite. Time Lord also uses this trick as well.
The masking sprite must be set to be behind the background, and must be earlier in the sprite table than the sprite which gets masked.

So, this is done to stop the mushroom from appearing on top of the block it comes out of, but to let it smoothly flow out of it at the same time, right?

For example, Here's time lord, and the sprites it draws to pull off a masking effect:

I think I understand.

Also, for that GBC screenshot, they are using the feature where every background palette has its own background color (color #0). If you look closely, the background area of that block is all the same color.

Indeed, I see it.

Also, for that GBC screenshot, they are using the feature where every background palette has its own background color (color #0).

And that's the first type of masking your described for the NES, right?

In addition to the masking modes that Dwedit mentioned, the GBC supports background priority per tile, like the Sega Master System, Game Gear, Genesis, and Super NES. Each background has a second plane of tile attributes, and one bit of these attributes is "top priority". A tile can be placed in front of all sprites, even those with the priority bit off. It's often used for text boxes, or for the first tile of a wall.

Can one put background tiles on top of other background tiles? That way, one could easily create text boxes by just laying a new layer of "top"-mode tiles into the background, and then remove them when the text box is finished, thus not needing to recalculate the tiles that are where the text box was.

The NES does not have this; it has to use either A. plain backgrounds surrounding an object (SMB1) or B. the triple-overlap effect (SMB3) to simulate this.

I don't understand the two things your describing here.

Please be careful not to fall for the megahertz myth, especially when comparing different CPUs with different instruction sets and different microarchitectures. As I understand it, the consensus from the C=64/Speccy wars is that an 8080-family processor such as that in a ZX Spectrum or Game Boy Color typically needs to be clocked twice as fast as an equivalent 6502. So one can treat the original GB's CPU as roughly the same speed as that of the NES, and the GBC CPU is only twice as fast.

I should've been more wary. Still, I didn't expect the GBC to be faster than the NES at all. I guess mentally I've equated the (graphics) capabilities GBC to that of the NES, and likewise for the GBA to the SNES, and DS to the N64.

[tepples]

Unlike the GBC PPU, the NES PPU has only one color #0. There is space for 28 colors in CGRAM, which would in theory allow a separate color #0 for each separate background palette, but the PPU only ever uses the first background palette's color #0 when rendering is on.

In addition to the masking modes that Dwedit mentioned, the GBC supports background priority per tile.

Can one put background tiles on top of other background tiles?

This is possible only in a very limited way. On the GBC, one would use the "window", and on the NES, one would use mid-screen scrolling.

That way, one could easily create text boxes by just laying a new layer of "top"-mode tiles into the background, and then remove them when the text box is finished, thus not needing to recalculate the tiles that are where the text box was.

Is it that hard to recalculate? You recalculate anyway when scrolling a background, unless you're doing a Zelda- or Battle Kid-style flip screen. And the GBC has a lot more work RAM than any licensed NES board, and more than any Famicom board short of SXROM, so you could probably just read the tiles out of VRAM, display your text box, and put them back.

The NES does not have this; it has to use either A. plain backgrounds surrounding an object (SMB1) or B. the triple-overlap effect (SMB3) to simulate this.

I don't understand the two things your describing here.

In the first Super Mario Bros. game for the NES, power-ups sprouting from blocks were drawn with back priority sprites. The tiles above a ? block were always solid color 0, and no water levels ever had ? blocks. Mario going into a pipe was likewise drawn with back priority sprites; notice how he disappears immediately when walking into the pipe at the end of 2-2, 7-2, and the water section of 8-4.

Super Mario Bros. 3 for NES couldn't always use this trick because powerups had to sprout behind the ? block but in front of occasionally more detailed background pieces, such as the dots in the background of a cave or the water in the back of a water level. So it used a back priority sprite appearing in OAM before the powerup to force background pixels to be drawn in that position.

I guess mentally I've equated the (graphics) capabilities GBC to that of the NES, and likewise for the GBA to the SNES

GBA with its 16.8 MHz ARM7TDMI CPU is comparable to a Super NES + Super FX. Compare Doom and Yoshi's Island on both platforms.

[FinalZero]

Unlike the GBC PPU, the NES PPU has only one color #0. There is space for 28 colors in CGRAM,

I thought there was only 4 palettes for each the background and the sprites?

which would in theory allow a separate color #0 for each separate background palette, but the PPU only ever uses the first background palette's color #0 when rendering is on.

Hmm, I didn't know that.

Is it that hard to recalculate? You recalculate anyway when scrolling a background, unless you're doing a Zelda- or Battle Kid-style flip screen.

I suppose not.

And the GBC has a lot more work RAM than any licensed NES board, and more than any Famicom board short of SXROM, so you could probably just read the tiles out of VRAM, display your text box, and put them back.

One would still do the same thing for the NES though, no?

In the first Super Mario Bros. game for the NES, power-ups sprouting from blocks were drawn with back priority sprites. The tiles above a ? block were always solid color 0, and no water levels ever had ? blocks. Mario going into a pipe was likewise drawn with back priority sprites; notice how he disappears immediately when walking into the pipe at the end of 2-2, 7-2, and the water section of 8-4.

So, I played until the end of 2-2, and now I see what you were trying to say.

Super Mario Bros. 3 for NES couldn't always use this trick because powerups had to sprout behind the ? block but in front of occasionally more detailed background pieces, such as the dots in the background of a cave or the water in the back of a water level. So it used a back priority sprite appearing in OAM before the powerup to force background pixels to be drawn in that position.

And I played until I found a block which didn't have a null background above it, so I understand tell the difference now.

Btw, in case anyone was wondering, the screenshot posted on the last page was from Dragon Warrior III, the remake for the GBC. It's interesting to compare it with the NES version, because the graphics were so vastly improved, yet I can't see any reason why the NES version couldn't have done most of the graphical techniques that the GBC version used. On that note, how many pattern tables can the GBC store? I assume at least 4, since it can hold twice as many palettes also?

[tokumaru]

I thought there was only 4 palettes for each the background and the sprites?

Yes, the NES has 4 background palettes and 4 sprite palettes. In theory, each palette has 4 colors, but there are some weird considerations about the first color (color 0) of each palette.

For the background, no matter what palette you use, if a pixel uses color 0 it gets drawn with color 0 of the first palette, even though has all 4 colors (1 for each palette) internally. There is a way to display those colors though, which is to disable rendering and make $2006 point to them. This is hardly useful though.

For sprite palettes, their first colors don't even exist, they are mirrors of the first colors in the background palettes. This means that the PPU has 4 * 4 (background) + 4 * 3 (sprites) = 28 colors internally, but because of the way background rendering works you only get to see 25 of them.

One would still do the same thing for the NES though, no?

It depends. Personally, I'd rather decode the data from the map again than waste hundreds of bytes just to remember tiles, specially if working only with the built-in 2KB of RAM.

On that note, how many pattern tables can the GBC store? I assume at least 4, since it can hold twice as many palettes also?

I'm not sure how much VRAM the GBC has for tiles, but I wouldn't make any assumptions based on the palette count, since there is no direct relation between them. You might even be right, but I doubt the palette count would have anything to do with this.

[tepples]

Unlike the GBC PPU, the NES PPU has only one color #0. There is space for 28 colors in CGRAM,

I thought there was only 4 palettes for each the background and the sprites?

There are 28 colors in these 4 + 4 palettes:

Background palette 0: 0, 1, 2, 3
Background palette 1: 4, 5, 6, 7
Background palette 2: 8, 9, 10, 11
Background palette 3: 12, 13, 14, 15
Sprite palette 0: 17, 18, 19
Sprite palette 1: 21, 22, 23
Sprite palette 2: 25, 26, 27
Sprite palette 3: 29, 30, 31

Colors 16, 20, 24, and 28 do not have distinct memory cells in the PPU. (They're mirrors of 0, 4, 8, and 12 respectively.) An oversight in the PPU design causes colors 4, 8, and 12 to be replaced with color 0 when rendering is turned on.

And the GBC has a lot more work RAM than any licensed NES board, and more than any Famicom board short of SXROM, so you could probably just read the tiles out of VRAM, display your text box, and put them back.

One would still do the same thing for the NES though, no?

On the NES, it's a bit harder because reading from VRAM is unreliable if sample playback is turned on. If a sample fetch happens on a certain clock cycle of the readback (LDA $2007), the CPU sends two read requests to the PPU as the DMA unit grabs and releases control of the address bus, and it misses one of the results. This also affects reading the controller ($4016 and $4017), but there are well-known ways to work around that, such as reading the controller twice and using the previous frame's keypresses if the read key states don't match. GBC doesn't have this problem because it has no DMA-based sample playback channel; instead, its triangle channel's waveform is rewritable like the waveforms on the FDS or TG16.

Btw, in case anyone was wondering, the screenshot posted on the last page was from Dragon Warrior III, the remake for the GBC. It's interesting to compare it with the NES version, because the graphics were so vastly improved, yet I can't see any reason why the NES version couldn't have done most of the graphical techniques that the GBC version used.

NES has no background tile flipping, unlike GBC. Tile flipping allows for certain CHR optimizations on trees, walls, grass, etc. GBC also has MMC5-style palette per tile instead of per block of 2x2 tiles. NES has less capacity for sprite overdraw: 8 sprites per line (25% overdraw on a 256px wide screen) vs. GB/GBC 10 sprites per line (50% overdraw on a 160px wide screen), and possibly for this reason, characters using Mega Man-style overlays for extra color appear to be more common on GBC than on NES because they're less likely to cause dropouts and flicker. Oh, and there are thousands of usable colors on the GBC (like on the Game Gear), unlike the NES where 52 colors in an HSV arrangement plus a screen-wide tint control are all you get.

On that note, how many pattern tables can the GBC store? I assume at least 4, since it can hold twice as many palettes also?

The Game Boy has 6 KiB of VRAM devoted to one and a half pattern tables: 128 tiles just for sprites, 128 tiles to share between sprites and backgrounds, and 128 tiles just for backgrounds. The remaining 2 KiB of VRAM is used by two nametables in a single-screen mirroring configuration.

The Game Boy Color has two sets of one and a half pattern tables, and one bit of the attribute selects whether a tile or sprite uses the first or second table.

[FinalZero]

Yes, the NES has 4 background palettes and 4 sprite palettes. In theory, each palette has 4 colors, but there are some weird considerations about the first color (color 0) of each palette.

And no mapper can increase the number of palettes, right?

There are 28 colors in these 4 + 4 palettes:

Background palette 0: 0, 1, 2, 3
Background palette 1: 4, 5, 6, 7
Background palette 2: 8, 9, 10, 11
Background palette 3: 12, 13, 14, 15
Sprite palette 0: 17, 18, 19
Sprite palette 1: 21, 22, 23
Sprite palette 2: 25, 26, 27
Sprite palette 3: 29, 30, 31

I didn't know that the first color in the sprites (and later 3 background palettes) was ignored.

Colors 16, 20, 24, and 28 do not have distinct memory cells in the PPU. (They're mirrors of 0, 4, 8, and 12 respectively.) An oversight in the PPU design causes colors 4, 8, and 12 to be replaced with color 0 when rendering is turned on.

So it wasn't intentional, but accidental?

On the NES, it's a bit harder because reading from VRAM is unreliable if sample playback is turned on.

What does "sample playback" mean? Any sound or music?

NES has less capacity for sprite overdraw: 8 sprites per line (25% overdraw on a 256px wide screen) vs. GB/GBC 10 sprites per line (50% overdraw on a 160px wide screen)

What do you mean by overdraw? Being able to draw on the part of the screen that isn't displayed?

The Game Boy has 6 KiB of VRAM devoted to one and a half pattern tables: 128 tiles just for sprites, 128 tiles to share between sprites and backgrounds, and 128 tiles just for backgrounds. The remaining 2 KiB of VRAM is used by two nametables in a single-screen mirroring configuration.

By "tile", you mean an 8x8 block of pixels, right?

NES has no background tile flipping, unlike GBC. Tile flipping allows for certain CHR optimizations on trees, walls, grass, etc. GBC also has MMC5-style palette per tile instead of per block of 2x2 tiles. NES has less capacity for sprite overdraw: 8 sprites per line (25% overdraw on a 256px wide screen) vs. GB/GBC 10 sprites per line (50% overdraw on a 160px wide screen), and possibly for this reason, characters using Mega Man-style overlays for extra color appear to be more common on GBC than on NES because they're less likely to cause dropouts and flicker. Oh, and there are thousands of usable colors on the GBC (like on the Game Gear), unlike the NES where 52 colors in an HSV arrangement plus a screen-wide tint control are all you get.

Still, I think they could've done better. They could've made overlapping walls and trees, trees that are sized properly, bushes that actually look like bushes (I played through the whole game (of the NES version) and didn't realize until looking at the GBC version again that those clumps of dark and light green on the ground were supposed to be bushes.), etc. Least they had learned something from the time they began DW1 and 2 though, because those were uglier yet.

Btw, with the screenshot I posted earlier in mind, I suppose that with each step the player takes, the game must calculate whether the lower part of a character should underlap the background or not, depending on the character's coordinates on the map?

[tokumaru]

And no mapper can increase the number of palettes, right?

No, they really can't. The palettes are stored inside the PPU, so the mappers can't interfere in the process of reading them like they can with pattern/name/attribute tables, which are stored outside of the PPU.

I didn't know that the first color in the sprites (and later 3 background palettes) was ignored.

The first color of the sprite palettes doesn't even exist (there's no memory to store them)... It's not like you could do anything with them anyway, since color 0 means transparency for sprites.

So it wasn't intentional, but accidental?

I believe this was intentional... I imagine that using the first color globally requires some extra logic, which they wouldn't have used if they didn't explicitly want the PPU to behave like that. Maybe the "oversight" tepples was talking about was failing to realize that the other way would be more versatile, because developers would be able to use different colors if they wanted to but they could also make them all the same.

What does "sample playback" mean? Any sound or music?

The NES has 4 audio channels that play simple waveforms that sound like "blips and blops" (i.e. typical 8-bit era sounds) but it also has a PCM channel that can be used to play more complex sounds such as real instruments or the human voice. These sounds are called "sampled sounds" because you record them by sampling the sound wave at a constant frequency, and with that information the same sound (or an approximation of it) can be played back.

One way to play sampled sounds on the NES consists in pointing it to the DPCM data in the ROM that you want to play, and it will do so while the program keeps running. From time to time, the CPU will briefly interrupt the program to read bytes containing sampled sounds from the ROM, and these reads are the ones that can interfere with joypad and PPU reads.

What do you mean by overdraw? Being able to draw on the part of the screen that isn't displayed?

In this case, overdraw means how much of the scanline can be filled with sprites. "Over" probably means "on top" here, meaning that the sprite can cover a certain amount of the background.

By "tile", you mean an 8x8 block of pixels, right?

Yes. Which means that the GBC has 768 tiles, according to what tepples said.

[tepples]

Yes, the NES has 4 background palettes and 4 sprite palettes.

And no mapper can increase the number of palettes, right?

Correct. But a mapper can make smaller background color areas (8x1 pixels instead of 16x16 pixels), and in theory, a mapper can even include a more sophisticated PPU that can fake more palettes through spatiotemporal dithering.

An oversight in the PPU design causes colors 4, 8, and 12 to be replaced with color 0 when rendering is turned on.

So it wasn't intentional, but accidental?

I'm almost certain that nobody posting to this board worked for Nintendo during 1983 when Nintendo was engineering the PPU. Therefore, we can't know for sure whether the inability to use colors 4, 8, and 12 was intentional or accidental.

reading from VRAM is unreliable if sample playback is turned on.

What does "sample playback" mean? Any sound or music?

Only channel 5 plays back samples streamed from ROM. The Legend of Zelda and Super Mario Bros. 2: Mario Madness use this for sound effects that were produced with the FDS adapter's channel 6 on the respective FDS versions of these games. Super Mario Bros. 3, Contra, and Blades of Steel use this for drums; several later games by Sunsoft use it for the bass. The other four channels are digital tone generators, do not automatically read data from ROM or RAM, and therefore do not interfere with reading from VRAM or the controllers.

NES has less capacity for sprite overdraw: 8 sprites per line (25% overdraw on a 256px wide screen) vs. GB/GBC 10 sprites per line (50% overdraw on a 160px wide screen)

What do you mean by overdraw? Being able to draw on the part of the screen that isn't displayed?

You're thinking of either nametable arrangement or overscan. Overdraw is something entirely different, related to the amount of space on the screen that sprites can cover. In 3D graphics, "overdraw" refers to the total area covered by overlapping triangles. Video processors descended from the TI TMS9918 family VDPs used in the TI-99/4A, ColecoVision, and MSX, such as those in the NES, SMS, Game Boy, Genesis, Super NES, and GBC, have limits on the number of sprites that can appear on the screen, the maximum size of sprites, the number of sprites that can appear on one scanline, and the total number of sprite pixels that can appear on one scanline. I have used the term "overdraw" to refer to the amount of area that can be covered by sprites without dropout, in most cases with respect to the amount of a scanline that can be covered with sprites.

The Game Boy has 6 KiB of VRAM devoted to one and a half pattern tables: 128 tiles just for sprites, 128 tiles to share between sprites and backgrounds, and 128 tiles just for backgrounds. The remaining 2 KiB of VRAM is used by two nametables in a single-screen mirroring configuration.

By "tile", you mean an 8x8 block of pixels, right?

Correct. Tiles on the vast majority of VDPs descended from the TMS9918 are 8x8 pixels in size. On the NES, Game Boy, and Game Boy Color, the data for each 8x8 pixel tile is always 16 bytes in size.

They could've made overlapping walls and trees

Overlapping objects in the background require extra tiles and, if the objects are of different colors, often extra palettes. That's one reason why roofs of RPG houses often sloped with the flat part toward the camera (as seen here), as opposed to toward the sides (as seen in the home button of your web browser): so that the edges could remain aligned to the tile grid.

trees that are sized properly

Which would have required extra care to show the correct overlap when the player walks behind them. This is tricky. Even on the Super NES, with its two main background layers and background priority per tile, Sony didn't get player-background occlusion 100% right in Equinox.

[FinalZero]

Correct. But a mapper can make smaller background color areas (8x1 pixels instead of 16x16 pixels), and in theory, a mapper can even include a more sophisticated PPU that can fake more palettes through spatiotemporal dithering.

I don't know what spatiotemporal dithering is, but it sounds like something that would be very unrealistic to implement. Did any licensed games use such a thing?

Only channel 5 plays back samples streamed from ROM. The Legend of Zelda and Super Mario Bros. 2: Mario Madness use this for sound effects that were produced with the FDS adapter's channel 6 on the respective FDS versions of these games. Super Mario Bros. 3, Contra, and Blades of Steel use this for drums; several later games by Sunsoft use it for the bass. The other four channels are digital tone generators, do not automatically read data from ROM or RAM, and therefore do not interfere with reading from VRAM or the controllers.

[what Tokumaru said] ...

I see.

Overlapping objects in the background require extra tiles and, if the objects are of different colors, often extra palettes.

1) Why would it require extra tiles?
2) Ack, I forgot that palettes are distributing to 16 by 16 pixel blocks, not 8 by 8... Perhaps it wouldn't be possible then...

The first color of the sprite palettes doesn't even exist (there's no memory to store them)... It's not like you could do anything with them anyway, since color 0 means transparency for sprites.

Oh. I thought one could turn off the transparency for sprites if one wanted to, thus allowing a fourth color.

[tepples]

a mapper can even include a more sophisticated PPU that can fake more palettes through spatiotemporal dithering.

I don't know what spatiotemporal dithering is

Dithering means adding noise to spread out rounding errors. Spatial dithering spreads out rounding errors between neighboring pixels. Temporal dithering spreads out rounding errors from one frame to the next: each pixel is flickered. "Spatiotemporal" dithering spreads out rounding errors both to neighboring pixels and to the next frame. But a PPU-in-a-mapper is largely theoretical (apart from Wide Boy) and not something you need to worry about at this stage.

Did any licensed games use such a thing?

Flickering the least significant bit of palette values is a form of temporal dithering that appears to have been common in Genesis games in order to work around the limitation of 3 bits per channel in the palette, compared to 5 bits on the Super NES, so that gradients don't royally suck.

Overlapping objects in the background require extra tiles and, if the objects are of different colors, often extra palettes.

1) Why would it require extra tiles?

Because when you overlap two objects in the background, and they don't have clean edges on tile boundaries, you have to composite all combinations of the two objects into CHR RAM or include all combinations in the CHR ROM.

Oh. I thought one could turn off the transparency for sprites if one wanted to, thus allowing a fourth color.

This is possible in SDL, but not in NES.

[tokumaru]

Did any licensed games use such a thing?

I don't think so, it's too much trouble. This set of demos seems to be a good example of the technique, though.

[FinalZero]

Dithering means adding noise to spread out rounding errors. Spatial dithering spreads out rounding errors between neighboring pixels. Temporal dithering spreads out rounding errors from one frame to the next: each pixel is flickered. "Spatiotemporal" dithering spreads out rounding errors both to neighboring pixels and to the next frame. But a PPU-in-a-mapper is largely theoretical (apart from Wide Boy) and not something you need to worry about at this stage.

Ok.

Flickering the least significant bit of palette values is a form of temporal dithering that appears to have been common in Genesis games in order to work around the limitation of 3 bits per channel in the palette, compared to 5 bits on the Super NES, so that gradients don't royally suck.

Oh, the Super NES had 32 colors per palette? And 65k-some colors to choose from I assume?

Because when you overlap two objects in the background, and they don't have clean edges on tile boundaries, you have to composite all combinations of the two objects into CHR RAM or include all combinations in the CHR ROM.

So, I was right when I said this, right?:

2) Ack, I forgot that palettes are distributing to 16 by 16 pixel blocks, not 8 by 8... Perhaps it wouldn't be possible then...

Could overlap like in the screenshot I posted before be possible on the NES? Or would one need more colors per palette?

[Dwedit]

Oh, the Super NES had 32 colors per palette? And 65k-some colors to choose from I assume?

32 possible intensities for R G or B in a color, not 32 colors per palette. Compare with VGA's range of 0-63 for intensity, or later video card's 0-255 range.
I believe there are 16 16-color palettes on the SNES.

[tokumaru]

Could overlap like in the screenshot I posted before be possible on the NES? Or would one need more colors per palette?

You mean how the wall overlaps the characters? The best way to do that on the NES would be to use mask sprites... sprites with the same shape as the wall, with higher priority (lower OAM index) than the character sprites and with the "behind background" bit set.

When your character sprites and the mask sprites overlap, the PPU will first check which sprite has higher priority, and since the mask sprites appear first in the OAM they will win. Then, the PPU will try to draw the mask, but since it's configured to be behind the background, the background is displayed instead.

The only problem with this technique is that the sprite count raises quite quickly. You obviously wouldn't keep the masks in place at all times, only when necessary, but even then the limit of 8 sprites is reached fairly easily, so there will be some flickering.