Basic fade in or out of a palette

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Basic fade in or out of a palette

Post by lidnariq »

Because for some reason, I haven't seen anyone else explicitly mention this ...

You could just have a set of lookup tables for each of the 4 steps of a fade.
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: Basic fade in or out of a palette

Post by FrankenGraphics »

re: tepples, buffer.

Yeah, i think it is sound to prepare a buffer in ZP (if you can afford it - has someone actually topped out on zp?) or elseplace in RAM, for the Vblank period to pick up in case of a pending update, much like OAM. It also means you can can manipulate your buffer however you want.
Someone asked for a colour cycler on NESmakers.com, i made this little thing, which relies on having a buffer:

Code: Select all

PickPaletteToCycle:
;notice -- this routine will clobber anything that is in registers a, x and y. If something in a,x or y needs to be stored for later use, do so before calling this routine.
lda #0 ; you can replace this with another literal, or a variable if you wish (expected values 0-7. Don't go higher or you'll run into some other RAM section)
asl a
asl a ;these multiply your literal or variable with 4 so we can get the right offset for each palette in increments of 4.
tax
CyclePaletteRightOnce:
ldy PalDataInRAM+3,x ;pocket colour 3 in reg y
lda PalDataInRAM+2,x 
sta PalDataInRAM+3,x ;move colour 2 to 3
lda PalDataInRAM+1,x 
sta PalDataInRAM+2,x ;move colour 1 to 2 
sty PalDataInRAM+1,x ;move pocket (y) to 1
rts
(For NM* specifically though, PalDataInRAM is actually double the size as it stores 16 subpalettes in a buffer. 0-7(*4) is 2 full sets for background palettes, 8-15(*4) is the same for sprites. 0-3 seems derived from 4-7, and respectively so in the sprite region.

*NESmaker has different labels.
pending variable = updatePalettes
PalDataInRAM = bckPal
Also note that only 4-7 and 12-15 will actually get uploaded this way via its NMI palette uploader. This will not likely be the case when using the code snippet in your own engine, though.
Last edited by FrankenGraphics on Fri Aug 31, 2018 10:14 am, edited 5 times in total.
User avatar
Banshaku
Posts: 2417
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

Re: Basic fade in or out of a palette

Post by Banshaku »

@lidnariq

After everyone comment, since 4 steps seems the most common, yes, a lookup table could actually do the job. I know I'm using one to rotate the palette during gameplay so to fade in/out for an introduction would be a very easy way to do it. This way the palette is defined by hand for that specific fade.

I will keep that in mind if programmatic ones are not reacting properly. Thanks!
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: Basic fade in or out of a palette

Post by koitsu »

lidnariq wrote:Because for some reason, I haven't seen anyone else explicitly mention this ...

You could just have a set of lookup tables for each of the 4 steps of a fade.
I did cover it in my post. :-)
User avatar
DRW
Posts: 2225
Joined: Sat Sep 07, 2013 2:59 pm

Re: Basic fade in or out of a palette

Post by DRW »

FrankenGraphics wrote:
DRW wrote:The $0D problem shouldn't be an issue because there's really no reason to use the gray colors in the $xD column in the first place. The shades in $x0 are pretty much identical.
This seems to be a fairly widespread notion, but fortunately for us artists, it's actually not true. I think the idea of them being close to the same has gotten popularized because, for some reason, fceux doesn't make a distinction between $00 and $2d, so $2d looks way too bright.
But independently from the question how close they look to each other, isn't it true that basically no game uses the gray colors in the D column, except for a handful of obscure ones?

As far as I remember, there are some issues with them, not only color $0D, but also the other ones. Something about the possibility that they might be rendered as black instead of gray or something like that.

The fact alone that basically no major NES game ever uses the colors in the D column would be reason enough for me to ban them from any of my games.
My game "City Trouble":
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Basic fade in or out of a palette

Post by lidnariq »

Not only did plenty of games use the $xD hues, but in fact, plenty games even used the problematic color $0D. This has come up enough times before that we felt the need to make a page on the wiki about it.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Basic fade in or out of a palette

Post by rainwarrior »

Just FYI, adding that special case for $0D to the example code I linked in my earlier post is just another 4 bytes:

Code: Select all

fade_apply_:
	; in: A = value to subtract from palette, copying from nmt_buffer
	@sub = temp+0
	sta @sub
	ldx #32
	@loop:
		lda nmt_buffer+31, X
		sec
		sbc @sub
		bcs :++
		:
			lda #$0F
		:
		cmp #$0D
		beq :--
		sta palette-1, X
		dex
		bne @loop
	rts
I mean, you could also solve this with tables, but this is a lot more compact. (Also maybe takes an extra ~125 cycles but your fade frames are probably not CPU intensive to begin with.)

With tables you could easily redefine the steps arbitrarily (e.g. $30 > $10 > $00 > $2D > $0F) but it costs a bit of ROM space. You can also do more than 4 steps with tables (the harder question is what colours to use for those extra steps). Another alternative for a slow fade would be to flicker back and forth between steps to represent a blend between them. You can also try to use emphasis bits, turning on all 3 darkens everything a bit (though will white out the screen on an RGB PPU).

Hue shifts are also very fun and easy. Colours from $X1 to $XC can just be rotated to the next colour. Maybe doesn't really fit the bill of a "fade" but might add some extra animation to the fade mechanism just by having some more visible steps.


