[Nukey Shay]

(sigh)
Nevermind. I just thought that the topic was creating hires pictures.

[CPUWIZ]

Sheesh, this is what Nukey means:





Regardless of whether it's interlaced or not, what good does one color per line do for you in regards to creating a picture ?

Right Nukey ?

[Nukey Shay]

Exactly! Is that what you are referring to? The VCS can already do that without any kind of interlacing (though it would be limited to it's own pallette of 128...[ or is it 256? ] color shades). But how does that help create a hires picture?

[Robert M]

Nukey,

you are missing a keyt component of what Zylon is describing. He is talking about building a 6 color image by changing between 3 different colors RGB over 3 television frames. So the final image is a composite of 3 frames which through the magic of persistence of vision the user sees as a single 6 color image.

You are correct that each color is being illuminated at 20Hz. So the flicker could be bad. To minimize the flicker he suggested interleaving the 3 colors into each frame.

FRAME1:
Red line
Green line
Blue line
Read Line
Green line
Blue line
Red line... etc.

FRAME2:
Green Line
Blue Line
Redline
...repeat.

FRAME3:
Blue line
Red Line
Green line.


By interleaving the colors you minimize the flicker because 1/3 of every color is in every frame. Smearing between the phosophors will help too. It would interesting to see it on the Atari 2600.

[ZylonBane]

Rob-- Exactly! Although it's 8 colors (2*2*2), not 6.

I'm attaching a proof-of-concept image. Take a look at it, and try to guess how many colors it's using. Then load it up in your paint program of choice and be amazed.

Attached thumbnail(s)

• 

[Robert M]

That' a very good example. Very cool. So given a photo you would need a filter to reduce the image to a pallete of 8 colors using dithering to get the desired shading. Hmm... very interesting. Thanks for sharing!

[ZylonBane]

Since this is a one-color-per-line thing, you can't just reduce the whole thing to a small palette. You have to split each image up into 3 grayscale R/G/B images, reduce them to your target color depth (for a 2600, that would be 2-color), then interleave them back together.

You're essentially creating meta-triads... RGB triads at the pixel, rather than phosphor level.

And this is how the above image would look on a 2600. Scary, isn't it? This is why you need active interlacing to recover the resolution you lose.

Attached image(s)

• 

[Robert M]

Agreed! But there is still the hitch that anything over 48x192 on the 2600 is non-trivial. With a horizontal resolution of 48, would the results be worth it? Your example image is 512x384 and it is stunning, but at 48 wide you are restricted to about a single eye or the nose of the sample image.

[Nukey Shay]

I'd ask for that in English...but it's already over my head

[Thomas Jentzsch]

Robert M said:

Agreed!  But there is still the hitch that anything over 48x192 on the 2600 is non-trivial.  With a horizontal resolution of 48, would the results be worth it?

If somebody sends me the three greyscale images (scaled down to 48 pixel witdth!) I'll make a demo out of it.

[Andrew Davie]

Thomas Jentzsch said:

Robert M said:

Agreed!  But there is still the hitch that anything over 48x192 on the 2600 is non-trivial.  With a horizontal resolution of 48, would the results be worth it?

If somebody sends me the three greyscale images (scaled down to 48 pixel witdth!) I'll make a demo out of it.

I already have Sam Fox running with the split RGB method (which I was working on before the above discussion anyway), downsizing each RGB layer to 2-colour with Floyd-Steinberg dithering. I'll post a demo on [stella] shortly. Even in B&W, it gives a reasonable image.

Cheers
A

[Andrew Davie]

ZylonBane said:

Ok, I'm not really going to have to explain the concept of additive color blending, am I? Haven't you ever looked at a color TV really close?

"The TV can display a seperate color on each phosphor already...why would you need to incorporate 3 phosphors into one? Just to increase the color pallette? You would still only have one color per phosphor, right?"

Here's a binary with a colour bitmap.
Run it and weep!

Attached File(s)

•  samfoxcolour.zip (17.16K)
  Number of downloads: 139

[ZylonBane]

Interesting!

Unfortunately, since you're swapping between solid R/G/B frames it does flicker severely and you don't get the color-blending benefit of the ColorView approach.

Attached is a ZIP of three pre-interlaced clown images, and a GIF preview of what it might look like on a 2600 (highly doubtful any browser will animate it at the specified speed).

Attached image(s)

• 

Attached File(s)

•  2600clownrgbs.zip (2.05K)
  Number of downloads: 48

[Andrew Davie]

ZylonBane said:

Interesting!

Unfortunately, since you're swapping between solid R/G/B frames it does flicker severely and you don't get the color-blending benefit of the ColorView approach.

Attached is a ZIP of three pre-interlaced clown images, and a GIF preview of what it might look like on a 2600 (highly doubtful any browser will animate it at the specified speed).

I wasn't attempting to use your method. And it doesn't 'flicker severely' on my machine. I assume you are viewing on an emulator, not the real thing. Because though I am also using an emulator, I *do* get colour-blending.

In any case, there are several methods. I think the one I presented actually works quite nicely - and really it only counts when you're talking about viewing on the real thing, anyway.

Cheers
A

[ZylonBane]

adavie said:

I wasn't attempting to use your method.

I didn't say you were. And it's not my method. A nice bloke by the name of Jeff Potter came up with it years ago. I also didn't say your method doesn't provide any color blending, just that it doesn't offer the type of blending that ColorView does.

The Atari computer demo scene has been over this territory a LOT, and they almost always go for interlacing for the pseudo-color screens. I have to think there's a good reason for that.

[Thomas Jentzsch]

ZylonBane said:

Attached is a ZIP of three pre-interlaced clown images, and a GIF preview of what it might look like on a 2600 (highly doubtful any browser will animate it at the specified speed).

Ok, I've made a demo out of this. Check it out!

IMO it flickers less on an emulator, somebody should compare this with Andrew's demos on the real thing.

BTW: Maybe this thread should be moved to the Programming Forum.

Attached File(s)

•  clown_demo.zip (1.42K)
  Number of downloads: 115

[ZylonBane]

Wow, rapid turnaround there Thomas! Looks nicer than I thought it would, what with the low resolution dithering.

Might be fun to convert a few more images and put out a little slideshow demo. Any suggestions?

[Paul Slocum]

I tried them all on a TV and the clown demo looks quite a bit better IMO. The flicker is not very noticable.

Samfox and Qb flicker a lot more. And in Samfox the colors are too subtle on my TV. I had to crank the saturation to make it out, and that made the flicker look worse.

Both are really impressive though. It would be cool to use it in my RPG to show characters as you talk to them, but I suspect it would use too much ROM space.

-Paul

[Thomas Jentzsch]

ZylonBane said:

Wow, rapid turnaround there Thomas!  Looks nicer than I thought it would, what with the low resolution dithering.

Thanks.

I think it might be even possible to improve it. It depends on how you split the colors. Most images tend to use not the whole color range (e.g. the Clown picture used a lot of red but not much blue). So, if you optimize the three color channels to match the needed colors as good as possible, the result should look even better. Also reducing the contrast might help to reduce flicker.

Can you provide a link to the original Clown picture? I guess some experimenting here might give even better results.

[ZylonBane]

Paul-- Yeah, a 48x80 image done this way consumes ~1.5K. But for your RPG you could go for something a lot simpler, like a 16x32 image using only 2 layers. That would only take 128 bytes per image, plus you'd be able to set real colors for each layer. Eh, probably be simpler to just go for regular color bands.

Another possible form of the CV technique is to go with 3-scanline-tall pixels. That way you could display all the RGB components at the same time, and just use the rolling interlace for color blending.

EDIT: D'oh, Thomas responded while I was composing--

Here's the clown image:
http://rsb.info.nih....mages/clown.gif
This pic has a bit of history. It's one of the images that was used a lot in print ads back when 256-color graphics cards were new. That's why it's only 320x200... MCGA resolution! Fortunately this is already the correct aspect ratio for the 2600. Baboon.jpg (on the same site) was also used for these ads.

As far as individually tweaking the RGB colors... this is exactly the same as going into a paint program and adjusting the RGB levels. You end up affecting the tint of the entire image. It would only be practical on 3-color images that didn't use any blending (or very carefully controlled blending).

Another thing, it turns out Robert M was initially correct about being able to load a custom palette. I was so caught up in the mechanics of channel splitting that I didn't see it at first. So the way I'm creating test images now is:

1. Crop/downsample image to 48 x whatever
2. Load a custom palette I've created that only contains RGBCMYKW (slightly desaturated), using error diffusion dithering.
3. Split to RGB.
4. Well, here it gets more involved. Progressive scanline masking and recombining and such.

Before (as with the Clown demo), I was splitting to RGB first and then downsampling, which caused the diffusion dither to be out of synch in the three images. Whoops!

[Nukey Shay]

Paul Slocum said:

Both are really impressive though.  It would be cool to use it in my RPG to show characters as you talk to them, but I suspect it would use too much ROM space.

Why not combine the players and missiles then? That will have much smaller pixels for better looking pictures and can be as tall as needed. Since the players and missiles are written to the screen immediately (just like the screen GFX), this would be possible as well...right?

[ZylonBane]

[Nukey Shay]

...?

[Nathan Strum]

Thomas Jentzsch said:

Ok, I've made a demo out of this. Check it out!

Do you have info on this for a stella.pro entry?

[Nukey Shay]

When I mentioned "combined", I mean displaying them side-by-side. The player objects are 8 bits wide, and missiles 2...this gives you 20 pixels across (40 if re-used once each). As with screen pixels, the sprites can be colored independantly on each scanline, right? So you could create pictures with smaller "pixels" (the P/M bits)...which would look better on-screen than using the background pixels.