128 colors squared possible?

[MayDay]

Hello,

 

I was going through information about 2600 prototypes and ran across the venetian (spelling?) blind demo. That got me to thinking if colors on the 2600 could be interlaced by frame to produce a lot more colors... not in actuality, but in perception to the human eye.

 

Please see the attachment. The idea was to make a red square, a yellow square, and a square in between that alternated between the two to make an orange (percieved) color. I'm new to programming and maybe more importantly, up past my bedtime but hopefully you can understand what I was trying to do here. I quickly threw this together without a ton of thought, and I'm sure it will show.

 

colordemo.ZIP

 

I know this isn't optimized or probably even practical, I just wondered if it was possible? I'm curious to see what you guys have to say, and will try to play around with it some this weekend.

 

-JD

Edited November 10, 2005 by MayDay

[supercat]

I was going through information about 2600 prototypes and ran across the venetian (spelling?) blind demo.  That got me to thinking if colors on the 2600 could be interlaced by frame to produce a lot more colors... not in actuality, but in perception to the human eye. 

963105[/snapback]

 

It's not really practical to get 16,384 colors via that method, but it can certainly be used to increase the number of simultaneous colors available. You're not the first person to think of it. I'd actually thought of implementing a game using that approach in 1994, and posted a demo earlier this year (in the thread http://www.atariage.com/forums/index.php?showtopic=70712 I give a little seven-color paint program). The paint program doesn't work as well as I'd like on a real machine (the colors come out a bit muddy) but it shows the technique.

[+batari]

I was going through information about 2600 prototypes and ran across the venetian (spelling?) blind demo.  That got me to thinking if colors on the 2600 could be interlaced by frame to produce a lot more colors... not in actuality, but in perception to the human eye. 

963105[/snapback]

The 2600 was designed to produce a non-interlaced display. The venetian blind demo actually just flickers colors on alternate frames.

 

However, you can produce a "real" interlaced NTSC display (262.5 scanlines). I've seen demos of this, and I think it was done by strobing RSYNC at in the middle of the scanline (which resets the scanline counter.) And I think that you also need slightly different VSYNC timing for even and odd frames, as I understand. But using a real NTSC signal, I would expect very good results at creating virtual colors, much better than Venetian blinds.

 

Regardless, I'm not sure of the real utility here except for the "Gee Whiz" factor.

[djmips]

Also google for "Interleaved Chronocolor" and/or check the Stella list archive for same, because Andrew Davie did a lot of various experiments on displaying and animating very colorful sprites. I remember in particular the large Mario 64 sprite was quite nicely done.

 

'edit'

Here's a link to the explanation of the version that utilized interlacing as well.

 

Interlaced Spasticolor"

Edited November 10, 2005 by djmips

[MayDay]

After getting off work, I went back and posted a better working example, though the flicker is awful.

 

supercat:  It's not really practical to get 16,384 colors via that method...I'd actually thought of implementing a game using that approach in 1994, and posted a demo earlier this year

 

I saw that thread and thought it was a kernel for producing a grid instead of making extra colors. Because of that, I didn't take the time to download the binary, I usually only do that if I have a question about code itself (or want to play a certain game). I'm not trying to get all 16,000 colors, but am saying that any one of those colors *should* be available to you at a given time.

 

batari:  The 2600 was designed to produce a non-interlaced display. The venetian blind demo actually just flickers colors on alternate frames...Regardless, I'm not sure of the real utility here except for the "Gee Whiz" factor.

 

Indeed. Sorry, I was about to fall asleep when posting last night and stated this absolutely wrong. I did however, come up with three utilities today while I was at work (knowing I would probably be asked ) and here they are:

 

1. Using two colors to make a three-colored sprite (original inspiration for idea).

2. Making a ported game more color-accurate to the original.

3. Surely SECAM users wouldn't mind a few extra colors?

 

