nesdev.com

There's three interesting effects here. The most apparent is the black and white pattern happening on the single line that is supposed to be colour $22.

The second that there is a 2 lines wide band of colour that should be a yellowish $28 but, as it turns out, is instead a somewhat flattering extra apricot colour that goes across the whole screen.

Thirdly, the bands are sort of inverted through blending (not how the upper band is slightly greener), compared to the emulation. They're probably all related.



I'm using my PAL system. I suppose these effects wouldn't appear on NTSC? It's a first for me. I guess it doesn't like a single horizontal line of colour so close to that bright sun. But i'm not too worried about it since there's supposed to be a sprite overlay on those rows that bends the attribute grid a little around the sun. Just curious what exact conditions causes it.

Edit: the single black-and white dots are easier to get since they're about differences on the same line.

Oh, and i'm setting bits R+G to achieve a morning light-looking master palette. But it doesn't matter.

_________________
http://www.frankengraphics.com - personal NES blog

I think some more info would help in figuring out what's going on. Are you loading the background on reset before turning rendering and nmi on? Are you doing any sprite-0 stuff?

My first thought would be that you're doing writes to $2006 without rendering turned off and that it just happens to occur on that scanline. But that's my best guess, as I've recently started learning about sprite-0 and had some similar glitches happening while doing so.

Do you have a secondary system to test on to rule out hardware failure? If you post a test rom I could try it on both PAL and NTSC.

Edit: I have NROM and TKROM flash carts, so if your rom does not support any of those I would not be able to test it.

I believe you're running into PAL's vertical chroma subsampling. Putting two scanlines of opposite phase should cancel out the color component ... and apparently also produce luma artifacts? Unfortunately, none of the videos in that thread are both of 1- a device that actually does this vertical chroma subsampling and 2- close enough to the TV to indicate whether these same dots show up for them

That thread explains a lot, thanks!

I've managed to isolate the occurence of luma rippling (alternating blacks and whites) to whether the colour border is below an even or odd line. The ripple is either perfect white and black (at neighboring lines with colours $22 and $28 for example -being off phase with each other), or tinted when not completely off phase. What i don't get at this point is why it isn't a smooth gray.

I haven't ruled out hardware deviations like pwnskar suggested yet, but have another PAL unit in the drawer. Will test with that soon.

In any case, I solved the ripple by moving the whole gradient pattern 2 steps up and fill in the line that caused the trouble.

I suppose additional colour bands simply are there to stay, but i think they fit quite nicely into the sky gradient... it's sort of nice that PAL users will get a slightly more colourful/seemingly attribute-breaking ending as compensation for the game being slightly more optimal on NTSC in other respects.



Haha, i fell into a trap with sprite 0 just the other week too. It had to do with scroll splitting though, and it's not used here.

Also, thanks for offering to test it on your hardware.


Edit: Comparison before/after odd/even aligning the gradient border.

_________________
http://www.frankengraphics.com - personal NES blog

The PAL delay line causes no such hanging dots, because the averaged chroma is not fed back to the Y/C splitter, at least not in a classic design.

What you are seeing is just a badly-implemented adaptive comb filter on the part of whatever device does the PAL decoding. I know that because in my attempts at implementing an adaptive comb filter in software, I often produced similar-looking artifacts.

So on another monitor that ripple would simply come out as gray, i take it. That's good to know. In any case, i opted to avoid the occurrence altogether.

_________________
http://www.frankengraphics.com - personal NES blog

Yes, avoiding one-line (almost-opposite) colors is probably the safest choice.

At least one game, "Felix the Cat", uses a striped pattern of pink and blue in the status bar when the game is paused. I wonder whether this was done in order to purposefully make use of vertical blending? Such was done a lot on the Apple II, but I do not know if that can be readily transferred to the much more capable NES PPU.

It's kind've ironic how bad it is considering that PAL has a reputation for having better picture quality than NTSC.

The badly tuned comb filter thing is really annoying, yeah. But apparently it's not so much the PAL standard as the specific EE implementation done to some TV:s.

NTSC (with the popular mnemonic never the same colour or never twice the same colour) is the older of the two standards, whicch means PAL could be designed with a hindsight reflection on NTSC pros and cons. While PAL was designed with colour in mind, the NTSC standard was retrofitted with colour capabilities. So i think you could safely argue that colour is more consistent on PAL, both evidently have quirks you may need to negotiate (that is if you care) or might want to exploit to your benefit.

_________________
http://www.frankengraphics.com - personal NES blog