nesdev.org

An old topic for reference:
http://nesdev.com/bbs/viewtopic.php?t=5165

I'm trying to make the screen fade in and out for transitions but thought I should ask here to see how other people handle this first.

Is this commonly done through palette manipulation?

If by fading you literally mean "fade from colour X to black", literally the only choice you have is changing colour indexes in the palette. Unlike the SNES, the NES doesn't have a screen brightness register.

It does have the "darken the screen slightly" feature though. You can use that inside a palette fade for twice as many levels. It probably fails on a Playchoice 10.

Since I started that thread, the method I ended up using was this:

I keep a copy of the unaltered palette in RAM, and I have a table in ROM specifying how the brightness and the hue should be affected for each "virtual screen brightness level". Then whenever the screen brightness changes I calculate a modified palette based on the original one by changing the hue and brightness of each color according to the table, clipping as necessary.

Of course you could do like most games did and just change the brightness every step, but adding the hue into the mix makes the fading much smoother (i.e. as the screen darkens, make the palette bluer, as it brightens, make it yellower).

Using this scheme I had a decision to make: I could either modify the colors during the frame and buffer the modified palette to quickly write it to VRAM during VBlank or I could use more VBlank time and modify the colors on the fly. I ended up deciding on modifying them on the fly in VBlank, which was harder to do because the code had to be very optimized and constant-timed. In other projects I could have decided to just buffer the modified palette.

Either way I think it's a good idea to keep the original palette untouched, because this way you can keep doing palette cycling effects and things like that without screwing up the brightness because you're fading in or out.

EDIT: At one point I considered doing what Dwedit said, alternating between decreasing a unit of brightness from the colors and activating all the color emphasis bits. Theoretically that would double the smoothness of the fading sequence, but I guess I gave up on the idea because it seems the color emphasis bits don't work as expected on some RGB PPUs or something. Also the fading would probably look weird in case I used the emphasis bits for something else, like water.

The cheap way is to subtract $10 until you get to $0x for the entry. But yeah, every program that I write always keeps the palette in RAM, and always copies it to the PPU on every NMI (because checking to skip it just adds more time overall). A lot of commercial games seem to do that too, even if they apparently don't do palette cycling.

Memblers wrote:every program that I write always keeps the palette in RAM, and always copies it to the PPU on every NMI (because checking to skip it just adds more time overall). A lot of commercial games seem to do that too, even if they apparently don't do palette cycling.

Lately, I tend to use 32-byte uploads in a transfer buffer in $0100-$019F. The NMI handler sees no difference between a palette update and a pair of CHR RAM tiles or a nametable row, except they have different destination VRAM addresses.

tepples wrote:Lately, I tend to use 32-byte uploads in a transfer buffer in $0100-$019F. The NMI handler sees no difference between a palette update and a pair of CHR RAM tiles or a nametable row

The problem with that is that when your horizontal scroll is not perfectly aligned to a tile you need to update at least 33 tiles when scrolling vertically (unless you are masking the leftmost 8 pixels of the screen). And when scrolling horizontally you have to update 30 tiles. So I don't think you can do everything in 32-byte blocks.

The NMI handler sees no difference between a palette update and a pair of CHR RAM tiles or a nametable row, except they have different destination VRAM addresses.

At first I used separate buffers, but then I implemented a system like this to simplify/shorten the NMI routine. I still have another separate palette entry in RAM, that is copied to the update buffer whenever an update is needed.

I keep a copy of the unaltered palette in RAM, and I have a table in ROM specifying how the brightness and the hue should be affected for each "virtual screen brightness level". Then whenever the screen brightness changes I calculate a modified palette based on the original one by changing the hue and brightness of each color according to the table, clipping as necessary.

I can understand your efforts in order to improve the fading, but personally I wouldn't do something like this, because the NES palette is somewhat partially defined / unstable. Many emulators use different palettes, so looking better on one system (be it an emulator or a real NES hooked to a real TV) might make it look worse on another system (another emulator / or another NES hooked to another TV).
Also, people have different sensitives about colors. I'm pretty sure people with blue, brown or dark eyes don't perceive colors the same way, so have hue shifts in some order might look better to your eyes, but look worse to someone with different eyes. There is people who are color-blind too.
All this to say you are guaranteed that just substrating $10 is a stable method. Maybe yours is amazing, but somehow I'm not so sure.

If this really isn't smooth, maybe you could turn on all color emphasis, then turn it off and substracti $10, then turn it on agan etc... to get a smoother fade. However it might not look good on all color, especially the bright ones...

Bregalad wrote:Also, people have different sensitives about colors. I'm pretty sure people with blue, brown or dark eyes don't perceive colors the same way, so have hue shifts in some order might look better to your eyes, but look worse to someone with different eyes.

What makes you think that the color of one's iris [1] has any effect on the ability of the cones [2] to detect color differences? If you are aware of any actual research papers, I would find that interesting.

However, I did find an article [3] (many, actually) stating that eye color affects light sensitivity, but nothing about eye color affecting color sensitivity.