@djmips- Andrew Davie mentions the "interleaved chronocolor" in one of the playfield tutorials (he's the man for creating those, btw). A 3-line RGB method would not be as accurate as this method for an exact color (I wouldn't think, at least up close where perception would be less than if seen from far away). I had not come across the "interlaced spasticolor" and was blown away by the theory. It seems to combine both theories into one if I understand it correctly by alternating the RGB between lines. What it doesn't specify, or at least I don't think it did, was does one color (let's say Red) go between all 3 lines, or just alternate on 1 for each of the two frame (2 lines out of 3 total on 2 frames?). No matter the case, it seems I'm about three steps behind Andrew in my theory (but at least I can spell color). Queen's English? Good grief, Charlie Brown! I'm still amazed at how well the people around here know their stuff about Atari hardware and programming.

 

-Jason

[vdub_bobby]

but at least I can spell color

You better watch out, he does poke his head into these forums on occasion.

[SeaGtGruff]

When you mix colors by flickering, the results are better (i.e., less obvious flicker) if the colors being mixed are close together in hue or luminance. For example, you could mix hue 2 (yellowish-orange) and hue 3 (reddish-orange) to get more of an "orange-orange," or you can get 15 shades of a particular hue by mixing two consecutive luminances (i.e., luminance 0 and 2, or 2 and 4, or 4 and 6, or 6 and 8, or 8 and 10, or 10 and 12, or 12 and 14).

 

Creating an interlaced display can be either good or bad for mixing colors. On the plus side, the combined scan lines will be closer together. But on the minus side, the colors that you're trying to mix won't be drawn directly on top of each other, so they won't mix together as well.

 

By the way, as I understand it, there's no need to use RSYNC when creating an interlaced display. All you need to do is draw 262 complete lines (on an NTSC 2600), then start drawing a 263rd line, but turn on VSYNC halfway through the line. Obviously, this means you'll need to count machine cycles or color clocks so you'll know when to turn on VSYNC. The next field should automatically begin with half of a scan line, so you'll need to keep that in mind when you're counting the scan lines (i.e., the first line is not a full line, so don't start counting until *after* the half line). Then, at the end of the second field, turn on VSYNC as soon as the last line has been drawn.

 

Last year I started to write a game called "Quest for the Lost Pyramids of Atlantis," which I've put aside for the time being, but my plan was/is to have NTSC, PAL, and SECAM versions combined in one game, controlled by the difficulty switches. And I was using interlacing to get more colors in the SECAM version. After I made a few test screens, I started working on the title screens, which implement the interlacing, etc. I'm attaching my last working copy of the title screens, which can be displayed in NTSC, PAL, or SECAM. All three versions use an interlaced screen, but only the SECAM version uses the interlacing to mix colors.

 

To run it on the z26 emulator, use

 

Z26.EXE -g7 -v3 -! LSTPYR1H.bin

 

for SECAM, use

 

Z26.EXE -g7 -v3 -1 -! LSTPYR1H.bin

 

for PAL, and use

 

Z26.EXE -g7 -v3 -0 -! LSTPYR1H.bin

 

for NTSC. If you run it for the SECAM version, you may need to use the "-" key to switch from the PAL palette to the SECAM palette (which should show yellow letters on a red screen, with red and black mixed together on the bottom part).

 

If you can load it into a Cuttle Cart or Krokodile Kart on a real Atari, set the left player difficulty to "hard" for NTSC. Set the left difficulty to "easy" for PAL or SECAM. The right difficulty chooses between PAL and SECAM-- "easy" is SECAM, and "hard" is PAL. At least, I think that's correct! I can't test it on a real Atari, just an emulator, so I have no idea how well it works on a real Atari, if at all! And the title screens are kind of boring, but if anyone can test it on a real SECAM 2600, at least they can tell us how well the interlaced color-mixing works (if at all).

 

Michael Rideout

 

PS-- I'm also attaching a picture I made in a graphics program to try to see how interlaced colors might look on a SECAM 2600. It simulates interlacing by using alternating colors. I should be able to create an actual binary that would show the same sort of display on a real Atari, if anyone with a SECAM 2600 is interested.

LSTPYR1H.BIN

[SeaGtGruff]

