nesdev.com

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.

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi

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.