Jump to content
IGNORED

Mixing Colors with Flicker


SeaGtGruff

Recommended Posts

Here's a program I wrote in batari BASIC to help me explore color combinations for color mixing. It draws a 3x3 grid of colors that are blended together using flicker. You can use the joystick to change the colors and see the effects, or turn off flickering to see the odd and even frames by themselves.

 

The 3x3 grid is arranged as follows:

 

Column 1 = Background color on odd-numbered frames

Column 2 = Playfield color on odd-numbered frames

Column 3 = Player color on odd-numbered frames

 

Row 1 = Background color on even-numbered frames

Row 2 = Playfield color on even-numbered frames

Row 3 = Player color on even-numbered frames

 

(For this program, both players are set to the same color, but of course you can set them to different colors when mixing colors in your own programs. I'll probably write another version of this program sometime that has a 4x4 grid with the background, playfield, player0, and player1 colors.)

 

When the program starts, the colors are frozen, so you can't change them with the joystick. Notice that the score is 000000. To select a color to change, press the SELECT switch, and notice that the score changes-- from 100000, to 010000 (if you press SELECT a second time), then 001000, etc. The position of the 1 tells you which of the six colors you can change, as follows:

 

000000 = All colors are frozen

100000 = Background color on the odd frame can be changed

010000 = Playfield color on the odd frame can be changed

001000 = Player color on the odd frame can be changed

000100 = Background color on the even frame can be changed

000010 = Playfield color on the even frame can be changed

000001 = Player color on the even frame can be changed

 

Once you have selected a color to change, moving the joystick will change the color as follows:

 

RIGHT = Increase the hue of the selected color

LEFT = Decrease the hue of the selected color

UP = Increase the luminance of the selected color

DOWN = Decrease the luminance of the selected color

 

The hue and luminance values will scroll-- i.e., if you increase hue 15, you'll go to hue 0; and if you decrease luminance 0, you'll go to luminance 14. (Quick review: The Atari 2600 has 16 hues, which have values from 0 to 15; and 8 luminances, which have even-numbered values from 0 to 14.)

 

Pressing the joystick's FIRE button will cycle through three display settings, as follows:

 

Setting 1 = Two frames (odd and even) are flickered together

Setting 2 = Only the odd frame is displayed

Setting 3 = Only the even frame is displayed

 

The following screenshot from the z26 emulator shows the initial color mixtures, which I chose to try to get the widest range of basic colors. However, the colors may not look this way on a real 2600, as emulator palettes tend to be slightly different from the colors on an actual 2600 (as well as between different emulators), plus the flickering effect will be somewhat different on a TV set (as well as with different emulator "phosphor blending" settings).

 

post-7456-1166331249_thumb.jpg

 

For comparison, here are screenshots of just the odd and even frames:

 

post-7456-1166331307_thumb.jpg

 

post-7456-1166331335_thumb.jpg

 

Normally (i.e., without flicker), you can get multicolored sprites using one of two different methods:

 

(1) You can overlay two or more objects on top of each other, such that the color of an object shows through the "empty" pixels of the objects which are on top of it.

 

(2) You can change the color of an object-- usually from one scan line to the next, but also while a scan line is still being drawn.

 

Mixing colors with flicker gives you a third method for creating multicolored sprites.

 

As with almost everything in life, each of these three methods has its own particular benefits and drawbacks:

 

Overlaying objects doesn't give you more than the usual four colors (i.e., background, playfield/ball, player0/missile0, and player1/missile1); there could be positioning problems when moving a sprite (e.g., if a player is being combined with playfield pixels); and it can limit the number of objects that are on a line (e.g., if both players are combined, then they can't be used for two separate sprites).

 

Changing an object's color on the screen doesn't let you use different colored pixels on a given scan line-- unless the object isn't moving horizontally, in which case you can change its color mid-line; but then there can be positioning limitations, since color changes can occur only at certain locations on a scan line due to 1 machine clock being equal to 3 color clocks-- and changing an object's color on the screen can also use up precious machine cycles on a scan line, so you're limited by time constraints as far as how many color changes you can make on any given scan line.

 

Flickering colors to get color mixtures can produce "muddy" looking colors, or the flickering can be annoying if the colors being mixed are too different-- especially if their luminances are very different.

 

Of course, any or all of these three methods can be combined with each other, which will give you the greatest number of colors on the screen.

 

One of the advantages of using flicker to get more colors is that only one object needs to be used. For instance, if you flicker player0's color from one frame to the next, and change its shape as well, you get a sprite that can have pixels of three different colors, and you still have player1 to use for another object on those same scan lines. And by flickering all of the objects on the screen, you can get three playfield colors, three player0 colors, and three player1 colors on each scan line, as follows:

 