By the way, if you mix X colors, you don't get X-squared combinations, since some of them will be the same (e.g., yellow-red and red-yellow produce the same mix). You actually get X! colors (if I have the notation correct)-- that is, "X factorial" (if I'm using the correct term).

 

For example, mixing 8 colors gives you 8+7+6+5+4+3+2+1, or 36 different mixes.

 

So mixing 128 colors gives you 128+127+126+...+3+2+1, or 64*129 = 8256 different mixes.

 

Michael Rideout

Edited November 11, 2005 by SeaGtGruff

[supercat]

When you mix colors by flickering, the results are better (i.e., less obvious flicker) if the colors being mixed are close together in hue or luminance. For example, you could mix hue 2 (yellowish-orange) and hue 3 (reddish-orange) to get more of an "orange-orange," or you can get 15 shades of a particular hue by mixing two consecutive luminances (i.e., luminance 0 and 2, or 2 and 4, or 4 and 6, or 6 and 8, or 8 and 10, or 10 and 12, or 12 and 14).

 

This is true. Most colors in my paint program exhibit no visible flicker on a real TV; to the extent that any flicker is visible under emulation, it's because of 'dropped frames'. The only colors that exhibit flicker are the ones that mix black with something else.

 

Unfortunately, the colors can sometimes be 'muddy' on a real television set because the two non-black colors that can be used on each scan line have hues that are 180 degrees out of phase (half the scan lines use 0 and 180; half use 90 and 270; thus, there are four colors that mix two hues that are 90 degrees apart).

 

Creating an interlaced display can be either good or bad for mixing colors. On the plus side, the combined scan lines will be closer together. But on the minus side, the colors that you're trying to mix won't be drawn directly on top of each other, so they won't mix together as well.

 

IMHO, if you are mixing two colors, interlaced sync serves no useful purpose. If you are mixing three colors, using an interlaced display allows for a 30Hz rather than 20Hz pattern (i.e.

-R-G-B
G-R-B-
rather than
R G B
G B R
B R G

 

By the way, as I understand it, there's no need to use RSYNC when creating an interlaced display. All you need to do is draw 262 complete lines (on an NTSC 2600), then start drawing a 263rd line, but turn on VSYNC halfway through the line. Obviously, this means you'll need to count machine cycles or color clocks so you'll know when to turn on VSYNC. The next field should automatically begin with half of a scan line, so you'll need to keep that in mind when you're counting the scan lines (i.e., the first line is not a full line, so don't start counting until *after* the half line). Then, at the end of the second field, turn on VSYNC as soon as the last line has been drawn.

 

I haven't looked at the Atari's sync output to see what it's up to, but it probably doesn't much resemble a proper vertical sync. A real vertical sync should look like this [each character is 1/8 scan line; the lengths of horizontal sync pulses are exaggerated; the top line is the composite signal and the bottom is horizontal sync]

Even fields:
-X-------X---X---X---X---XXX-XXX-XXX-XXX-XXX-XXX-X---X---X---X---X-------X--
-X-------X-------X-------X-------X-------X-------X-------X-------X-------X------
Odd fields:
-X-------X---X---X---X---X---XXX-XXX-XXX-XXX-XXX-XXX-X---X---X---X-------X-------X--
-X-------X-------X-------X-------X-------X-------X-------X-------X-------X-------X------

 

Note that horizontal sync is CONTIGUOUS through the interlaced frames. Before the "heavy" vertical sync pulse, there are a bunch of serrations called IIRC "equalization pulses". The idea with those is to make the vertical-sync detection circuit work more uniformly on even and odd frames. Whenever the composite sync signal is active, a certain cap charges up; when it's inactive the cap discharges. If the cap reaches a certain threshhold, it triggers vertical sync.

 

Without serration pulses, a greater level of charge would remain on the cap at the start of a vertical sync pulse that occurred mid-line than at the start of one that coincided with the next horizontal sync. This would in turn cause such a vertical sync pulse to be detected somewhat faster than the later one, and this would in turn cause the two interlaced images to be slightly misaligned.

 

