nesdev.com

MMC5 supports CHR RAM, though no existing cart board came with CHR RAM. You'd have to modify a board to take CHR ROM, just as you'd have to modify cart boards to take flash memory for PRG ROM.

Currently there's no CPLD clone of MMC5, so think about that if you're seeking cart manufacturing.

For "constant upload of data to video RAM", look at what's going on in Haunted: Halloween '85. The demo is part of the forthcoming third volume of Action 53.

Sure, the two players are both sprites, but you don't have to always use sprites for enemies or objects! You can use the playfield quite effectively for:

Stationary objects - like the coins in SMB and SMB3. Unless you're using MMC5's extended attributes, you're limited to one playfield palette for every 16x16 metatile, and that's one reason why the coins are as big as they are. The coin palette is also used for other parts of the level, like breakable blocks and question mark blocks.

Stationary enemies - if the enemy scrolls with the level and doesn't otherwise move.

Boss fights - to have a really crazy boss fight with tons of objects on screen, many games would make the boss itself out of playfield tiles, and scroll the screen to make the enemy move. The Guts Man fight in Mega Man 2 and the Technodrome fight in TMNT both come to mind. Since the boss is the playfield, the rest of the screen is just the background color, but that never seemed to bother anyone.

Technodrome is a terrible name.

drome means "racetrack" or running. This thing moves slowly. In no sense is it racing.

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

I'm not up on TMNT lore, but my first handwave would be that it used to be a racetrack for a traveling cyclesport exhibition before Shredder bought it to convert it to a mobile fortress.

I wonder if it was named in reference to Videodrome, the excellent David Cronenberg sci-fi body horror film? And I think "videodrome" itself is supposed to be a portmanteau of "video" and "syndrome".

I just quote you because I agree Also the 8-sprites per line limitation make it difficult to overlay sprites without running into problems.

As for answering the original question, my opinion is that 1 palette for player 1, 1 palette for player 2 and 2 palettes for enemies is the very standard way to do it (assuming a 2-player co-op game). If you need the palette to change to reflect player's state there's not much else you can do. The only thing you can do is change the enemy's 2 palettes during the level.

Just Breed has a system where it loads the sprite palette dynamically in function of what it needs to draw, every frame. As far as I know this is unique. It also uses some sprite overlay for the hero, meaning the first 2 palettes are "fixed" and only the last 2 variable (dynamically loaded).

Another very simple "trick" is to have a constant sprite palette across the whole game. It might sound like it's not a very advanced technique, but it works wonders for Castlevania and Battletoads&Double Dragon for example. Since you know what colour palette you have at all times, you can reflect state changes of the player by changing them, and any enemy can use all 4 palettes freely. Battletoads on the other hands has only the 4th palette which is variable.

One thing that might help in a co-op game is not making your player 1 and player 2 characters palette swaps of each other. That way they can use the same palette, and you can justify their being the same color as a uniform or whatever. But I'd need to see your character designs in order to tell whether that's plausible for your project.

Or: Make them palette swaps in the way that you save their tiles twice in memory, only that one character uses a red shirt and blue pants while the other one uses a blue shirt and red pants.

_________________
Available now: My game "City Trouble".
Website: https://megacatstudios.com/products/city-trouble
Trailer: https://youtu.be/IYXpP59qSxA
Gameplay: https://youtu.be/Eee0yurkIW4
German Retro Gamer article: http://i67.tinypic.com/345o108.jpg

That was one of the things that surprised me when I started looking into NES.

Like flashing/changing one sprite's palette different colours to show damage states etc. seems like such a common / obvious / easy technique on most other systems I'm familiar with, but on NES when it happens it's usually designed very specially around it. Maybe having several versions of the sprite in CHR for different rotations of the colour, or reusing one of the existing palettes instead, or if it's a "background" sprite using attributes instead of changing the palette itself. I did not expect all these work-arounds before I got to know the NES.

Been interesting reading this. I was under the impression that because the pallete is hard coded into the system you could actually change colour palettes on the fly.i mean for each level loaded, load title screen for example that uses 4 pallets, and Sprite layering using 4 pallets, then when going to level 1 use a completely different set of 8 palletes(4bg,4spr) and so on for each level. Turns out you can't if what I have read. It is literally 8 palletes throughout the whole game. Am I right?

No, you can change the whole set of palettes every frame.

The restrictions come from trying to juggle them. E.g. if you have 4 characters on the screen that each need a palette, what happens when you add a 5th?

Oh I got ya now, that's good to know. Thank you very much that was proper helpful.

When you're working with a limited palette you need to make the most of the colors you have. That's for any resource, really. Tile count, pixels, etc. There are many good examples of graphics on the graphics forum.
One thing you can do is make two characters that use the same palette where one has predominantly more of one color and the other has most of another color. The remaining color is used for details. Could be hard to do if one color is darker than the other (which I personally prefer to do rather than pick two colors with similar brightness).
I think the best thing to do is as mentioned to keep the game "simple" and change palettes during gameplay when needed if you want to add variety in a level.

As for unusual techniques:
If you don't mind a little "bzzt" effect you can get extra perceptive colors by flickering the tiles with horizontal lines, like what Macbee did with Lucky Penguin https://www.youtube.com/watch?v=8i6bDMH4PaM
Another thing you can do is you can change the PPU intensity mid frame to get darker colors after a certain scanline. There's a game that does this to simulate water surface.

_________________
https://twitter.com/bitinkstudios <- Follow me on twitter! Thanks!

On my game megaman odyssey ...i always struggle so darn hard to deal with sprite palettes. You guys know how some enemies in the megaman games will have completely different sprite palettes in different levels ??

Like a sniper joe in mm 2 flashman may be pink-ish/red ...but then later in a Wily level the same sniper joe is purple/blue/orange or whatever.

For mine, i "dont" want enemies to use different palettes no matter where they may be, or in which-ever levels. So it makes it way harder to pair enemies with others. Often i'll have a custom palette change event when you cross through X screen at X position.

In the last hallway of pyro man level, i have nearly every single enemey type for the level appear, across 4 total sprite palettes "not" including megaman's blue and peach-white, and 2 times during the hallway i change the sprite palette a couple pixels before you scroll them on the screen to load their correct colors.

I also must delete the enemies with the "previous" palette so they dont get the wrong colors once the new ones are scrolled on screen.

It is possible to make mid-level palette changes completely dynamic if you load/unload palettes as objects are activated/deactivated. Each object's initialization code can check if its palette is already loaded, use the index where the palette is, and increment a counter indicating how many objects are using that palette. If the palette isn't available, load it in the next available slot and set its use count to 1. When deactivating an object, decrement the number of uses of its palette accordingly, and if that becomes 0, free the palette slot.

That way you don't have to worry about hardcoding palette changes to scroll positions, you can place enemies freely when designing your maps, you just have to mind the distance between areas patrolled by differently colored enemies, so that a palette slot is guaranteed to be available when an enemy using new colors shows up.