nesdev.com

So, I'm finding myself shocked and bamboozled by how darn few sprite palettes you can have at once. It's just four! It's not like I didn't know that beforehand, but now that I'm actually coding up my project I'm struck by how little four actually turns out to be.

I'm making a co-op kinda thing, so I'm using one palette for player one, one palette for player two, and now I'm left with two palettes for all the enemies and objects they encounter. Furthermore, I usually want black outlines on my enemies which means enemies can have a grand total of two sets of two different colors.

But old retro games should be colorful and alive! So, I've been brainstorming about strategies and tricks to help maximize the color liveliness of the game. I figured I'd write down my thoughts here, and see if there are any other clever ideas I'm missing out on.

Palette Reuse
The obvious first thing to think about is to try to reuse as many palettes as possible. By making enemies that have the same color scheme as player one and two, we suddenly got four different colored enemies instead of two. But, that runs into a wall if you are planning on changing the palettes, for instance like when Mario gets a fire flower and switches to a new yellow and white palette. Unless you are willing to have enemies also magically change colors out of the blue along with Mario then reusing palettes is difficult.

But in certain cases palette reuse can be pretty safe, Mario's fireballs uses the same colors as Fire Mario. When ice Kirby freezes enemies into blocks of ice they use the same blue colors as Kirby's blue form. If either of them loses their special power (this changing their palette) then the projectiles/ice blocks can simply be deleted on the same frame and most players wouldn't mind.

Also, when reusing a palette between two different sprites you can switch around which color you are mostly emphasizing, thus giving the sprites a very different "feel" despite using the same palette.

Changing the palettes actively
Some games (like the Mario games) sets the palettes per level, so that when you enter a level the palettes are loaded and stays there. Enemies simply use those palettes whether they fit or not, so the level design has to be done carefully so there are no terrible clashes of sprites and palettes that look bad together. The easiest example of this level palette design are the Goombas who turn grey in underground levels.

But it's entirely possible to change the palettes on-the-fly inside of a level depending on what enemies appear. Doing so offers a number of pitfalls though, what to do if all four palettes are already in use when a new kind of enemy appears? Simply delete it?

This is the strategy I'm going for in my project. To avoid some of the pitfalls, I'm also giving each enemy a list of alternative color schemes, so that if all palettes are currently occupied they can in a pinch appear reusing one of the other already existing palettes looking only slightly different.

Mid-screen palette changes
Probably not, based on the various topics about it here on the forum it doesn't seem viable for anything except a split-screen game with a big black bar in the middle.

What I normally do is use 2 or 3 palettes (depending on how colorful the protagonist is) for constant objects, such as the protagonist, items, explosions and other effects, and 1 or 2 palettes that can be dynamically changed by the level. Enemies and level objects can use the constant palettes, that usually contain useful colors such as gray and orange, but the custom ones will usually fit the theme of the level better.

There's also software blitting to modify background tiles around the player to add white and black to the other three colors, but that's very slow. You'd need to reserve Black and White in your background palettes as well, leaving two remaining colors in each background palette.

Or even sprite overlays, if you need to add a small black and white object (8px wide) to another object. Mario 2 does that.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!

Even SMB1 changes palettes mid-room sometimes. Aside from the obvious case where the Mario / Luigi / Fire state changes, it also loads a new palette for Bowzer, and possibly other cases. Not being able to scroll back and forth is probably a big help here.

The other thing that's important in SMB2/3 is how levels are frequently divided up into smaller rooms. Very useful for keeping the enemy combinations contained.

I ran into terrible palette problems making the Jammin Honey game. Not just palettes, but 8 sprite limit problems. Honey always takes up 4 sprites wide, due to overlapping guitar sprites...and uses up 2 full palettes. that means that I can only have 2 enemies on the same scanline before flicker madness. If there is a coin or star, only 1 enemy can be on the same scanline.

so 2 palettes are reserved for honey, 1 for coins and stars, left me only 1 palette to use for most enemies. I had to reuse as much as possible (bees use coin yellow, chicken uses coin brown, fire uses coin yellow)

The white in the chicken's eye is just BG white. noticeable only when she walks over a ladder.

it's tough. it would have been easier if I used only 1 palette for the hero. or if I had restricted each room to only have 1 type of enemy, I could have been more colorful with each enemy.

it was a trade off. I ordered mixed enemies per room to more colorful enemies.

EDIT, correction, I made coins smaller, so I think you can have 3 coins on the same scanline as honey, without sprite flickering.

_________________
nesdoug.com -- blog/tutorial on programming for the NES

One thing i've found a bit useful so far is reserving only one extra colour in another subpalette for sprite overlays on a main character or the like. So, let's say there's black outline and two shades for armour in the basic sprite, and one colour for skin in the overlay. What it means is the "skintone" (or whatever it is you're overlaying) will have one context on the player character, and a wholly other when used together with the two free colours in the same palette on some other metasprite object.

It's very circumstantial advice and ymmv.

_________________
http://www.frankengraphics.com - personal NES blog