Adding the seration pulses avoids this problem, since the state of the cap at the start of the vsync will be about the same on both even and odd fields (since in both cases, vsync will come just under half a scan line after the sync pulse). Note that the extra sync pulses won't affect the horizontal sync pulse, because a television set will ignore any horizontal sync pulse that occurs before the beam is about 75%-90% of the way across the picture.

 

I don't know to what phase RSYNC resets the horizontal clocks, but I suspect doing a proper interlaced vertical-sync signal would require a bunch of RSYNCs at 38-cycle intervals. Note that horizontal sync must continue unabated; just adding a single RSYNC to every other frame to cut a scan line short by 38 cycles might work with some monitors, but not others; turning on VSYNC mid-scan-line is also apt to yield dubious results.

963577[/snapback]

[mos6507]

The problem with using interlace (real interlace) to get more colors is interlace is flicker by its nature. So when you go interlace, the entire screen is committed to flickering.

 

With a noninterlaced kernel, you get static gaps between scanlines which looks better than the bobbing interlaced flicker. As the lines bob up and down, the colors will actually look a little dimmer because it's not drawing over the same scanline on every field but alternating with black.

 

With the SECAM screenshot you are really looking at two fields merged into one. The solid colors won't look solid on the real thing. They will look flickery.

[mos6507]

just adding a single RSYNC to every other frame to cut a scan line short by 38 cycles might work with some monitors, but not others; turning on VSYNC mid-scan-line is also apt to yield dubious results.

 

 

I'd be curious to hear stories of people who were not able to see true interlace with the old Stellalist demos. I didn't have any problems with them.

[SeaGtGruff]

I don't know to what phase RSYNC resets the horizontal clocks, but I suspect doing a proper interlaced vertical-sync signal would require a bunch of RSYNCs at 38-cycle intervals.  Note that horizontal sync must continue unabated; just adding a single RSYNC to every other frame to cut a scan line short by 38 cycles might work with some monitors, but not others; turning on VSYNC mid-scan-line is also apt to yield dubious results.

I haven't been able to try interlacing on a real Atari, but I reviewed the Stella-list posts about interlacing several months ago, and when it was first demonstrated by others it was shown that RSYNC wasn't needed (IIRC). I don't know about modern TVs or computer monitors, but the only thing that was needed a few years back, when it was first demonstrated in Stella-list, was to turn on VSYNC at the correct time, depending on whether the even or odd field was being drawn.

 

By the way, many years ago I was obsessed with getting more colors on my 8-bit Atari (600XL, 800XL, 65XE, and 130XE). I successfully mixed colors very well by combining flickering with dithering, which is easy on an 8-bit but very difficult on a 2600 (because of the difference in resolutions, plus the difference in the graphics features). Anyway, I found that colors could be mixed fairly well by using flickering with alternating scan line colors, rather than using dithering, but the results weren't quite the same. For example, a RYRYRYRY checkerboard pattern flickered with a YRYRYRYR checkerboard pattern creates a pretty good solid orange (but it tingles if you move your eyes), whereas alternating RYRY lines flickered with YRYR lines also produces orange, but it looks slightly different. This is due to the bleeding of colors that results when colors are put side-by-side on a line, such that using a dithered checkerboard design mixes the colors a little bit more because the colors bleed together on the TV screen. Without dithering, there is no color bleeding (if that's the right term to describe it), so the flickering still blends the colors, but they don't look the same. Dithering isn't really feasible on the 2600, unfortunately.

 

Michael Rideout

[+batari]

By the way, if you mix X colors, you don't get X-squared combinations, since some of them will be the same (e.g., yellow-red and red-yellow produce the same mix). You actually get X! colors (if I have the notation correct)-- that is, "X factorial" (if I'm using the correct term).

 

For example, mixing 8 colors gives you 8+7+6+5+4+3+2+1, or 36 different mixes.

 

So mixing 128 colors gives you 128+127+126+...+3+2+1, or 64*129 = 8256 different mixes.

 

Michael Rideout

