use yuv overlay instead of rgb for rendering?

use yuv overlay instead of rgb for rendering?
by mattmatteh on 2007-09-04 (#26711)

i am working on re coding my ppu and have been reading and thinking of how to do it. i think i know how i want to code it but stuck on how to efficiently handle emphasis and monochrome. i have never used overlay before and not sure i fully understand it. but since the nes is ntsc or pal, not rgb, has anyone tried to use yuv overlay ? for example, sdl has overlay support. would this be easier to use for correct emulation and perhaps emphasis and monochrome handling ? i would assume that most graphics cards would have this in hardware and perhaps software for non full screen such as linux.

any ideas ?

matt

Re: use yuv overlay instead of rgb for rendering?
by Disch on 2007-09-04 (#26712)

I don't know about YUV... but:

mattmatteh wrote:

i think i know how i want to code it but stuck on how to efficiently handle emphasis and monochrome.

I keep a 512 entry lookup table that has the output colors in RGB format. The first 64 represent the NES palette with no emphasis, which would be filled by the loading of whatever .pal file. The remaining 7 sets of 64 each represent a different color emphasis mode and are calculated once based on the first 64 colors.

Monochrome can be handled very easily by applying a mask to the color prior to the lookup in the above table. A mask of $3F would be full color, and $30 would be monochrome mode. And in fact... I believe this is actually more or less how monochrome works on the system.

My output looks something like:

Code:

output_pixel = rgb_output_lut[ emphasis_bits | ( nes_color & monochrome_mask ) ];

where 'nes_color' is the desired color ($0F = black, etc), and 'monochrome_mask' is either $3F or $30.

emphasis_bits would be the bits as written to $2001, left shift 1 (0x01C0)

EDIT
------------

An optimization I just thought of....

To avoid the additional AND operation for each pixel... you could keep two seperate buffers for the palette at $3F00. One which has the colors as written (full color mode), and one which has the same entries but pre-masked with $30 (for monochrome mode). When the game switches between color/monochrome modes, you can simply adjust a pointer which points to which buffer the PPU is to use.

This of course would require you to maintain two buffers and keep them updated as the game writes to $3F00, but palette writes occur far less often than pixels are output.

To avoid the emphasis OR, you could just use a pointer to the lut instead of looking up the LUT directly. Update the pointer when the game changes emphasis.

by mattmatteh on 2007-09-04 (#26713)

that is what i am doing now. but i am working a caching tiles, sprites, background, and foreground. i can those cached as 8bit with a palette look up or 24 bit rgb. the palette look up will be easy, but the 24 bit rgb will need to be redrawn.

as to the topic, i was wondering if anyone has done that. perhaps i could let the overlay do that, or perhaps it can not. i have never used an over lay before and have seen many post about ntsc atrifacts and correct rendering from rgb; perhaps draw closer to ntcs from the beginning?

matt