I was thinking about it for some time. Basically trick is based on "half-transparency" one, where sprite is being drawn every second frame (either odd or even ones). If we'd change palette of sprite every second frame, altering it so fast that human eye can't notice it, we could in theory "mix" NES palette's colors to achieve shades that are normally outside NES range. What do you think?
Flickering is a topic that has come up here very often.
For a variety of reasons, it's fairly failure-wrought.
viewtopic.php?f=21&t=9674viewtopic.php?p=101093#p101093viewtopic.php?f=22&t=9551In summary: 30Hz is only below the flicker fusion frequency of the human eye in very dark conditions; using a checkerboard pattern to mitigate spatial noise produces chroma error; other spatial noise diffusion doesn't have high enough spatial frequency to be obviously useful. And regardless of whether you could use it successfully, Bregalad will tell you you're wrong for even considering it.
Those threads deals with multicolored, layered sprites. My idea is for 3 color (except transparency) sprites that have colors outside of standard NES palette:
As you can see, result sprite (bottom) changes palette between first and second one which in return gives out color in between those used in both palettes. In theory, you could use this method to get more colors as long as two NES colors can be mixed together, 1:1 to get it.
On the NES, if a monster sprite flickers in color like that, that usually means the player has damaged the monster.
Too much flickering and you might give someone a seizure.
Everybody has though of this "trick" at some point, but it doesn't work that well on the NES. Colors don't really blend together, you can easily notice the flickering.
That, and while it may look okay on the LCD display you are probably using on your desktop computer while testing, on a CRT television or a faster-response display it will be worse.
Use flicker when you want it to appear to flicker.
tepples wrote:
On the NES, if a monster sprite flickers in color like that, that usually means the player has damaged the monster.
*IMAGE REMOVED*
Seizure warning? j/k
You really should remove not only that image but the one it links too as well. You don't wanna trigger someone's epilepsy.
As I'm still using a CRT monitor, I can see the flickering of the ghost sprite quite clearly, so this method doesn't work well (even when the two colours are close). I think it'd look even worse with the colour artifacts on a CRT TV.
Gilbert wrote:
As I'm still using a CRT monitor, I can see the flickering of the ghost sprite quite clearly
AFAIK GIFs don't animate consistently at 60Hz, so the example posted here shouldn't be taken as proof of anything IMO. But I stand by the opinion that 30Hz flicker of any kind does not result in frame blending on the NES, and the result is unpleasant unless you're actually going for a flickering effect, which is often used in games to represent danger or damage.
GIFs are quantized to multiples of 10ms between frames. So you can accurately simulate what it would look like on a PAL TV on a monitor that ran at 50Hz (or a multiple), but nothing else quantizes nicely.
I believe browsers haven't always honored the delay though... I distinctly remember GIFs playing slow as hell in some old version of IE (7 maybe?). I'm not sure how current GIF support is though.
I made a game for the Atari 2600 that leans hard on flicker and color changes per frame called M.M.S.B.C. II
http://atariage.com/forums/topic/207626-mmsbc-2-done/It is very hard to manually figure out which colors will cause the least eye strain when combining every other frame. It's not just a matter of type of display but overall response rate and color accuracy. It's really a nightmare.