That's neat. With things that only use 1 or 2 colors (like a bullet) you could extend this trick quite a lot.

It is at least lucky to have 4 sprite palettes on the Famicom. IMO the more restricting factor is its 2bpp graphics, giving each sprite only 3 (+1 transparent) colours, making you use more than one palettes in an object (like sprite overlaying in Rockman and SMB2US or using different palettes in different portions like in Contra; I think the Double Dragon games use both) if you want it to be more colourful. There are many clever ways in arranging these palettes though, as mentioned by people here.

You're not so lucky if you developed for the Sega systems BiTD though. The SMS has only one single palette for sprites, and no sprite flipping feature too, forcing you to use different sprites for even just palette swapped objects and characters facing different directions. You could use dynamic sprites by constantly changing the sprite table but that eats CPU time in uploading the graphics to video memory. The Mega Drive isn't terribly better either as it has only 4 palettes combined for both sprites and backgrounds (which IMO is worse than the Famicom). The sprites on these systems are 4bpp though so in general stuff should still look better, and I think mid-screen palette changes are relatively easier too.

Another interesting trick is that you can cycle palettes on certain items, projectiles, effects or anything that shines/flashes/glows, and it won't look like they're reusing palettes from other objects. SMB1 does this a lot, but the effect looks cooler in Batman Return of the Joker. As long as the palettes have their colors sorted by brightness, the exact colors used may not even matter much.

In my view, dealing with the palette limitations on the NES is the one thing that most makes it an "NES game". I think it ends up making a big impact on every NES game's design, probably moreso than other limitations of the system. At least, that's how it feels for me. RAM size, performance, etc. are "easier" constraints that take up less of my thought, but palette restrictions are a problem that never goes away.

Maybe an exception to this is to port other ideas to NES and "not care" how the palettes get distributed, like you could say that all the enemies are grey and just go with that. Kind of the least interesting option though.

(I feel similarly about the triangle channel and NES music. I feel like dealing with that one thing has the biggest effect on the whole.)

I get what you mean rainwarrior, and I agree. But at the same time, the mental image I have in my head of old Nintendo games from my childhood were that they were pretty colorful (minus yellow I guess). Megaman's blue color theme really sticks in your mind, and seeing Mario light up with fireflower power while raining fiery death everywhere.


Another thing I realized is that if you got some surplus in the sprite pattern department you can include duplicate sprites with different colors bits set. It can be pretty useful for say, white bullets in a megaman style game, since there is always bound to be some white color in one of the palettes currently in use.

You could also have duplicate sprites with less color details, thus being able to reuse a palette that only has 2 of the 3 colors correct. The loss of detail might not be noticeable if it's moving fast or of minor importance. Take the cannon balls in SMB3, they have a white shiny reflection on one side, but if that were to disappear in favor of a 100% black sprite in an especially crowded scene nobody would notice.

No, that's exactly what I mean! A lot of NES games had very good use of colour! There a huge desire to do so, but the palettes make it a struggle. To pull it off, your game needs to be designed around the limitation, and I think NES game design is dominated by this desire. There are all sorts of arbitrary decisions in NES games about what enemies go together etc. that just wouldn't be made on other platforms.

The other thing dictating palette assignment is CHR ROM/RAM address space limit. If you are dynamically loading tiles into CHR RAM or swapping 1K (64-tile) chunks of VRAM using an MMC3-class mapper depending on what tile is visible, that may provide an additional constraint on what enemy combinations are viable.

$1000-$13FF and $3F11-$3F13: Player 1
$1400-$17FF and $3F15-$3F17: Player 2
$1800-$1BFF and $3F19-$3F1B: Enemy 1
$1C00-$1FFF and $3F1D-$3F1F: Enemy 2

How are you organizing CHR memory? What mapper, and ROM or RAM?


Because it has no hardware flipping, a Master System or Game Gear game needs to use a lookup table to flip sprite tiles. But if you do that, you can make additional lookup tables with horizontal shrinking baked in, giving you Neo Geo-style shrinking for free. (Z80 excels with page-sized LUTs.)

Yes, I know that, but still you need constant upload of data to video RAM, especially if you want to have a variety of enemies(or animated frames, etc.) on the screen at the same time, and that when different enemies using the same design but facing different sides appear in a frame you need two copies of them. Ironically the background plane has nearly everything the sprites missed: able to flip tiles, two palettes (though one is shared with the sprites) which could even be set individually for each tile (unlike the 2x2-tile attribute grid of the Famicom, unless you use MMC5). No wonder many SMS games abused background updates as much as possible, with the most obvious drawback being choppy movement due to objects aligned to a grid, and that many objects are terribly symmetrical(in both shape and "pillow" shading) in order to save memory by reusing tiles as much as possible(the rocks, trees, enemies and whatever in Space Harrier, and the town folks in Phantasy Star are quite noticeable).

I'm using the MMC5, 8K sized CHR pages, with 8x16 sprites so that I get 8 separate sprite CHR pages to use.

It would be neat to use CHR RAM, but I'm not sure if it's even possible with the MMC5?