If we set the Red bit so that the screen becomes more red (BGR 001), according to NinTech.txt, becomes 123.9% (23.9 'more red'). If the colour being drawn to the screen is white (0x00FFFFFF) does the red value (0xFF) remain the same or wrap? (Therefore is 0xFF the maximum the colour can be increased to).
Also are there any demos in which to test the bits?
The "emphasize red" bit darkens blue and green and lightens red. Likewise for the "emphasize green" and "emphasize blue" bits. If you turn on all three bits, you darken the whole screen.
No, nothing wraps. The emphasis is said to be done in analog circuitry, which tends to saturate rather than wrap.
Only commercial game I know of to test is Final Fantasy, which cycles through emphasis modes to create the flashy effect when you get into a battle.
Didn't Dragon Warrior 2 also use it?
And Super Spy Hunter, when you pause the game the screen goes darker.
And that Dizzy game with the scroll in the beginning.
Just Breed have all emphasis bits always set, to have darker graphics. What do you think is the best ? Have all bits set for darker graphics, and clear them to do lightening effects (Just Breed) or having them clear, and set them to do lightening effects (Final Fantasy 1, 2).
The only FF game I have running on my real NES is the second (thanks to drk414), and I think the effects is way to fast to notice how the color varies. However, it's not very different from an emulator such as FCEUltra.
The attribute bits also darken blacks closer to the level of NTSC's "blacker than black" synchronization signals. If you set all the attribute bits, some older TVs might not find the sync signals.
Try doing lighting effects by adding or subtracting $10 from each palette entry, clipping negative values to $0F and positive values to $30.
I'm sure that Just Breed does this, even with the black color (probably $0f). The problem, is whith doing effects only by software, it's impossible to get some intermediate colors. I always ask myself how looks the color $1d on a real screen. It should be the darker gray available on the NES palette, but all games seems to rely to $00-$30 to do gray and never to $1d-$3d (because $0d shouldn't used on a NTSC TV). I think that if could be good to use $1d for black sprites and $0f for black BG, so a black sprite on a black BG would still be visible. However, all emulators emulates $1d pretty much differently from nearly as grey than $00, to as black than $0f, and I don't know how looks the real one, nor any game using this color.
Quietust's copper.nes also uses the CI bits rather well.
001 B: 074.3% G: 091.5% R: 123.9%
010 B: 088.2% G: 108.6% R: 079.4%
011 B: 065.3% G: 098.0% R: 101.9%
100 B: 127.7% G: 102.6% R: 090.5%
101 B: 097.9% G: 090.8% R: 102.3%
110 B: 100.1% G: 098.7% R: 074.1%
111 B: 075.0% G: 075.0% R: 075.0%
How accurate are those figures? Is it the same for NTSC/PAL? Can anyone improve on them? Or are they like the palette on every console (i.e. different all the time).
WedNESday wrote:
Implementing the intensity is tricky though, and if done incorrectly is very CPU intensive.
Not really - just calculate all palette values in all emphasis modes (512 colors total, can be calculated at palette load time) and look up the proper one at rendering time.
That's exactly what I do.
My output looks kind of like this:
Code:
pixeltooutput = nOutputPalette[ nEmphasis | (nPalette[ out ] & nMonoMask) ];
'nOutputPalette' being the precaculated RGB table (DWORDs if outputting 32-bit color, WORD if outputting 16-bit). 512 entries (64 colors * 8 emphasis modes)
'nEmphasis' are the emphasis bits are written to the register, masked out and left shifted one (nEmphasis = 0x1C0 if all 3 emphasis bits set)
'nPalette' is the NES palette as it exists at ppu$3Fxx
'out' is the bg/sprite pixel to output
'nMonoMask' will always either be 0x3F (normal) or 0x30 (in monochrome mode)
yaya, that's it. ^_^;;
if the guy is using an 8-bit mode, then... he should switch to 16-bit video mode...
Quietust's copper.nes also uses the CI bits rather well.
001 B: 074.3% G: 091.5% R: 123.9%
010 B: 088.2% G: 108.6% R: 079.4%
011 B: 065.3% G: 098.0% R: 101.9%
100 B: 127.7% G: 102.6% R: 090.5%
101 B: 097.9% G: 090.8% R: 102.3%
110 B: 100.1% G: 098.7% R: 074.1%
111 B: 075.0% G: 075.0% R: 075.0%
How accurate are those figures? Is it the same for NTSC/PAL? Can anyone improve on them? Or are they like the palette on every console (i.e. different all the time).
Actually, Quietust posted a new measurement on this forum a few weeks ago, but I can't find the thread..
Code:
/* emphasis factors, %000 to %111. r,g,b */
/* measurement by Quietust */
const float emphasis_factor[8][3]={
{1.00, 1.00, 1.00},
{1.00, 0.80, 0.81},
{0.78, 0.94, 0.66},
{0.79, 0.77, 0.63},
{0.82, 0.83, 1.12},
{0.81, 0.71, 0.87},
{0.68, 0.79, 0.79},
{0.70, 0.70, 0.70}
};
NTSC/PAL difference ? dunno
hap wrote:
Actually, Quietust posted a new measurement on this forum a few weeks ago, but I can't find the thread..
I deleted the thread after somebody made a post questioning the purpose of measuring colour emphasis in terms of RGB adjustment when the NTSC PPU has no RGB logic inside it whatsoever - apparently, after the "NTSC emulation" showed up, people only want to know exactly how colour emphasis modifies the NTSC signal itself and don't care about such RGB adjustment hacks.
Thanks a lot. But this poses another problem. Which one to use!?!? lol
Quietust wrote:
hap wrote:
Actually, Quietust posted a new measurement on this forum a few weeks ago, but I can't find the thread..
I deleted the thread after somebody made a post questioning the purpose of measuring colour emphasis in terms of RGB adjustment when the NTSC PPU has no RGB logic inside it whatsoever - apparently, after the "NTSC emulation" showed up, people only want to know exactly how colour emphasis modifies the NTSC signal itself and don't care about such RGB adjustment hacks.
We definitely need to know how the CI bits affect the RGB values as we have them in our emulators. Obviously, the NES does not work in RGB mode but we use the equivalent.
Actually, wouldn't it be better to know how the CI bits affect the composite signal?
tepples wrote:
Actually, wouldn't it be better to know how the CI bits affect the composite signal?
Yeah, that's what I meant (as opposed to how it affects the final RGB values).
Quietust wrote:
apparently, after the "NTSC emulation" showed up, people only want to know exactly how colour emphasis modifies the NTSC signal itself and don't care about such RGB adjustment hacks.
This is not just a matter of theoretical correctness--given that the color emphasis bits operate on a composite video signal, they will not have the same RGB effect on every NES color. That's why previous attempts to determine the color emphasis effects in terms of RGB proportions have produced (very) inconsistent results.
Even if you aren't doing "NTSC emulation", it might be best to understand the emphasis in the component (YUV) domain, and then use the same YUV-to-RGB transformation that you use for your emulator's current NTSC palette generator.