Pseudo-colors for low resolution graphics

A place for your artistic side. Discuss techniques and tools for pixel art on the NES, GBC, or similar platforms.

Moderator: Moderators

lidnariq
Posts: 9659
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Pseudo-colors for low resolution graphics

Post by lidnariq » Fri Aug 28, 2020 7:47 pm

tokumaru wrote:
Fri Aug 28, 2020 7:31 pm
I guess you could have a screen asking the player to "select the square that contains the picture of a specific object with a specific color", but that's a really weird thing to include in a game
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?

User avatar
tokumaru
Posts: 11858
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Pseudo-colors for low resolution graphics

Post by tokumaru » Fri Aug 28, 2020 9:21 pm

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.

lidnariq
Posts: 9659
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Pseudo-colors for low resolution graphics

Post by lidnariq » Fri Aug 28, 2020 11:17 pm

tokumaru wrote:
Fri Aug 28, 2020 9:21 pm
the game also needs to look decent for people playing in PAL consoles
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:
nes-pseudo-colors-3-pal.png
(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.)
and pixel-perfect setups.
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 every other dither pattern will have more chroma fringing.
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.
They mostly just linearly interpolated. Hence why I rearranged the first image in the way I did.

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.
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.
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 ?

User avatar
tokumaru
Posts: 11858
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Pseudo-colors for low resolution graphics

Post by tokumaru » Sat Aug 29, 2020 12:33 am

lidnariq wrote:
Fri Aug 28, 2020 11:17 pm
For certain pairs of colors, bad implementations of this averaging can produce chroma-into-luma artifacts, as FrankenGraphics discovered.
Whoa, that's evil.
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 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).
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.
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.
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 ?
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...

raycaster-01.png
raycaster-01.png (799 Bytes) Viewed 589 times
raycaster-02.png
raycaster-02.png (756 Bytes) Viewed 589 times
raycaster-03.png
raycaster-03.png (848 Bytes) Viewed 589 times

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:

project-m-01.png
project-m-01.png (1.51 KiB) Viewed 589 times
project-m-02.png
project-m-02.png (1.46 KiB) Viewed 589 times

User avatar
tokumaru
Posts: 11858
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Pseudo-colors for low resolution graphics

Post by tokumaru » Mon Aug 31, 2020 12:06 am

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.

lidnariq
Posts: 9659
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Pseudo-colors for low resolution graphics

Post by lidnariq » Mon Aug 31, 2020 12:27 am

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:
Attachments
faked chroma blending (PAL-B)
faked chroma blending (PAL-B)
ntsc artifacts
ntsc artifacts
exact pixels
exact pixels
raycaster-03-dither.png (2.73 KiB) Viewed 489 times

Post Reply