963583[/snapback]

A factorial is the product of the numbers not the sum. 128! is an astronomically large number, on the order of 10^215.

 

What you're describing but it can be represented with "sigma notation" pretty easily... Just assume the "E" is an upper-case Greek letter sigma, and often the i=1 and n are left off without loss in generality.

 

n

E i

i=1

[Thomas Jentzsch]

n*(n+1)/2

[tmont]

n*(n+1)/2

963634[/snapback]

Thanks to our good buddy Gauss. So there should be (129*128)/2 colors available, which is some big number I don't feel like computing. But actually there's even less than that, since red+red = red, and that's already been counted as well. And there's probably other overlaps, too, like how red+blue=purple, which might already be represented by a single color. But I find this whole idea fascinating. I was thinking I could use my vast (i.e. not vast) knowledge of combinatorics and do 128 choose 2 (if I recall correctly), but that also won't account for the red+blue=purple phenomenon. Okay, I'm done.

 

 

Hmmm, all of those might be wrong, actually. It's been too long since I did any Discrete Math...

Edited November 11, 2005 by HeckYesIDid

[SeaGtGruff]

Okay, I used the wrong term, I guess an easy way to remember it is "factor" = multiply. The term I should have used is "triangular number." The number of different combinations of 128 colors is as I said, 129 * 64 = 8256. This assumes that two combinations are considered to be equal if they involve the same colors (e.g., color 30 mixed with color 46 is the same as color 46 mixed with color 30).

 

For example, the SECAM 2600 has only 8 colors, so the combinations are

 

color 0 mixed with color 0, 1, 2, 3, 4, 5, 6, or 7 (8 mixtures),

color 1 mixed with color 1, 2, 3, 4, 5, 6, or 7 (7 mixtures),

color 2 mixed with color 2, 3, 4, 5, 6, or 7 (6 mixtures),

color 3 mixed with color 3, 4, 5, 6, or 7 (5 mixtures),

color 4 mixed with color 4, 5, 6, or 7 (4 mixtures),

color 5 mixed with color 5, 6, or 7 (3 mixtures),

color 6 mixed with color 6 or 7 (2 mixtures),

color 7 mixed with color 7 (1 mixture),

= 8 + 7 + 6 + 5 + 4 + 3 + 2 + 1

= (8 + 1) + (7 + 2) + (6 + 3) + (5 + 4)

= 9 * 4 = 36 mixtures

 

The general formula is (X + 1) * X / 2, as Thomas said.

 

*However*, in actual practice the number of *discernible* mixtures produced can be considerably less than that, depending on the colors being mixed, and the method being used to mix them. For example, the GIF image I posted for the 8 SECAM colors (created in a paint program rather than on a real Atari) shows 36 mixtures, but some of them look very similar to each other. Using RGB color space to illustrate, mixing red [1,0,0] with green [0,1,0] produces dark yellow [.5,.5,0]-- the sum of the RGB values divided by the number of colors being mixed. Thus, mixing red [1,0,0] with cyan [0,1,1], or green [0,1,0] with magenta [1,0,1], or blue [0,0,1] with yellow [1,1,0] produces the same color-- gray [.5,.5,.5]. This assumes that the colors are being mixed as completely as possible, or as a single pixel. With flickering, or with alternating colors via interlacing, the original colors are still somewhat visible, so the mixtures may appear slightly different.

 

Applying this to the NTSC Atari's 128 colors, we can say that the mixture of two colors is the sum of the hues, divided by 2, and the sum of the luminances, also divided by 2. This isn't quite right as far as the hues are concerned, because it matters which hues we're talking about (e.g., hue 1 mixed with hue 15 is *not* hue . Nevertheless, in theory,

 

color 0 (hue 0, luminance 0) & color 14 (hue 0, luminance 14)

= color 2 & color 12

= color 4 & color 10

= color 6 & color 8

= "color 7"

 

The amount of flickering will be different, but if we could mix those colors exactly (and if the luminances follow regular steps), then the results would be the same.

 