Playfield_Color_1 + Background_Color

Playfield_Color_2 + Background_Color

Playfield_Color_1 + Playfield_Color_2

 

Player0_Color_1 + Background_Color

Player0_Color_2 + Background_Color

Player0_Color_1 + Player0_Color_2

 

Player1_Color_1 + Background_Color

Player1_Color_2 + Background_Color

Player1_Color_1 + Player1_Color_2

 

Of course, you have to choose the colors carefully to get the best results, and you're limited by the different possible combinations (e.g., you can't flicker red with blue to get green). Also, it often helps to flicker the background color as well-- although if you do, the choice of colors is even trickier.

 

That's where this utility program can come in handy. I actually created it with Tetris in mind, because I was thinking of overlaying and flickering the playfield and the two players (plus the background) to get the different colored blocks in Tetris, as follows:

 

+--+--+--+--+--+--+--+--+--+--+
|  |  |  |  |  |  |  |  |  |  |
+--+--+--+--+--+--+--+--+--+--+
|  |  |  |  |  |  |  |  |  |  |
+--+--+--+--+--+--+--+--+--+--+
|  |  |  |  |  |  |  |  |  |  |
+--+--+--+--+--+--+--+--+--+--+
|  |  |  |  |  |  |  |  |  |  |
+--+--+--+--+--+--+--+--+--+--+
|  |  |  |  |  |  |  |  |  |  |
+--+--+--+--+--+--+--+--+--+--+
|  |  |  |  |  |  |  |  |  |  |
+--+--+--+--+--+--+--+--+--+--+
|  |  |  |  |  |  |  |  |  |  |
+--+--+--+--+--+--+--+--+--+--+
|  |  |  |  |  |  |  |  |  |  |
+--+--+--+--+--+--+--+--+--+--+
etc.	  ^
	  |
   playfield pixel,
   quad-width player pixel,
   or both (flickered together)

Since there are 10 blocks or spaces on each row of Tetris, both players would need to be used, and set to the same color-- or better yet, one of the players could be used with both missiles (since that would leave the other player available for showing the preview of the next Tetris shape alongside the playing area).

 

Thus, each block could be one of nine different colors (shown by the utility program), as follows:

 

Background_Color_1 + Background_Color_2

Background_Color_1 + Playfield_Color_2

Background_Color_1 + Player_Color_2

Playfield_Color_1 + Background_Color_2

Playfield_Color_1 + Playfield_Color_2

Playfield_Color_1 + Player_Color_2

Player_Color_1 + Background_Color_2

Player_Color_1 + Playfield_Color_2

Player_Color_1 + Player_Color_2

 

Anyway, I hope this color-mixing utility proves to be helpful for anyone who wants to experiement with mixing colors through flicker.

 

Michael

color_mix_test.zip

Link to comment
Share on other sites

Good grief, that was a detailed explanation.

I drive my bosses crazy with explanations like that! :P

 

Very awesome!

Some of the mixtures are amazing as far as the number of different colors they produce-- but it's probably best to use the utility program on a real Atari 2600 and a TV, since the results can vary from what an emulator shows.

 

I'm ashamed to admit it, but I have both a Cuttle Cart 2 and a Krokodile Cart, yet I can't run my programs on a real Atari 2600 or 7800 right now. I can't remember where I put my Cuttle Cart 2, and the Krokodile Cart uses a serial connection-- but my computer doesn't have a serial port, and I keep forgetting to buy a serial-to-USB adapter! :roll:

 

[Rummages around in purse] "Where did I put my brain today?" *

 

Michael

 

* Scene from an old Bob Newhart Show episode

Link to comment
Share on other sites

Lots of experimentation was done about 5 years ago with colour interlacing techniques starting with methods similar to that which you describe. A more generic system is to multiplex RGB colours to form an "unlimited" palette. This can effectively be achieved by dithering the 1-bit frames. Unfortunately, the posts discussing these techniques don't seem to be in the forum anymore, nor do the binaries. Such a shame. I attach some of the experiments that lie handy on my hard drive; there were some really really interesting techniques involved. Most of these demos use RGB line multiplexing with dithered single-bit layers for each colour channel, with a rolling palette change per-line.

Cheers

A

boringNTSC.bin

fade.bin

FuKung.bin

GreetingCart_NTSC.bin

marioInterlaced.bin

marioRGB_ICCPAL.bin

ICC_NTSC.bin

SpastiColour_Marilyn_NTSC.bin

spiralwords.bin

FullScreenBitmap.bin

Link to comment
Share on other sites

