Do any games use tile/sprite overlap for more colors?

[3gengames]

Contra looks epic doing the flickering in the 2nd bases boss. Super contra intro I don't like as much. Those are the only place I've really noticed using sprite overlapping being used on even/odd frames.

[Sik]

Project MD does that flickering trick just about, um, everywhere, even in the freaking arrow in menus (and in levels the effect is outright fullscreen) - though instead of using horizontal patterns it uses checkerboard patterns. It works fine as long as the game never slows down (which there never happens, but it could be prone to happen in a NES game, I guess).

EDIT: what's going on with that game in the video Shiru linked?! Things start going seriously crazy in world 1-2 o_O

[Macbee]

The flickering was a common tech for demo coders on all platforms, and in games made by demo coders. Barely seen in commercial games, because it doesn't look too good.

Batman isn't the best example, though, because it flickers between two completely different pictures, which is the worst case scenario.

It isn't necessary to slow down the gameplay to half of the frame rate, by the way. There was an attempt of SMB unofficial port to ZX Spectrum (Soviet clones, to be exact) that used flickering to increase number of shades from 2 to 3 and it was running at 50 FPS, which is quite an achievement for the platform. It didn't look too bad. Unfortunately, all videos of the game on YouTube aren't represent the game well at all, they all has crazy lag (example).

Thanks for this explanation Shiru! I had no idea that flickering sprites were already used in the past.

Is there a reason you interlaced detail horizontally, like so:
And not checkerboard dithered, like so:
?

The software I'm using sorta creates these lines automatically - but your suggestion was really appreciated, thanks! =)
I tried to do it using checkerboard dither and the results are even better (Simba.NES is attached)!

[tepples]

Is there a reason you interlaced detail horizontally [...] And not checkerboard dithered

On the NTSC NES, checkerboard is more likely to result in annoying diagonal artifacts. See rgb121.

As for in-game flicker, Thwaite is made of it. All explosions flicker for semi-transparency, and all smoke flickers to allow more smoke to be drawn.


EDIT: link repaired

[Sik]

On the NTSC NES, checkerboard is more likely to result in annoying diagonal artifacts.

Use vertical strips then?

[Macbee]

I wish I could buy a Powerpak and see (the results of flickering) by myself on my CRT television. I have a PAL-M famiclone - so maybe the interlaced image can look a little different from a NTSC NES.
It's a shame that it may create all these artifacts... I'm making new checkerboards tests and I'm more and more impressed with the results (another Rom is attached).

[Shiru]

These pictures are looking very good on my old TFT (25ms response time), I'd say perfect, because the flicker isn't visible at all. However, I seen how flicker looks on a normal CRT TV, and it is nowhere nearly as good, the flickering is easily noticeable, especially on large areas.

[tokumaru]

The flickering is very subtle in the tests you posted, and the colors don't vary much, so in this case it might work. Still, what you get is the illusion of more shades of the same color, not more colors.

[Macbee]

The flickering is very subtle in the tests you posted, and the colors don't vary much, so in this case it might work. Still, what you get is the illusion of more shades of the same color, not more colors.

Well, different shades are different colors. But I understand what you're saying: when you need completely different colors the good old sprite overlap is still necessary.
I prefer to use this technique in sprites without many color variations - to me it's when it really works. But you can easily mix different colors and the results are nice too.
Download my "4 into 10 colors" test. You see green created from yellow and blue, purple from blue and red, etc.

By the way with this demo I can finally see diagonal artifacts (thanks to the amazing CRT filters found on Nestopia emulator).
I don't know if the artifacts are more evident on a real CRT TV but (judging by what I can see on Nestopia) they're not as annoying as I tought.

[Bregalad]

Just my $2, but while this kind of flickering usually works great with emulators on modern PC-workstations with LCDs, it tends to look terrible on an authentic system with a CRT, it doesn't look transparent at all and actually looks like flickering.

At least the intro of Batman looks terrible on a true CRT.

[Sik]

Just my $2, but while this kind of flickering usually works great with emulators on modern PC-workstations with LCDs, it tends to look terrible on an authentic system with a CRT, it doesn't look transparent at all and actually looks like flickering.

At least the intro of Batman looks terrible on a true CRT.

Which is why in Project MD I used the checkerboard pattern. Stripes are very noticeable because they're very big areas so the eyes can easily spot them out. The checkerboard pattern gives you the smallest area possible and as long as vsync is accurate (i.e. 1 frame = 1 refresh rate) it's practically impossible to tell. This works fine even when with crystal clear output.

And of course, the more similar the two shades, the better the effect works. Middle red vs. light red is more likely to work fine than blue vs. green, for example.

[Dwedit]

I once got a 120Hz refresh rate on a CRT, it was some kind of VGA mode where it omitted half the scanlines. On that video mode, flickering looked exactly like half transparency.
I think it was Nesticle that had that video mode as an option. You had to turn off the frame limiter, but turn on VSYNC.

But 60Hz is far too slow for flickering to look any good on a CRT.

[Sik]

When I messed with this kind of flickering it was only on CRTs, I don't have any LCD screens around. Unless you mean raw flickering rather than using patterns, then yes, it's going to look horrible at any framerate unless the areas in question are small enough.

Also you need to take into account the ideal refresh rate of the CRT monitor, since this affects for how long the light stays on screen. Computer monitors are generally made for 85Hz (early ones for 70Hz), while TVs are generally made for around 60Hz. This means that the 120Hz mode you mentioned most likely exceeded the ideal refresh rate of the monitor and had such a slow reaction that indeed turned the flickering into real transparency.

The human eye has been proven to be able to distinguish up to 240Hz at least, so I'd expect flickering to be noticeable up to that rate.

[lidnariq]

The human eye has been proven to be able to distinguish up to 240Hz at least, so I'd expect flickering to be noticeable up to that rate.

That's a really tricky assertion; those assertions are talking about two different abilities of human perception.

One is what's called the flicker fusion threshold, which is a function of ambient light level, but is generally accepted in rigorous experiments and the brightest conditions to be pretty strictly never above 100Hz for humans. If you hear someone complaining about magnetic ballast fluorescent lights, they may well be seeing stroboscopic effects or complaining about color rendering index or sound but they are unequivocally not seeings the 120Hz (US) directly.

The other is the ability to detect phase difference, which can easily go up to this 240Hz, or more accurately, down to 4ms. Detecting phase difference is plausible is other cases, but is entirely different from what you see when you look at a CRT.

[thefox]

The examples look pretty good, too bad I don't have a CRT TV to test them on. Still, I think this method might be a worthwhile tradeoff between more flicker/more detail/less sprites on scanline [and funnily enough, less sprite limitation based flicker because of that] in some cases.