I should add that I wrote right above it:mikejmoffitt wrote:I was under the impression that all that is shifted is the color sub-carrier's position. This is to even out the artifacts over time.
Chris Covell's I want my RGB page describes this fairly decently on the screenshots page, and has this image to demonstrate:
ie: it's not the NES specifically, but systems that vary their colourburst to get rid of artifacts.Here's a theoretical example:
You mean the same LCDs that deinterlace every signal no matter what and completely destroy the flicker illusion? (and in fact that horizontal lines flickering idea would be completely broken on such a TV because it'll look like thick horizontal lines instead of alternating patterns)Dwedit wrote:Oh god... Flickering again? We've been through this 100 times already. Flicker on LCD = good, flicker on anything else = bad.
You work with what you got, and what you've got is a console developed during the early-to-mid-80s and RTM mid-to-late 80s, using technology that was available at the time. I dunno what else there is to say; that's the reality of the situation. If you absolutely need/want more colours to accomplish the visual style you want, I would recommend going the SNES/SFC route. You'll be surprised how much easier it is to develop on the that platform anyway.Sik wrote:In the end the only thing that seems to work properly is to avoid faking colors altogether and try to make graphics look good exclusively with solid colors, but that starts getting annoying when the amount of colors is so small.
Why not take the next step and develop on PC instead? Now THAT'S when the developing really becomes easier. Point being, part of the charm is trying to push the envelope.koitsu wrote:You work with what you got, and what you've got is a console developed during the early-to-mid-80s and RTM mid-to-late 80s, using technology that was available at the time. I dunno what else there is to say; that's the reality of the situation. If you absolutely need/want more colours to accomplish the visual style you want, I would recommend going the SNES/SFC route. You'll be surprised how much easier it is to develop on the that platform anyway.Sik wrote:In the end the only thing that seems to work properly is to avoid faking colors altogether and try to make graphics look good exclusively with solid colors, but that starts getting annoying when the amount of colors is so small.
These images are there only as a visual reference of different flickering techniques. I've never said they make good use of colors - because I know they don't.Sik wrote:Dwedit wrote: Also any technique is going to look bad no matter what when the two colors in the mix are too different (like the green and black in those TMNT pics), even when there aren't any signal noise artifacts at all. It's just too noticeable to be usable.
...until you have to deal with graphics APIs and underlying SDKs with crappy documentation, with a Web filled with completely wrong information. There's a reason I stopped doing anything with graphics/video circa 1997. Kudos to anyone who toughs it out, but god the situation is abysmal today.thefox wrote:Why not take the next step and develop on PC instead? Now THAT'S when the developing really becomes easier. ...
Not anywhere even remotely as noticeable though. Could be even considered passable, the Blanka pic seems to be the only one where it's sorta easy to notice (the Sega logo happens to go along the diagonals ^_^') and even then the impact is pretty light.Macbee wrote:The diagonal "rainbow patterns" are still there...
Yep, I agree with you. These patterns are discrete and "forgivable" to me as well.Sik wrote:Not anywhere even remotely as noticeable though. Could be even considered passable, the Blanka pic seems to be the only one where it's sorta easy to notice (the Sega logo happens to go along the diagonals ^_^') and even then the impact is pretty light.Macbee wrote:The diagonal "rainbow patterns" are still there...
Advantageously straight vertical lines don't look fuzzy?scratchy as a result, though (Mario flagpole I am looking at you!)TmEE wrote:On SMS and MD you get straight vertical rainbowing not diagonal. There is no colorburst shifting happening of any kind on them.
What happens when you use a horizontally-stretched checkerboard pattern?Macbee wrote: 1) Checkerboard patterns -
Pros: It's the ultimate flicker technique to make good looking images. Results are usually impressive.
Cons: Diagonal artifacts seems to be present all the time when using Composite cables, no matter how similar flickered colors are.
2) Horizontal lines patterns -
Pros: It's the only flicker technique that doesn't seem to create diagonal artifacts when using Composite cables.
Cons: End results doesn't look as good as checkerboard flickered images (shakiness is way more evident).
Code: Select all
xx xx
xx xx
xx xx
xxx xxx
xxx xxx
xxx xxxUnfortunately, this ends up looking less like blended colors and more like a stretched checkerboard at that point.Drag wrote:What happens when you use a horizontally-stretched checkerboard pattern?Macbee wrote: 1) Checkerboard patterns -
Pros: It's the ultimate flicker technique to make good looking images. Results are usually impressive.
Cons: Diagonal artifacts seems to be present all the time when using Composite cables, no matter how similar flickered colors are.
2) Horizontal lines patterns -
Pros: It's the only flicker technique that doesn't seem to create diagonal artifacts when using Composite cables.
Cons: End results doesn't look as good as checkerboard flickered images (shakiness is way more evident).
For instance, two columns for every row, or three columns for every row:
This seems like it'd be a good compromise between the two methods.Code: Select all
xx xx xx xx xx xx xxx xxx xxx xxx xxx xxx