Change palette values per scanline in practical way

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems.

Moderator: Moderators

User avatar
greatkreator
Posts: 49
Joined: Wed Dec 09, 2015 2:18 pm

Change palette values per scanline in practical way

Post by greatkreator » Wed Jan 27, 2016 9:52 pm

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)?

lidnariq
Posts: 9494
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Change palette values per scanline in practical way

Post by lidnariq » Wed Jan 27, 2016 9:58 pm

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

tepples
Posts: 22014
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Change palette values per scanline in practical way

Post by tepples » Wed Jan 27, 2016 10:00 pm

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.

User avatar
greatkreator
Posts: 49
Joined: Wed Dec 09, 2015 2:18 pm

Re: Change palette values per scanline in practical way

Post by greatkreator » Wed Jan 27, 2016 10:14 pm

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?

lidnariq
Posts: 9494
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Change palette values per scanline in practical way

Post by lidnariq » Wed Jan 27, 2016 10:21 pm

You should be looking at this Indiana Jones title screen.

User avatar
tokumaru
Posts: 11744
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Change palette values per scanline in practical way

Post by tokumaru » Wed Jan 27, 2016 10:26 pm

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.

User avatar
greatkreator
Posts: 49
Joined: Wed Dec 09, 2015 2:18 pm

Re: Change palette values per scanline in practical way

Post by greatkreator » Wed Jan 27, 2016 10:35 pm

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?

User avatar
tokumaru
Posts: 11744
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Change palette values per scanline in practical way

Post by tokumaru » Wed Jan 27, 2016 10:46 pm

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.

User avatar
greatkreator
Posts: 49
Joined: Wed Dec 09, 2015 2:18 pm

Re: Change palette values per scanline in practical way

Post by greatkreator » Wed Jan 27, 2016 11:01 pm

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?

User avatar
darryl.revok
Posts: 520
Joined: Sat Jul 25, 2015 1:22 pm

Re: Change palette values per scanline in practical way

Post by darryl.revok » Wed Jan 27, 2016 11:47 pm

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.

User avatar
tokumaru
Posts: 11744
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Change palette values per scanline in practical way

Post by tokumaru » Wed Jan 27, 2016 11:53 pm

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.

User avatar
Bregalad
Posts: 7889
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Re: Change palette values per scanline in practical way

Post by Bregalad » Thu Jan 28, 2016 2:05 am

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.

User avatar
Dwedit
Posts: 4328
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: Change palette values per scanline in practical way

Post by Dwedit » Thu Jan 28, 2016 8:08 am

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...
Last edited by Dwedit on Thu Jan 28, 2016 8:15 am, edited 1 time in total.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!

User avatar
greatkreator
Posts: 49
Joined: Wed Dec 09, 2015 2:18 pm

Re: Change palette values per scanline in practical way

Post by greatkreator » Thu Jan 28, 2016 8:11 am

Thanks everyone who helped!

Actually I am interested exactly in pushing the limits.

User avatar
Bregalad
Posts: 7889
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Re: Change palette values per scanline in practical way

Post by Bregalad » Thu Jan 28, 2016 3:17 pm

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.

Post Reply