I'm not convinced you actually need to care. You'll notice that all of the 2/3 + 1/3 color mixes from the first example are closer to each other than to either of their neighbors. If you're choosing only 16 colors in the end, would you ever want two different versions of the same mix?
Pseudo-colors for low resolution graphics
Moderator: Moderators
Re: Pseudo-colors for low resolution graphics
Re: Pseudo-colors for low resolution graphics
I don't mean just the variations from the different NTSC alignments, the game also needs to look decent for people playing in PAL consoles and pixel-perfect setups. I'd have to create combinations that result in similar sets of 16 colors for all these cases, and for that to be possible I'd probably have to stick to a fixed set of 16 colors for each level, since changing the bar colors progressively would impact the pseudo-colors in different ways.
I also wonder if the 3-color patterns will still behave as desired when used in small 4x2-pixel areas, the size of a single software pixel.
I also wonder if the 3-color patterns will still behave as desired when used in small 4x2-pixel areas, the size of a single software pixel.
Re: Pseudo-colors for low resolution graphics
So proper "Telefunken" PAL-B (or PAL-N) decoding averages the chroma components of each pixel with the one exactly 64µs prior, and the PAL-B NES and Famiclones generate slightly slow scanlines, so the actual average is off by half a pixel. (In contrast, unless the PAL-N famiclone has been significantly tweaked here, it produces fairly fast scanlines - 3 pixels too short - so this chroma blending will be different.
For certain pairs of colors, bad implementations of this averaging can produce chroma-into-luma artifacts, as FrankenGraphics discovered.
But for these specific patterns, it mostly seems ok: (In gimp, I took the original image, scaled it horizontally 279% linearly and vertically 200% nearest neighbor, "decomposed" the image to YCbCr, made copies of blueness and redness and shifted them by equivalent-to-64µs (2 pixels down, 1 pixel left) and averaged them, and "recomposed" the image back to RGB.)
That's part of why I included the source images, so that you could evaluate that for yourself. But I think it's worth pointing out that these specific dither patterns will look best on NTSC ... as long as you permit the missing dot. They'll look worst (they'll flicker at 20Hz) if you disable rendering at the top of the field for more PPU bandwidth.and pixel-perfect setups.
And every other dither pattern will have more chroma fringing.
They mostly just linearly interpolated. Hence why I rearranged the first image in the way I did.I'd have to create combinations that result in similar sets of 16 colors for all these cases, and for that to be possible I'd probably have to stick to a fixed set of 16 colors for each level, since changing the bar colors progressively would impact the pseudo-colors in different ways.
Perhaps this is a more philosophical point: your thread-starting 16-color palette has 10 colors that are approximately independent, and only 4 of them are forced to come along for the ride if you change one of the primaries. In contrast, my 9-color palette uses each primary in 5 of the available hues, multiplied by however you dim things.
Now that is a good question. Do you have a mockup I could paint these patterns into so that I could throw them into nes_ntsc ? Preferably with less effort than de-dithering your GIFs in this post ?I also wonder if the 3-color patterns will still behave as desired when used in small 4x2-pixel areas, the size of a single software pixel.
Re: Pseudo-colors for low resolution graphics
Whoa, that's evil.lidnariq wrote: ↑Fri Aug 28, 2020 11:17 pmFor certain pairs of colors, bad implementations of this averaging can produce chroma-into-luma artifacts, as FrankenGraphics discovered.
I don't have any intention to mess with the dot crawl pattern, unless that helped with the color blending somehow (but from your assessment it'd actually make things worse).I think it's worth pointing out that these specific dither patterns will look best on NTSC ... as long as you permit the missing dot. They'll look worst (they'll flicker at 20Hz) if you disable rendering at the top of the field for more PPU bandwidth.
I guess this is not such a big problem after all... if the resulting palette is good, I may not even have to change it on the fly.Perhaps this is a more philosophical point: your thread-starting 16-color palette has 10 colors that are approximately independent, and only 4 of them are forced to come along for the ride if you change one of the primaries. In contrast, my 9-color palette uses each primary in 5 of the available hues, multiplied by however you dim things.
Here are a few shots at the correct resolution and flattened colors, but since this whole 16-color thing is somewhat new, all textures are still 2 colors, so there won't be many busy areas with different colors near each other...Do you have a mockup I could paint these patterns into so that I could throw them into nes_ntsc ? Preferably with less effort than de-dithering your GIFs in this post ?
There's this other project which has nothing to do with the NES but uses the same pixel size I do, so maybe these would be good for testing? I already did some color reduction on these, so the color count would be closer to what I can do on the NES, but I'm not committing to any particular palette here:
Re: Pseudo-colors for low resolution graphics
I have been trying to fit these 3x3 patterns in the space occupied by my software pixels, but it's not going well. It would be possible if I was generating the patterns on the fly, but one of the biggest performance optimizations in my engine is the use of pre-defined patterns, so I definitely can't sacrifice that.
Each software pixel is 4x2 hardware pixels, but since each tile is 8 pixels wide, and I manipulate the vertical scroll every 4 scanlines, the color patterns could actually repeat every 8x4 hardware pixels. Still not multiples of 3, so this probably isn't of much help.
Each software pixel is 4x2 hardware pixels, but since each tile is 8 pixels wide, and I manipulate the vertical scroll every 4 scanlines, the color patterns could actually repeat every 8x4 hardware pixels. Still not multiples of 3, so this probably isn't of much help.
Re: Pseudo-colors for low resolution graphics
3's primeness is awfully inconvenient.
Is their any chance you can make any change painting these macropixels with different patterns from one column or one row to the next?
Dithering these colors from row $2x with black is posing a problem:
Is their any chance you can make any change painting these macropixels with different patterns from one column or one row to the next?
Dithering these colors from row $2x with black is posing a problem: