PPU and horizontal color blending

I have a quick (hopefully!) question for those of you who actually understand how the NES encodes its video signal ('cause I sure don't): if I draw a pattern of vertical stripes using one color for even-numbered columns and another for odd-numbered columns, is the perceived result roughly the same regardless of which color is odd and which is even? In other words, does a red-blue-red-blue pattern look as violet as a blue-red-blue-red pattern? Assuming the scroll doesn't change, if that matters.

I'm asking this because I am working on something that mixes colors like this, but also allocates colors dynamically, so there are no guarantees that the colors of a 2-color pattern will always be allocated in the same order, meaning that every time you run into a particular pattern it may or may not have its colors reversed compared to when you last saw it. I don't mind it looking a little different, but it has to be the same overall hue.

A quick test with blargg's NTSC filters suggests that switching the order of the colors has little to no impact on the final perceived color (I do see a slight shift in the artifact diagonal lines that are formed, but that's OK), but it would be nice to know if anyone here knows anything relevant that I don't, and what to expect on PAL consoles. Thanks.

The artifact patterns are in groups of 3 pixels, and the offset of that grouping shifts by 1 each scanline.

I made this ROM to demonstrate the patterns and groupings: NTSC pattern torture test

e.g. If you make a 3 pixel pattern and shift it 1 pixel to the right each line, it will produce the same colours on each line.


If you simply alternate columns in 2 column groups like you're suggesting, you'll get a 3 line pattern that repeats, and reversing the order will give the same 3 line pattern just starting from a different phase (i.e. shifted up or down 2 pixels). The actual starting phase of the PPU in this respect is random on reset (there are 6 possible phases).

The reason why is sort of outlined here:
https://wiki.nesdev.com/w/index.php/NTSC_video#Color_Phases

I understand it as the way it generates colour takes 12 clocks to complete a cycle that will properly define the hue, but each pixel only lasts 8 clocks. So for any pixels that aren't adjacent to the same colour you get an interrupted cycle, some hue from one pixel, some hue from the other.

In a more simplified example to illustrate: imagine an RGB colour has to be expressed with 4 clocks of red, 4 clocks of green, then 4 clocks of blue in a repeating pattern. Use this to represent a trio of White, Black, White pixels of 8 clocks each. The first white would get 4 red, 4 green, but no blue. The black pixel would eat up 4 blue and 4 of the next red. The last white pixel would get 4 green, 4 blue, but be missing its red. So, you'd see: Yellow, Black, Cyan?

The actual thing here isn't in RGB chunks like that, it's more of a continuous thing that's an accumulated average of what's around it but it's a similar idea where if you don't get a whole cycle in your colour is corrupted, and the exact phase where it occurs changes the specific colour you'll get.

Like I mentioned there are 6 random phases on reset. In my torture test ROM, that top left diagonal might look Red, Green, Blue, Magenta, Yellow, or Cyan depending on which phase the PPU was reset with. You can't really choose which, unfortunately. (Was it the TRS-80 that had some games that told you to reset until you saw the correct set of colours onscreen?)

TRS-80 is unfortunately not specific; it's specifically the CoCo that had this ?feature?.

To answer your question: Yes, fields of 1px vertical stripes alternating Red-Blue-Red-Blue and Blue-Red-Blue-Red should look pretty much the same on NES and Super NES PPUs. If you want, I can whip up a test ROM in a few hours and take a photo of my TV.

Thanks for the input, guys. Some of this information still flies completely over my head, but I do intend to understand the process of composite video generation better some day. I just can't get sidetracked right now.


Thanks for the confirmation. Thanks for the offer too, but I don't think a test ROM will be necessary... The exact reason I asked about it here is that I didn't want to waste time making a test ROM!

You don't need to make a test ROM if you have a flashable SNROM cartridge (or equivalent CF/SD adapter) on which to run a graphics editor. That's what I was planning on doing anyway.