[1] http://en.wikipedia.org/wiki/Eye_color
[2] http://en.wikipedia.org/wiki/Cone_cell
[3] http://www.nytimes.com/2009/01/20/healt ... .html?_r=1

Bregalad wrote:I'm pretty sure people with blue, brown or dark eyes don't perceive colors the same way, so have hue shifts in some order might look better to your eyes, but look worse to someone with different eyes.

I'm no doctor, but I'm pretty sure that eye color has nothing to do with how people perceive colors... I do agree that there probably is some variance from people to people, but the iris just surrounds the hole through where light goes into the eye, so its color doesn't matter because no light goes through it. When I had laser eye surgery to fix my sight they cut my cornea open with a circular blade. If I could see anything in that area, I would certainly see a scar, which I don't. Light only enters your eye through the small opening at the center.

There is people who are color-blind too.

They have more important things to worry about, like red and green lights when they are driving, than the fading routines of my game. =)

But seriously, if a person is color blind, I bet they are less likely to notice slight hue shifts than people with normal sight (seeing as they have less color sensors), so the worst that could happen is that it would look more like a traditional brightness-only fade to them.

Maybe yours is amazing, but somehow I'm not so sure.

Come on, don't you think the fading in this game looks amazing for a system with only 64 colors? Insanely better than anything on the NES IMO.

Several Genesis/MD and SMS games faded like this, and this is somewhat easier to program if the system's palette is RGB (as is the case with these 2 consoles), since you can just modify each of the color components at different rates and times. But it's not so hard on systems like the NES or the Atari 2600, you just have to visualize the palette as a color circle, and move the colors towards blue or yellow at the same time as you make them darker. It looks great IMO.

If this really isn't smooth, maybe you could turn on all color emphasis, then turn it off and substracti $10, then turn it on agan etc... to get a smoother fade.

That's what Dwedit suggested... I haven't tried coding that, but I do believe it would appear to flicker a bit.

Well I don't have any sources
I just remember that I was told that eye color affected vision. That should be something extremely difficult to test though, as anyone is used to it's own vision and can't test anyone else's eyes. Maybe I see blue the way someone else see red and vice versa, and since we had that since our birth, nobody even knowns this.
Only those extremely rare people that have two eyes of different colors could confirm if they see colors differently with one eye than another. But I'm not one of them.

They have more important things to worry about, like red and green lights when they are driving, than the fading routines of my game. =)

The position of the lights usually defines if they are green or red, with rare exceptions.

But seriously, if a person is color blind, I bet they are less likely to notice slight hue shifts than people with normal sight (seeing as they have less color sensors), so the worst that could happen is that it would look more like a traditional brightness-only fade to them.

You're probably right on this one. Although it's all theorical.
Just to say we usually don't think that some people can be handicapped, but can still play games. (for example a handicaped persone who have no arms isn't going to play your game). But people who has no audition, or that is color blind, are still going to play games, and the developers doesn't always think about them which isn't nice. I'm getting out-of-topic here anyways, as as you said color blind probably plays no role in this.

Bregalad wrote:Only those extremely rare people that have two eyes of different colors could confirm if they see colors differently with one eye than another.

I do see a bit differently with each eye... One sees slightly bluer and the other slightly redder, but that's very hard to notice. The lighting has to be right and I must be looking at a white object.

I don't think it varies so much from people to people to the point of the same color appearing red to a person and blue to the other. Colors have known wavelengths, and I believe it's possible to tell which cones are stimulated by which wavelengths, so it should be possible to predict what kind of information is being sent to the brain.

Well to be honest I never understood this wavelenght thing.

To me, the wavelength model of colors is a total contradiction with the color circle model. There is no way both can exist and be "true", as the wavelength model doesn't loop on himself like the color circle does. This have been a major question I've been asking to myself for years and never got any answer.

http://en.wikipedia.org/wiki/CIE_1931_color_space

I think the key to understanding why the color "wheel" is a circle, yet why real light is based on wavelength is this paragraph in the above Wikipedia article:

Two light sources, made up of different mixtures of various wavelengths, may appear to be the same color; this effect is called metamerism. Two light sources have the same apparent color to an observer when they have the same tristimulus values, no matter what spectral distributions of light were used to produce them.

Additional edit: This might also be helpful:
http://en.wikipedia.org/wiki/Line_of_purples

Bregalad wrote:To me, the wavelength model of colors is a total contradiction with the color circle model. There is no way both can exist and be "true", as the wavelength model doesn't loop on himself like the color circle does.

Between the eye and the brain, the signal from the cones is converted to a color space much like YUV through an opponent process. So the eye sees along the lightness axis, the red-green axis (V), and the blue-yellow axis (U). Men with no red cones or no green cones see only blue-yellow distinctions.

The line of purples from blue to red on the chromaticity diagram represents what happens when U is blue and V is red. Red cones are slightly sensitive to blue light, which is why both a blue+red mixture and the blue at the bottom of a rainbow appear violet.