nesdev.org

Is it possible to change the palette's values per a scanline in a practical way (so it can be used in a game and not only demo)?

You can change the palettes for a status bar, or other vaguely similar things, but that's approximately it.

After every scanline? No. A clean palette change requires several blank lines, one for each of the eight 3-color subpalettes. There's an Indiana Jones game that changes the background color ($3F00) only, and only on the title screen, and with a few blank tiles at the right side, but that's it.

By "several blank lines" you mean blank scan lines? Right?

Concerning the title screen of Indiana Jones: I see empty tiles in the left not right. Isn't?

You should be looking at this Indiana Jones title screen.

The problem with changing palettes mid-frame on the NES is that a lot needs to be done: set the VRAM address, write the new color(s), and restore the scroll to what it was supposed to be. There's only a teeny tiny window in hblank during which you can manipulate the VRAM address without corrupting the display, which is not nearly long enough to accommodate everything that needs to be done, so you really need forced blanking, which means blank scanlines. And by "blank" I mean completely blank, not even sprites can be rendered in those scanlines.

Thanks a lot guys!

I hoped maybe it was possible to sacrifice side tiles to extend hblank possibilites.
The fact that it's needed to sacrifice entire scanline is sad.
Everything becomes quite impractical.

So as tepples said (and I have understood it right) it's needed one scanline to change 3 values in single palette?

greatkreator wrote:The fact that it's needed to sacrifice entire scanline is sad.

There are 2 reasons why you need to sacrifice entire scanlines. The first is that sprites can get corrupted when rendering is temporarily disabled, so you have to turn rendering off and on at proper times, if you need sprites. The other reason is a PPU "feature" that causes the color being pointed by the VRAM address to be drawn on screen when rendering is disabled. This means that if you wrote new colors during the visible part of the scanline, you'd SEE little dashes of color on the screen as the writes happened, so the actual updates must still happen during hblank to prevent such glitches.

So as tepples said (and I have understood it right) it's needed one scanline to change 3 values in single palette?

That sounds about right.

Is the same situation with the attribute table values? Only 3 32x32 attribute block can be changed?

If I don't use sprites or/and scrolling does it help anyhow to increase number of changed colors or attribute block values?

So you're going to rewrite the attributes in vRAM during an IRQ so that the colors of the tiles change before they're rendered on screen?

It might be possible, since you can write to vRAM during hBlank a little, but you're not gaining anything.

You would still have to select from the sames colors you already had available.

MMC5's approach is sort of like that idea. The cart swaps into different attribute values every 8x8 tile so you get 8x8 attributes. You can't do this with IRQs. If you try to write to vRAM while it is rendering, everything goes haywire.

The only way I've reasonably found to get more colors in the playfield is to swap colors as they scroll off. This requires one full screen with 3 colors max. Changing the background color would require no tiles on screen that use the background color, so that is a bit more impractical.

greatkreator wrote:Is the same situation with the attribute table values? Only 3 32x32 attribute block can be changed?

With attributes you have a little more freedom, since you can update them during the visible part of the blank scanline. You can update around 14 bytes during one blank scanline.

If I don't use sprites or/and scrolling does it help anyhow to increase number of changed colors or attribute block values?

Not using sprites doesn't help with palette changes because there's still the "color being updated gets displayed" thing. As for scrolling, even if you're not modifying the scroll over time, the PPU is ALWAYS using the scroll for rendering, and changing the VRAM address messes with the scroll, so you absolutely have to fix it before turning rendering back on.

Change palette values per scanline in practical way

The only practical way is : Don't. Changing palette is too complicated, so it is only an interested feature for tech demoes or such where you're ready to waste a lot of CPU time to pull out nice effects that push the hardware to the limits.

Some games use a different palette for two halves of the screen, so it's not all that impractical if you don't mind a seam in the screen.
Examples: Super Off Road, Day dreamin' davey, Back to the Future...

Thanks everyone who helped!

Actually I am interested exactly in pushing the limits.

greatkreator wrote:Actually I am interested exactly in pushing the limits.

We all are! However, pushing the limits of a system like the NES is never "practical" and will always have strong constraints like using a particular mapper, or using a lot of CPU time, and writing fine-tuned timed code.