SeaGtGruff, this demo is very interesting, try change the luminance of backgrond, and you will see the flicker can be more soft. I start to program my own, but is more simple, just 2 colors mixing to get a third ilusion color. Using this we can get a new rage of colors, never seen before in a 2600 game :)

 

Andrew Davie, I see this interlancing technique in stella mailing list, a clown demo, but this demo of 3 mario is awsome!

There a way for I get more info about interlacing? I realy want understand this. :D

Edited by LS_Dracon
Link to comment
Share on other sites

Thanks for posting all of those, Andrew! I'd seen the clown and Mario demos, but not all the others. You're right, the RGB method produces more combinations than mixing just two colors can. The only drawback is that 20Hz flicker (NTSC/60) and 17Hz flicker (PAL/50) are more apparent than 30Hz and 25Hz. Personally, I don't mind flicker, because I think the advantages of using it (more colors, more sprites) make up for the disadvantages. And the interesting thing about the RGB method is that it's similar to one of the early methods used many years ago to produce color TV pictures. :)

 

http://www.earlytelevision.org/early_color.html

http://www.earlytelevision.org/cbs_color_system.html

 

Michael

Link to comment
Share on other sites

Thanks for posting all of those, Andrew! I'd seen the clown and Mario demos, but not all the others. You're right, the RGB method produces more combinations than mixing just two colors can. The only drawback is that 20Hz flicker (NTSC/60) and 17Hz flicker (PAL/50) are more apparent than 30Hz and 25Hz. Personally, I don't mind flicker, because I think the advantages of using it (more colors, more sprites) make up for the disadvantages. And the interesting thing about the RGB method is that it's similar to one of the early methods used many years ago to produce color TV pictures. :)

 

http://www.earlytelevision.org/early_color.html

http://www.earlytelevision.org/cbs_color_system.html

 

Michael

 

Very interesting links, thanks. Many people have worked on colour systems, and it's interesting to read about these early efforts. As it happens, mechanical TV is one of my other interests :)

 

Cheers

A

Link to comment
Share on other sites

Andew Davie, if I'm not wrong, televisions have 4 electron beam, 3 for colors (rgb) and one for white.

The white you can mixing the 3 colors, but white beam is used for change the luminance...

 

Well wrong or not I try to use it in interlacing code, and yes! I can a good result!

 

I use a grey, becouse white already exist. See my demo below.

 

Good part :

With grey, we have DOUBLE number of colors.

Now is possible draw images with contrast (the grey give more bright for other colors)

Better images with shadow/bright

And of course, now we have a grey color to use.

 

Bad part :

The flicker is more perceptive (I don't care about this, becouse we have a double numbers of colors to use)

The contrast aren't much efficient.

I need made more experiences, so it's a beta. (Run in Z26, Stella had more bright colors, and the grey turns to white)

 

Ah, there other thing, grey need be used with high value (#$0A to up) and colors need use a low value (#$x2)

rgb_grey.bin

Link to comment
Share on other sites

Good part :

With grey, we have DOUBLE number of colors.

Now is possible draw images with contrast (the grey give more bright for other colors)

Better images with shadow/bright

And of course, now we have a grey color to use.

 

Another option would be to use four colors, with half the scan lines flickering two of them and the other half flickering the other two. That would give you four things to blend, at 25Hz flicker, at the cost of losing half your vertical resolution.

 

A further consideration is that if you can afford to have two colors plus black on each scan line (e.g. you overlay a 4x sprite with the playfield) you can greatly increase versatility without increasing flicker.

Link to comment
Share on other sites

if I'm not wrong, televisions have 4 electron beam, 3 for colors (rgb) and one for white.

Actually, color TV sets have only three electron beams-- red, green, and blue-- and mixing all three together at their brightest luminances creates white. The beams themselves have no color-- they're just streams of electrons-- but each beam is aimed and "masked" (using some kind of object, such as an aperture grill) so that it (ideally) hits only the red, green, or blue phosphor dots on the screen.

 

Michael

Link to comment
Share on other sites

A further consideration is that if you can afford to have two colors plus black on each scan line (e.g. you overlay a 4x sprite with the playfield) you can greatly increase versatility without increasing flicker.

 

True.

You can use one player for black base... but need a better machine, atari 5200 to up...

 

Actually, color TV sets have only three electron beams-- red, green, and blue-- and mixing all three together at their brightest luminances creates white. The beams themselves have no color-- they're just streams of electrons-- but each beam is aimed and "masked" (using some kind of object, such as an aperture grill) so that it (ideally) hits only the red, green, or blue phosphor dots on the screen.

 

Hehehe right... :D

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...