Adding in the hues, we get similar results. For example,

 

color 20 (hue 1, luminance 4) & color 38 (hue 2, luminance 6)

= color 22 (hue 1, luminance 6) & color 36 (hue 2, luminance 4)

= hue "1.5", luminance "5"

 

Keeping in mind that the flickering is least when the hues and luminances are closest together, the best (least flickery) results are obtained by mixing adjacent hues and adjacent luminances.

 

So for any given hue, we can get 15 luminances-- the 8 luminances which the Atari can produce for that hue, plus the 7 luminances which are halfway between them (i.e., luminances 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, and 14).

 

And we can get something like 46 hues-- the 16 pure hues, plus 15 hues between the 15 pure colorful hues (i.e., hue 1.5, 2.5, 3.5, 4.5, 5.5, 6.5, 7.5, 8.5, 9.5, 10.5, 11.5, 12.5, 13.5, 14.5, and 15.5-- where "15.5" is hue 15 mixed with hue 1), plus another 15 hues which are the 15 pure hues mixed with hue 0.

 

Putting these together, we get something like 690 colors (15 luminances of 46 hues). Obviously, these aren't the *only* possible combinations. And if we can mix the colors using dithering along with flickering (as I've successfully done in the past on the XL/XE computers), we can get some pretty good mixtures using hues that are nonadjacent. For example, mixing blue with brown can produce dark green if we pick the right shades of blue and brown (think of brown as "dark yellow"). So it's pretty difficult to calculate the exact number of *practical* combinations that can be produced, but it's safe to say that it will be considerably less than X*(X+1)/2.

 

Unfortunately, all of this tends to work better on a TV than on a monitor, and it tends to work better with TVs that have lower resolution than with TVs that have higher resolutions-- at least, that's been my experience. This is due to the "color bleeding" that tends to occur when the TV has a lower resolution, especially when you dither two colors together using the smallest pixels that the Atari can produce.

 

Michael Rideout

[supercat]

Applying this to the NTSC Atari's 128 colors, we can say that the mixture of two colors is the sum of the hues, divided by 2, and the sum of the luminances, also divided by 2. This isn't quite right as far as the hues are concerned, because it matters which hues we're talking about (e.g., hue 1 mixed with hue 15 is *not* hue .

964051[/snapback]

 

Mixing non-adjacent luminances will not allow the creation of any new colors, but mixing non-adjacent hues will. Think of chroma (hue and saturation) space as being a disk. The center of the disk is gray, the outside edge contains saturated colors, and the areas in between contain somewhat pale colors. At moderately-low luminances, the 2600's colors (other than hue zero) are about 80% of the way to the edge of the disk; at higher luminances they're nearer the center. All of the 2600's colors other than hue zero are a circle, though.

 

Mixing colors will generate a new color halfway between the other two. If the two mixed hues are adjacent, the new color will be pretty close to being on the same circle as the 15 standard hues, but if the mixed hues are further apart the new color will be much more grayish.

 

There aren't a full 136 different colors available for each luminance level, but there are a more than 56 (grey, two adjacent colors, or one color and gray). I'd guess there are probably about 80 good distinct colors for each luminance.

Edited November 12, 2005 by supercat

[supercat]

For example, a RYRYRYRY checkerboard pattern flickered with a YRYRYRYR checkerboard pattern creates a pretty good solid orange (but it tingles if you move your eyes), whereas alternating RYRY lines flickered with YRYR lines also produces orange, but it looks slightly different.

963603[/snapback]

 

What you are describing is artifacting, a phenomenon which may be used when the dot clock is a multiple of the chroma clock (2x on the Atari 8-bits or the 7800; 2x or 4x on the Apple) and which is nothing but trouble on machines where color is line-synchronized but the dot rate doesn't match chroma (e.g. old Commodore 64's). On the 2x machines/modes, even pixels will appear different colors from odd pixels. On an Atari machine that can show 4 colors in 320-dot mode, it is entirely practical to use artifacting to generate 16 colors. There is some flexibility in choosing what those 16 colors are, but not total. Basically, just pick different combinations of four colors and see what combinations of 16 colors they yield.

