nesdev.org

It's been a while, hasn't it?

Anyway, here's a mockup I did:

Looks good. I wonder how the dithered colors would look with NTSC artifacts, but so far it certainly looks better than Somari!

tokumaru wrote:Looks good. I wonder how the dithered colors would look with NTSC artifacts, but so far it certainly looks better than Somari!

According to Blargg's NTSC filter it will look like this:

Not too bad on the stones, but the water looks pretty weird with those diagonal stripes...

tokumaru wrote:Not too bad on the stones, but the water looks pretty weird with those diagonal stripes...

I think it'd look weird without the see-thru effect since it matches the background in the stones. A wavy line with nothing above or below would look weirder. Very nice graphics!

EDIT: But, the different-colored background immediately underneath the wave-crests is somewhat strange to look at. Unless of course it is floating organic debris?

This might be a good place to use a one-framed alternating dither pattern. Similar techniques were used for the shields in the 16-bit Sonic games, and for the water in the 8-bit games.

And sometimes a coarser dither pattern looks less artifacty.

Left: checkerboard; right: checkerboard stretched horizontally by 2, as in Videomation
Top: RGB; bottom: composite

Since most Genesis games didn't have a proper transparency effect (especially since those illusions would be broken thanks to RGB displays), is it possible to utilize some Genesis tricks and make them work on the NES? Granted it has a larger screen and can display more colors, but maybe the general idea might work?

The only trick I can think of is where artists dithered with vertical bars rather than a checkerboard pattern. The genesis also had a 320x240 resolution mode which used a faster pixel clock to create the increased horizontal resolution, which means that for each period of the colorburst wave, there's more pixels. So basically, the pixels blurred together better than they would on the NES.

I dunno, it'd still be worth a shot to try different patterns, but I think we did this before.

LocalH wrote:This might be a good place to use a one-framed alternating dither pattern. Similar techniques were used for the shields in the 16-bit Sonic games, and for the water in the 8-bit games.

Something like this?

(Please excuse the flickering, but GIF frame delays can only be specified in milliseconds instead of FPS)

Drag wrote:The only trick I can think of is where artists dithered with vertical bars rather than a checkerboard pattern. The genesis also had a 320x240 resolution mode which used a faster pixel clock to create the increased horizontal resolution, which means that for each period of the colorburst wave, there's more pixels. So basically, the pixels blurred together better than they would on the NES.

It's not just the pixel clock, the Genesis composite output also exhibits color mixing in H28 mode (256x224) such that that distinctive dithering still functions. Not sure of the low level reason for that, probably realted to the timing relative to colorburst. I know the H28 pixel clock is damn close to the NES/SNES (I've used the same aspect ratio for Genesis graphics as one would use for NES graphics, and PAR is a function of the pixel clock, since the pixel clock determines the width of a pixel).

DevEd: Yeah, that's what I was talking about. I'm not sure if I'd apply it to non-water tiles unless you're going for a translucent effect for them too (like if an object gets behind the wall).

The 256px mode of TMS9918-derived NTSC VDPs, such as those in the ColecoVision, CreatiVision, MSX, Master System, and Genesis, has a 342-pixel scanline. (NES and Super NES PPU is 341, and standard NTSC is 341.25.) This means the phase of the dot clock relative to colorburst does not change from line to line, causing vertically oriented color mixing. Nor does this phase change from frame to frame.

Genesis color mixing is more distinctive in 320px mode because its dot clock is 15/8 of colorburst. This means the two layers contribute almost equally to each subcarrier period, and the vertical pattern loops roughly once every metatile.

Didn't Battletoads make use of a timing glitch that allowed for 3-frame phase cancelation instead?

If the program leaves rendering turned off just before the start of the first line of picture, the pattern is different. Battletoads turns rendering on late to increase usable video memory bandwidth on NTSC. I do the same in my rgb121 demo to keep the phase pattern from destructively interfering with dithering. But it does create a bit more of a moving texture overlaying the picture, as infiniteneslives pointed out: "The 'motion' is difficult to ignore".

How about 2-pixel wide flickering dithered pattern with 3 frame phase cancellation.