In my own use, I usually just want very quick fades. 4 frames is plenty to smooth off the feeling of suddenly cutting to black, and allows the user to get on with things quickly.
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: Basic fade in or out of a palette

Post by FrankenGraphics »

@DRW

In addition to lidnariqs' confirmation that it was used, here's where the $xD colours can be problematic:

-playchoice10 (arcade machine)
-vs. system (arcade machine)
-famicom titler (obscure commodity in japan which had the famicom hardware bundled into a movie subtitle imprinting machine.)
-i think there was one more obscure licensed commodity in japan that used this.
-people who've modified their NES:es to use a PPU from one of the above, for example a pretty invasive RGB mod that surfaced some years ago and then faded into obscurity which iirc used donors from the above?

These systems will show black instead of the two gray tones. I think i read on the wiki this was intended by nintendo as a form of copy protection.

notice that the arcade boards use a quite different palette to begin with - much brighter. And they include a vivid yellow and some other clear base colours not present on the NES/famicom.

I'll link to the discussion we've had on this recently tomorrow. But anyway - $2d and $3d is within NES and famicom specs and were used. Arcade machines and PPU swap mods are not.
(It is nice to include a compatibility mode, or in lieu of that, at least note somewhere that it won't look quite as intended on playchoice etc).
Last edited by FrankenGraphics on Fri Aug 31, 2018 2:21 pm, edited 1 time in total.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Basic fade in or out of a palette

Post by rainwarrior »

FrankenGraphics wrote:These systems will show black instead of the two gray tones. I think i read on the wiki this was intended by nintendo as a form of copy protection.
There were a few different playchoice Vs. System versions that had basically scrambled the order of colours in the palette. That was the copy protection. (This is only important if you want to put your game into a Playchoice 10 Vs. System machine though.)

The two greys were omitted from the one that didn't have this copy protection, actually. I think they were just left out because Nintendo didn't really use them for their games anyway (I think the $D column was an accident of design?). That's the version of RGB PPU that shows up in NES mods though, since it's otherwise compatible (excepting the emphasis problem).

It's all described here, I think: https://wiki.nesdev.com/w/index.php/PPU_palettes
Last edited by rainwarrior on Fri Aug 31, 2018 2:59 pm, edited 3 times in total.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Basic fade in or out of a palette

Post by lidnariq »

rainwarrior wrote:There were a few different playchoice versions that had basically scrambled the order of colours in the palette. That was the copy protection. (This is only important if you want to put your game into a Playchoice 10 machine though.)
Vs. System. Not Playchoice.

Specifics are definitely rather immaterial, though; either way they're arcade machines of which many orders of magnitude fewer were made.
User avatar
DRW
Posts: 2225
Joined: Sat Sep 07, 2013 2:59 pm

Re: Basic fade in or out of a palette

Post by DRW »

FrankenGraphics wrote:But anyway - $2d and $3d is within NES and famicom specs and were used.
Yeah, but I personally would still omit the D column completely.

Even if those colors were used, they were used rarely. And I don't know of any game by Nintendo itself where these colors were ever used at all.

Also, the fact that the dangerous black is in this very column shows me that the D column seems to be more of a curiosity and not a regular choice of colors.
My game "City Trouble":
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
User avatar
Banshaku
Posts: 2417
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

Re: Basic fade in or out of a palette

Post by Banshaku »

What came out of that thread is that I should be careful with that column of color once I work on the actual project :lol: For now I do not have original assets so I don't think they are using those color. I will confirm, just in case.

My goal is mostly a quick fade and once the colors are all black, I need to load the next image/text that will be shown during that state.

One thing I will need to check is for reloading new text, if I use the example in C from Shiru (which at first was not planing to) could be more then enough actually. I just don't know if there is something I need to be careful while disabling the screen for writing the new text, if the displayed image will be affected in some way. But I guess this is the subject of another thread if some problem occurs because I haven't made that part yet ^^;;
User avatar
DRW
Posts: 2225
Joined: Sat Sep 07, 2013 2:59 pm

Re: Basic fade in or out of a palette

Post by DRW »

One more thing that you should keep in mind: Once all the colors are black, you still need to disable rendering, so that you can write to the PPU outside of vblank.
My game "City Trouble":
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Basic fade in or out of a palette

Post by tokumaru »

Or you can keep rendering on at all times, even during screen transitions, and keep using the NMI handler for VRAM updates. That may seem inefficient, but if you already have a full VRAM update system in place, you might as well use it all the time, even when the screen is blank, and save some time by not writing new update functions.

Even if you draw the background one column or row per frame, making use of your existing scrolling engine's functions, it'll take significantly less than 1 second to redraw the entire background. In most cases, that's perfectly appropriate.

There are cases when you'd want lightning fast VRAM updates though, like in a multi-screen action game with no scrolling... if you're running and jumping through different screens, you'll want the switch to happen as quickly as possible, or the experience might be frustrating to the players.
User avatar
Banshaku
Posts: 2417
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

Re: Basic fade in or out of a palette

Post by Banshaku »

Right now the current place where screens are updated during fade is for the story itself. When text is faded out, you may need to update the text or fade the background then update both.

Since my engine allows to change at any time the NMI with a custom routine, I could update the NMI for that specific state or even update many time during the state when different rendering is necessary. I will try at first to do it without such code and just in C with some code in a library, neslib like. If there is some artifact then I will just figure out something in the NMI and update during vblank.
Post Reply