[SeaGtGruff]

For example, a RYRYRYRY checkerboard pattern flickered with a YRYRYRYR checkerboard pattern creates a pretty good solid orange (but it tingles if you move your eyes), whereas alternating RYRY lines flickered with YRYR lines also produces orange, but it looks slightly different.

963603[/snapback]

 

What you are describing is artifacting, a phenomenon which may be used when the dot clock is a multiple of the chroma clock (2x on the Atari 8-bits or the 7800; 2x or 4x on the Apple) and which is nothing but trouble on machines where color is line-synchronized but the dot rate doesn't match chroma (e.g. old Commodore 64's). On the 2x machines/modes, even pixels will appear different colors from odd pixels. On an Atari machine that can show 4 colors in 320-dot mode, it is entirely practical to use artifacting to generate 16 colors. There is some flexibility in choosing what those 16 colors are, but not total. Basically, just pick different combinations of four colors and see what combinations of 16 colors they yield.

964068[/snapback]

 

I'm not talking about artifacting in GRAPHICS 0, where each pixel is only half of a color clock. I mean dithering in a high-res GRAPHICS mode (e.g., GRAPHICS 15) where each pixel is a full color clock.

 

Several years ago, I started working on the graphics for an adventure game, using brown, white, yellow, red, and blue as the basic colors in GRAPHICS 12 (red for bits 11 with normal characters, and blue for bits 11 with inverse characters). By choosing the right hues and luminances for the colors, I could get a pretty decent light green (blue and yellow) and dark green (blue and brown) to create, for example, a landscape of trees-- light green for the grass, dark green for the foliage on the trees, and of course brown for the tree trunks.

 

Dithering can be used with many patterns, but to get the appearance of new solid colors that are mixtures of two real colors, the pattern should be a checkerboard, with the colors in the pattern being alternated from one frame to the next (correct technical term should be field, but if the picture is noninterlaced, then each field is a frame). Without flickering between alternating color patterns, you just get a checkerboard dither of two colors, as in the standard paint programs for the Atari.

 

You can also make checkerboard patterns between a real color and a mixed color, which looks like the checkerboard dither of a standard paint program except one of the colors comes from a mixture. Or you can create dithers where the dots have a 75%-25% mixture rather than a 50%-50% mixture. So for example, if you start with yellow and red and your two real colors, you could get seven mixtures between yellow and red, with the middle mixture being a "solid" color:

 

100% yellow

75% yellow, 25% orange

50% yellow, 50% orange

25% yellow, 75% orange

100% orange (yellow and red mixed by dithering and flickering)

25% red, 75% orange

50% red, 50% orange

75% red, 25% orange

100% red

 

I used to have a demo screen that I made on the XL/XE which displayed a color wheel with real colors, "solid" mixtures, and dithered patterns between the "solid" mixtures and real colors. I programmed it so I could turn the flickering on or off by pressing a certain key, and the difference between the two was nothing short of dramatic. With no flickering, the same color mixtures listed above would be:

 

100% yellow

87.5% yellow, 12.5% red

75% yellow, 25% red

62.5% yellow, 37.5% red

50% yellow, 50% red

37.5% yellow, 62.5% red

25% yellow, 75% red

12.5% yellow, 87.5% red

100% red

 

On a TV, there may be some artifacting involved which creates "color bleeding" (don't know what else to call it) that helps to further blend the colors when using a dithered pattern in a high-res color mode, but I'm not talking about GRAPHICS 0 artifacting, and I haven't heard anyone use the term "artifacting" when describing the dithered checkerboard pattern that is commonly used in Atari paint programs to mix two colors together.

 

I experimented with artifacting in GRAPHICS 0 and GRAPHICS 8, but I was never able to create the "16 colors" that I had read about, just four artifacted colors which could then be dithered together.

 

These sorts of techniques are very easy to implement on an 8-bit Atari if you trick the Atari into thinking it's using a different GRAPHICS mode. For example, switch to GRAPHICS 8, POKE 87 with 9, and you can PLOT and DRAWTO using COLOR values from 0 to 15, the so-called "16 colors" that you get from artifacting. What you actually get are 16 combinations of four artifacted colors, but you can combine this with flickering to make the mixtures look more "solid." However, as long as you're just getting four artifacted colors that are being mixed together, it makes more sense to me to use four real colors in a high-res color mode. On the other hand, the artifacted colors are not the same as the Atari's real colors, and by using different hues and luminances with GRAPHICS 8 you can get different artifacted colors, so it might be interesting to combine GRAPHICS 8 with GRAPHICS 15 using a custom display list, and use flicker/dither with the GRAPHICS 8 lines to get some colors that aren't quite the same as if you were using GRAPHICS 15.

 

Michael Rideout

[+Andrew Davie]

All very interesting stuff. I thought I'd chime in and mention that the mario demo I did a long time back, now, also included a SECAM version which looked, for all intents and purposes, identical to the PAL and NTSC version. The trick I used was to dither the 1-bit colour-separated images (that is, separately dither (stucki) each of the red, green, and blue subcomponents of an image). If you haven't seen my chronocolour demos, you really should dig them up -- some are quite impressive even today.

Cheers

A

[SeaGtGruff]

All very interesting stuff.  I thought I'd chime in and mention that the mario demo I did a long time back, now, also included a SECAM version which looked, for all intents and purposes, identical to the PAL and NTSC version.  The trick I used was to dither the 1-bit colour-separated images (that is, separately dither (stucki) each of the red, green, and blue subcomponents of an image).  If you haven't seen my chronocolour demos, you really should dig them up -- some are quite impressive even today.

Cheers

A

965176[/snapback]

 

Hi, Andrew! Are you talking about flickering three frames together-- one with red dithering, one with blue dithering, and one with blue dithering? If so, I've heard of that idea before, but have never tried it or seen it in action. I'll do a search for your chronocolour demos, they sound intriguing.

 

Michael Rideout

[+Andrew Davie]

Hi, Andrew! Are you talking about flickering three frames together-- one with red dithering, one with blue dithering, and one with blue dithering? If so, I've heard of that idea before, but have never tried it or seen it in action. I'll do a search for your chronocolour demos, they sound intriguing.

 

Michael Rideout

965724[/snapback]

 

It's a little more complex than that -- the three red/green/blue frames are initially separated and dithered to 1-bit colour, but then recombined into three blended frames where each frame consists of groups of red/green/blue lines, repeated. The three combined frames are then displayed in succession, over 3 frames. Each frame displayed by chaging the colour on each successive scanline red/green/blue as appropriate for the particular frame.

Attached are some of the test/demo binaries from way back. Mostly NTSC, all should play OK in Z26. Some have bad scanline counts. Me bad! There are lots more demos hidden in the forums, somewhere. These are what I have handy.

Cheers

A

marioRGB_ICCPAL.bin

marioInterlaced.bin

3marioNTSC.bin

4kmario2.bin

GreetingCart_NTSC.bin

2600_2003.bin

[+stephena]

Attached are some of the test/demo binaries from way back.  Mostly NTSC, all should play OK in Z26.  Some have bad scanline counts.

Just wanted to add that these work fine in Stella, too.

[MayDay]

Wow, those are incredible. I take back what I said about thinking Mike Tyson's Punch Out is impossible, now I think about anything *can* be done... even if it shouldn't be in some cases. My whole idea of 2600 programming has been altered by these demos.

 

-JD

[ZylonBane]

Hi, Andrew! Are you talking about flickering three frames together-- one with red dithering, one with blue dithering, and one with blue dithering? If so, I've heard of that idea before, but have never tried it or seen it in action. I'll do a search for your chronocolour demos, they sound intriguing.

If you have an 8-bit Atari or equivalent emulator installed, you can check out a large library of images in ColorView (aka COLRVIEW) format. This technique was developed years before Andrew glommed onto it, renamed it, and oh-so-cheekily TM'd it.