I'll start this post listing the 2 layer order options found on the 2600. 1 is the top layer.

Order#1=
1:Player0, Missile0
2:Player1, Missile1
3:Ball, Playfield
4:Background

Order#2=
1:Ball, Playfield
2:Player0, Missile0
3:Player1, Missile1
4:Background

Okay I'll start with some setups and other uses for the sprite objects.

This first example demonstrates skipped scanlines and odd to even alignments using bit constructed sprites. Since it is being constructed one line at a time you can skip every second line and offset another sprite within the same vertical scanline zone using the same Bit Sprites. This is useful for text, background sprites, icons, anything static where you need more sprites horizontally but you've run out of free sprite objects and need to stretch your resources further. Cycle costs will vary on pattern complexity, the objects shown should be practical but the faces would likely need some vertical isolation to make up for more expensive drawing instructions.

I think it goes without saying that skipping lines works best under a 1 line kernel since a 4 line kernel would have some pretty big gaps to say the least. The alternative to skipping scanlines and offsetting there alignments is to render sprites in 2 passes instead of 1 where you render the odd lines and then another pass for the even lines which gets rid of the gaps but creates flicker and color bleed as a byproduct. Its a good method for very short text where skipped lines would destroy font legibility and also the thicker the lines get the faster and cheaper 2 pass rendering gets so that has some uses.

I'm not sure how specifically either method applies to Player object rendering although I have seen them rendered with alternating scanline rendering to achieve certain tricks. This is something I'll have to inquire about sometime.


Color bleed caused by flicker varies based on the frequency of flicker but I can explain the basics. If you render White pixels over a Black background with flicker you get grey and it will get darker the higher in frequency the flicker gets since in this example the Black background is visible more frequently being a constant and therefore is dominant to the viewer's eyes. It operates on the same principal as the "bird in cage" optical illusion.
Primarily color bleed reduces overall color palette usage as darker luminances become invisible and other colors are dependent on what you can actually blend together attractively. Actually programmers have gone to the extent of testing and producing flicker based color palettes since flicker factored so heavily into pushing beyond the 2600s limits.
Here's a good thread about it that has both visual and tech related jargon on mixing colors with flicker. It's more detailed and specific than I could ever get into.
http://www.atariage.com/forums/topic/98820-mixing-colors-with-flicker/


Okay I want to say one thing about flicker and that is to not fear it or avoid it completely as some of the best 2600 games include flicker as part of there rendering cycle, yes you want to minimize the degree of flicker overall so it doesn't offend the eyes but it should be regarded as just one of your many tools for making 2600 games.

Something odd about the TIA video output of the 2600 is it uses the actual TV hardware as part of its video card, by that I mean the output is generated on the TV as opposed to the console generating the picture for the TV to display. It was cost saving measure by Atari as the 2600 is extremely economically built even by 70s standards.

I bring this up on account of some differences in video output on modern flat panel displays in terms of flicker based rendering. The main one I heard about was automatic interlacing of 2 flicker passes into one visible image which was quite handy and offered certain code optimizations but it didn't work on every flat panel display unfortunately. Actually what I notice about flicker in general on modern TVs is depending on the engine it can get pretty bad at times EG. Contra on the Nes has acceptable sprite fallout but Toki looks awful on my LCD and I tend to play it exclusively on a CRT.

Generally speaking there are 2 main methods of flicker which are to render passes of the sprites as a whole full render top to bottom and the "Venetian Blinds" method of odd to even scanline render passes. Venetian Blinds look and work best on CRTs as the phosphor is kept lit quite well but often looks bad on LCDs and sprite flicker rendering of whole sprites looks good on LCDs but comes out dark and inconsistent on CRTs.
While this doesn't matter within an emulator it does represent a split in code base since 2600 code tends to get bloated and slow with options added like this(EG. Adding a player life display after the fact to Pitfall was a fair amount of work since the code was so trim and tight.), its more optimal to have one or the other while trying to include both is best left to stronger hardware platforms. I haven't seen examples of this but based on the use of separate ROM files for NTSC and PAL the CRT LCD difference is much like producing different ports or using double capacity carts and a startup menu to select a version to load.

The stock RF output of the 2600 was rather poor even when it was new that modding was inevitable for the future. The highest quality output caps off at S-video standard, the best mod I've seen so far is from the Longhorn Engineer which offers kits of various levels of completion and price.http://longhornengineer.com/atari-av-mods/
I bring it up since I've become displeased with the picture quality offered by my 2600 that I thought I should give you a heads up if you intend to acquire an Atari console and the picture quality is less than charming.

Here's a video of the Longhorn's AV mod in action, cover your kid's ears or turn the volume off because the guy demonstrating it swears like a trucker periodically. It's funny but if you're easily offended you've been warned. The video is quite good since he zooms in to show the sharp clear pixels possible with this mod.
http://www.youtube.com/watch?v=KzJkh_b8i4U



Here we have a Playfield using Tiling mode.


And here I've used the Ball object to create a wall on the left side. This was first used in the game Adventure to avoid the added costs of asymmetrical Playfield rendering. The same can be done with either Missile if you're willing to spend it on that task.


This example shows the use of the Player object as a background tile.

The top row uses a tall tile leveraging the unlimited height resolution possible with 2600 sprites. Typically using this setup would either limit you to a single Player entity or that all other sprites are constructed with the 3 loose bits.
The bottom row of blocks uses a variation on this setup instead isolating the curve portion to minimum size or a shorter vertical scanline zone and instead draws the black gaps at the sides over the Playfield pixels that make up the width of the block. Good option if you wanted a unique sprite within the middle of the blocks height using the same Player object as the corner tiles.
Actually here's a good spot to mention that the Player objects can flop horizontally but not vertically on account of the way the 2600 draws pixels that vertical flop isn't applicable thus being able to make any object sprite to incredibly tall heights if desired. In my block example a corner tile would simply switch from a top version to a bottom version when it got to that elevation of the screen.


Or you can skip burdening the movable objects and just try to make a Playfield equivalent.



I'd be remiss if I didn't mention scrolling on the 2600. Vertical scrolling is basically supported on the 2600 as the top to bottom nature of its pixel rendering cycles pretty much make vertical scroll a given. Horizontal scrolling is a different matter on the 2600.

This example demonstrates the 2 horizontal positions between each Playfield pixel width and how it requires supplemental pixels around its outer edges to achieve these states. These edge pixel positions are typically filled by Missile0,Missile1, and the Ball as they are stretchy appropriate objects to fill this need. Most of the time such systems include a certain amount of prerendered table data in the code kernel which is served best by repeating patterns instead of free form landscapes.
Other requirements include minimizing horizontal scrolling zones to small lanes or rows of short height (EG. Defender's urban landscape.). The isolation to a row or lane is optional but minimizing its vertical acreage will create zones where both Missiles and Ball can be used for other things (EG. Defender ship laser blasts.). I guess you could think of them as the 2600's version of parallax scrolling.
Beyond the initial restrictions things like Playfield edge smoothing with loose bits isn't possible with horizontal scrolling as all the "extra" pixel rendering can barely cover the needs of the interim positions of the scroll approximation that scrolling graphics have to be standard Playfield resolution.

The only other way to do horizontal scrolling is to fake it by moving the objects left & right relative to the player sprite which usually remains centered on the screen so it appears things are scrolling by. This setup needs a completely straight flat Playfield graphic to complete the illusion. (EG. Texas Chainsaw Massacre)


Although 3D games are sparse on the 2600 one dependable method is the race track engine approach seen in Pole Position since the perspective descends up into a vanishing point it works well with vertical scanline zone isolation as the sprites get smaller the higher up the screen you go which I use as a basis for discussing sprite scaling or rather the approximation of that through prerendered sprite states or LODs.

Because of the lack of sprite objects making a larger zoom state for a sprite will require larger and larger pixels. It comes down to the shear horizontal acreage you have to cover with the larger states and doing so with the fewest number of sprite objects and widths setting for each within. You might be able to make a more attractive zoom state sprite if you had only one sprite total like in a demo project but games need multiple sprites so you have to get each state or code kernel as frugal as possible in cycle use which on average is served best through coarse blocky resolutions.


I'll start Multi-color discussion with the standard approach used in most 2600 games which is creating holes in your sprites where a Black background shows through. If you're familiar with 1 bit color graphics on other platform like the ZX Spectrum then you probably understand the technique. Other good examples include Nes games that feature Black as a dominant or universal color such as Batman or Shatterhand. The basic method is to include holes that suggest outlines or deep shadows in the sprite like you would on other 8-bit platforms. Black has the benefit of being the most contrasted color in the 2600 color palette.

Personally I think Black is used way too much in 2600 games as background or "peek through" color as any 2 contrasting colors will work, I get the logic of it as in maximum contrast and it being a great outlining color but it gets dull.
The key thing is making sure the color placed over the background color is bright or dark enough to contrast since even the darkest tones in the color palette aren't nearly as contrasted as Black.

I should note some things about this example. It would likely take every object excluding one Player object for the gamer to use, and it would only be able to move up and down smoothly. Other than that it uses the Playfield for the bulk mass, the 3 loose bits to smooth its outer edge, a couple of color changes per scanline here and there, and the port holes use a Player object copied 3 times and since the propeller is lower I use the same Player object for that as well. Also I use the Playfield to render not just the ocean floor but also the sky above suggesting waves, if the Subfish never vertically intrudes into the waves it could probably be smoothed much like the sub is.
 Lastly this is a visual target not definite so its likely I'd have to adapt things if I used this in an actual game, usually just a little loss in precision of shape or compromising the shape based on the rigid horizontal positions allowed for each object and its copies.



This example was designed to show the variation on not just varying your 2 contrasting colors when defining sprites but also in how it can effect the construction of the sprite such as the cloud in this example. On a Black background the clouds outer shape defines itself simply through the pixels being opaque while on a Blue background I'm omitting the fill color and instead defining the shape through an outline.


Gradients?

You've probably seen plenty of examples of 2600 graphics that feature a Playfield with a color gradient across its vertical field since its fairly easy to invoke within the code kernel. I'll instead bring to light the issue of how ugly, obvious, overused, and contrasted it is to change the colors so much vertically when horizontally you can only do 4 per scanline by default. Its a hard nosed stance on the matter but I just think its used too much as visual gimmick rather than serving the art direction as a whole.
This is why I suggest letting the horizontal color limit dictate how much color you use vertically if only to create a better balance between the 2 and save cycles for other things.
The 2 primary methods I use to deal with X & Y axis color amount differences is dithering either through creating hole patterns with a single color for the background to shine through or the other which uses a transition of solid color then a dither of the previous color with the next color in line followed by the next color in the gradient and so on which approximates more shades but with fewer as I'm also alternating the vertical position of each color to either odd or even scanlines to create the illusion of more than 4 colors per scanline. The only limitation of odd to even alignment offset is the thickness of line used globally since 1 or even 2 line kernels will reap benefits from use but 3 or 4 line kernels aren't very compatible with dithering since the pixels are so large.
At the end of the day you'll have decide what to do, horizontal gradients beyond "holes" use Missile or Ball supplemental pixels which may be otherwise occupied depending on your game design or layout. I just wanted describe how you can make it happen given the restrictions.


I mentioned mid-line color changes as an option in regards to the Playfield rendering which allows more than one color per scanline. I was hoping for better news about it but this option isn't as versatile or cheap to render as changing colors vertically per scanline. I'd say the best case scenario is 2 colors per scanline using either the SCORE bit or using one mid-line color change at one of the supported distances.
One of the better adoptions I thought of was inspired by a mockup by 8bitbeard of a mountain climbing scene, this led me to a setup of half the screen with White Playfield for clouds and the other half with Dark Grey for mountain ledges with both sharing the same background color of Sky Blue. Since the 2600 can scroll vertically without additional sprite object assistance a game that focuses on traveling up & down seemed like a logical choice as I could spend my sprite budget on making it more pretty (EG using the Ball to smooth out the cliff face.). I should also mention that Pinball games are ideal for the 2600 rendering limitations as well since they too are vertically oriented and use objects with fixed positions.



3 or 4 colors per scanline?

This is the best example of 3 color changes per scanline I could show, here you can see one "color zone" with the border on the left, another color zone in the middle for the gem stack, and another color zone for the border on the right. I call it the best example since its mirrored and both the left and right zones match making it frugal to render despite the additional cost in cycles of having 3 horizontal color zones. Other examples include BMX Airmaster for its bike ramp and Robot Tank which I think is related to its rendering of large "3D" sprites.
Its safe to say mid-line color changes of the Playfield scanlines beyond 2 equal zones(Score bit) is a costly matter since it has no native hardware support that its best avoided unless you're willing to make sacrifices to visual quality and level layouts.

*I should mention that mid-line color changes can be applied to the Background layer as well, with 3 horizontal color zones you can actually define a square despite a complete lack of actual image resolution.

Thank goodness my buddy SeaGTGruff chimed in with some useful information on mid-line color changes and precision placement of the color zone border lines. The exact point where a color zone border can occur in the Playfield is at 3 color clocks or 6 pixels in my canvas. Anyway this gives you a good deal of options for the width of the 3 color zones.


He said based on Playfield pixel width that rounds up to every 3rd Playfield pixel if you want the color changes to line up with the Playfield pixel widths.


Based on this width increment I tried for the aforementioned 3 colors per Playfield scanline or 3 color zones so it would fit more evenly within the Playfield column layout which worked out to 12 Playfield pixels, then 16, then the remaining 12. You can put the 2 zone borders at any 6 pixel increment but if you want to use the Playfield in a tile like manner this is the closest division into 3rds.



The 2600 color palette?

I thought it might be worth discussing the color palette used on the 2600, although this is a digital approximation of an analog color palette its close enough to make judgments on its limitations. Generally speaking the 8 luminances available for each color(Well 7 and Black for the greys.) go from a small dark and saturated range to a heavy amount of light almost whitened brighter range of shades. In practice the 1st & 2nd brightest luminance of every color are so close that I often skip one and just use either one but not both in a row unless I'm doing an obvious gradient. What proves challenging is coloring things with desired color and saturation and still having sufficient contrast at the same time, most of the time I vary the Background color to try to balance the contrast of 2 sprites in opposing luminance ranges as in using a medium tone for the Background.

I tend to favor the darkest luminances of Green since the brighter range is just too minty for my tastes when trying to emulate the green tones on other gaming platforms.

The brown column is the best base colors for flesh and earth tones but with such limited colors per sprite you can risk humans disappearing in forests when they overlap one another. In between the Green and Brown columns are 2 ranges of brownish green which are kind of sickly with there green hue but the brighter range of luminances are brighter than the brightest brown shades so they can work as highlight tones for brown sprites. Also the darker Orange range(Last 3 shades.) can fill in for brown at times.

The standard Nes color choice of highlights in White and shadows or outlines being Black works just as well on the 2600 when applicable to rendering limits jsyk.

The red range pretty much sucks since only the last 2 darkest tones come close to the traditional Red we all know and love. Red pretty much changes almost immediately to Rose red and just gets brighter as you go up. I tend to favor the 3rd brightest Red for my traditional red needs.

Yellow,Orange, and Red Orange are fairly interchangeable for regular fire needs. The brightest Yellow is pretty much the closest you'll get to its primary color equivalent (EG. Pac-Man color ^_^.).

There is plenty of Blue and Magenta to play with, Blue has obvious uses but I never know what to do with Magenta other than Bubblegum or pink dresses.
Starting from the left going right after Magenta we have Purple, Navy Blue, Blue, Light Blue, Pale Blue.

Although Purple, Navy Blue, and Blue represent distinct colors they are close enough to match in a gradient or color ramp as for example the darkest Purple luminance is darker than the other dark blues. In this regard its possible to run diagonally through the palette.

Blue & Light Blue mix well as far as gradient, saturation, and contrast wise which I bring up only because the upper luminances in the palette don't differ enough for adequate contrast most of the time.

Pale Blue is kind of dead or drained of life that it could make a nice stormy ocean color or perhaps a colored metallic. You could use it for creatures but it lacks warmth so in someways it would be better for a sickly tone or for the look of the undead.

In those rare contexts where you actually have maximum control over the choice of colors and resolution put into one subject matter IE. an art slide you're going to have to aim for hue approximation most of the time much like C64 pixel art as in the smoothest color ramps rather than a traditional gradient (EG. bridging with greys or other differing colors.).


ANSI art? I think the artist's name is within the image translation.

ASCII art is pretty much out of the question since text rendering is not a strong suit of the 2600 but ANSI based art is more viable. This example takes a safe approach employing only the Playfield for the bulk of the image rendering. Here I just created Playfield based scanline dithered equivalents of the blocks used in ANSI art and replicated there positions within. It's very basic and plain but it gets the job done.

Here a more refined approach.

This work is far from complete but I wanted to mention it right now. What I'm seeing so far is the need to use quadruple width resolution as a visual standard since although the Player objects can produce a good double wide block graphic of dither the bit constructed variants can only cover decent amounts of screen width distance if I set the Missile and Ball width to 4 pixels wide to get as many dither blocks in a row as possible. Also note the use of Player object blocks drawn to wider resolutions rather than actually being stretched by hardware so they match there bit constructed counterparts at the wider resolution visual standard but don't cancel out Missile bits.

As you can see the denser dither patterns can actually be rendered partially with the Playfield while lighter less dense dither requires more and finer gaps which only the Player object can do effectively. Need to work on this more but I think that's enough to get the basic method and limitations of doing ANSI style art on the 2600.

Traditional dither test:

Here I tried the standard 5 variations of dither pattern common to pixel art at 3 pixel widths of 2,4,and 8 or Playfield standard. While 2 and 4 pixel widths worked normally the 8 pixel width option required both more vertical pixel spacing and 2 additional dither patterns(wavy lines) to smooth out the dither transition and stop banding within an 8 bit wide Playfield bank. I could likely normalized the 8 pixel width variation if I stepped up to 2 Playfield banks or 16 bits wide but that would result in an enormous dither transition that would be hard to fit on screen at once.
Strong color contrast definitely looks worse the wider you make a pixel unit that you'll likely want to stick to the least amount of contrast especially with 8 pixel width units which primarily resides in the brightest luminescences of the 2600 color palette.
While a gradient invoked in the Playfield or Background will offer a smoother gradient it doesn't contain any texture and dithering a gradient does have the advantage of requiring less color interrupts per scanline which does make for a trimmer display kernel simply from less color changes per line.

Anti Aliasing? Short answer no usually, long answer...

You only really have 2 main options of horizontal streaking dither or employing one of the 3 loose bits to render the aliasing colors. Despite such large pixels in the Playfield the same basic rules apply to dithering on the 2600 which include mostly gross large scale use with small scale turning to noise when dithering is applied. Despite CRT blur I tend to look to the future and avoid high contrast colors when dithering so graphics will look good on both new and old display technology, it worked for Capcom it will work for you.
Using actual aliasing is a highly contextual setup to use on the 2600 best left to demos and title screens since it would be very difficult to design a game around its limitations. Your strongest usage lies in working with Missile copy gap distances as to avoid the employment of yet another Missile or the Ball for every occurrence. Its easy to assume you will be limited to primitive shapes and repeating patterns in this pursuit. Regardless the line being drawn with Missile changes shade per scanline smoothing the difference between the 2 colors you'll likely be restricted to within your specific height resolution zone.
Wish my example was better but I'm only fair at manually aliasing pixel art but I keep trying.

Here's some examples of dithering and aliasing from my attempt at porting Shadow of the Beast to the 2600.


Still it demonstrates dithering within the Playfield resolution quite well.


Since the Playfield pixels are much wider than they are tall even when you thicken the scanlines the difference in resolution is very obvious. The best you can do in a Playfield drawing to make lines appear thinner is to omit lines to make it look less solid and more thin. As you can see there is a limit to how much you can omit as it just turns into pixel noise and the line disappears.


Its best to try and find a compromise between details and solid color or solid dither color zones as the coarseness can really degrade an image into unspecific homogeneous noise. It can be tricky to balance symbolism with specific pixel detail.

I gave a go at dithering the Playfield within a 2 line kernel.

What I'm seeing already is I'm macro-sizing the bitmap size just to define the texture better with the taller pixels. Based on this I'd say the number of viable dither shades will lower as you thicken the lines and you'll have to use dither shades with higher density contrast between each shade just to keep the difference apparent and keep the image from turning into noise.
Because of this thicker line design should probably lean towards more colors through color changes per scanline per sprite object which actually makes sense since often thickening the lines is used to help towards the cycle costs of invoking color changes per scanline.


Multi-color is the most common term used for making 2600 pixel graphics with more than 4 on screen colors, while 4 is the limit horizontally changing the color per scanline in each object will increase the number of on screen colors.

Increasing the number of colors horizontally is extremely sparse and costly to render with the Playfield capping off at 3 at most which based on its CPU costs won't work with every single game design. 2 colors per Playfield scanline is practical when it occurs at the center but when placed off center still comes at a cost that may limit what you can do overall. The sprite objects(Player0/Missile0/Player1/Missile1/Ball) also can have mid-line color changes per scanline but the timing and horizontal distances between color changes have the same width restrictions(Every 3 color clocks or 6 pixels) plus CPU costs making this option very limited in uses except if you design towards that limitation like in a HUD or menu but it gets hard to apply to game sprites. Because of this I suggest working within the defaults instead of relying on rendering tricks as much as possible.

I'll go over the basic color limit of each sprite object. Note this is if each object has the same scanline alignment since scanline isolation will allow independent colors for each.
-The Playfield and Ball share the same color default.
-Player0 and Missile0 share the same color default.
-Player1 and Missile1 share the same color default.
-The Background is only one color total.

So the basic rule of adding another color horizontally per scanline comes at the cost of spending one sprite object set to that intended color. Beyond the large sacrifice of one of the very few sprite objects we have to use it also creates a requirement that every occurrence of that object regardless of shape will be set to that color for each individual scanline those sprites reside on and there copies.

Here's a basic example of plotting logical color zones vertically in a game. I used this for a platformer game to work out the average height of each color zone where I intended to add a color change vertically across the Playfield. I went with a logical order of the top row being being black for HUD space, followed by white for a cloud zone,then various colors for the platform blocks, and then the last row or lane being my ground color zone. From there you can work out further color changes per individual zone. A good example of this color distribution can seen in Keystone Kapers which is the closest equivalent I've seen to Super Mario Bros. on the 2600.

I know it doesn't really line up but things change in practice. Despite being a rather ambitious/dubious visual target it will suffice for this description. It at least demonstrates how plans can change when faced with the reality of rendering setups. I should credit PAC-MAN-RED for the Mario sprite with the highest color count that I used as a base for the other variations.

I thought the ground couldn't be done efficiently but if I use the Background to create the light green block and layer the Playfield of dark green over it that should work.

The pipe bells are colored yellow as I assigned that color for that vertical zone and I've varied it to outline and shadow it but I also used a Missile1 segment to create the edge shadow on the right side. Okay I've just boxed myself in since I wanted to use Missile1 for the turtle as part of a bit construct but its busy doing a pipe shadow lol. My best option is to make the turtle with Player1 instead of a bit construct made from Missle0 & Missile1, I wanted to allow at least 2 enemies to occupy the same vertical space but that would only work well if both sprites were a single color otherwise one would corrupt the colors of the other. I think I'll just keep them vertically separate instead so they can share the same object. This means Goombas with Vertigo as in fear of edges or falling. Actually much of the problems associated with the pipe side shadow rendering could be avoided if I accepted Black or another dark color as the default Background color and just created holes for it to show through.

Okay despite the Piranha Plant & Thwomp being part of this mockup I never intended them to exist on the same screen since they both use Missile1 and the Ball so only one or the other per screen but not both unless I can keep them from aligning horizontally with careful positioning.

The platform Blocks are a combo of Playfield,Missile0, and Missile1 where I've offset light red and black in an odd & even scanline alignment so they can share the same object, plus I vary the width of the Missile bit every other black line. This will mostly be a challenge of getting the copy spacing to align gracefully with the block layout, may have to flicker or strobe some copies to more ideal horizontal positions if it proves too difficult.

Next we have Mario and a Goomba which are Player0 and Player 1 or your basic player & enemy division of sprites. Seperate objects so seperate color schemes. I'll have Mario throw the Ball object for his fireball and limit it to only one active Ball which clips after a certain number of seconds not unlike Super Mario Land on the GB. Since we have objects sharing different duties color dominance becomes an issue between the platform tiles and sprites. Since Mario and the Fireball are smaller we let the platform tiles color them in those instances meaning the fireball will change color as it bounces around and Mario will strobe briefly as he passes through each platform blocks color zone. Its a bit glitchy but I'm willing to accept the consequences of enhancing the background graphics.

Next up the breakable blocks which are built from Playfield for the main brick part where I'll leave spaces and fill the ? blocks with a Missile bit as that's the easiest way to give them a separate color. The ? icon would likely use Player 1 to avoid the complication of creating it with a bit construct but the bolt pattern is simple enough to bit construct so we can avoid any multiplexing flicker issues if it shared Player0s scanlines with Mario as he passes through those vertical spaces often. Clipping parts of the Playfield has been done since Pac-Man, Dig Dug, Centipede, etc. all use Playfield alteration as part of the gameplay structure meaning something could be worked out for smashing and eliminating blocks. Also Mario Bros. on 2600 had upward block bumping animation so the different behaviors between large and small Mario can be accomplished.

Then clouds which are pretty much a repeat of the platform graphic in construction but without the interaction or clipping needs.

And lastly the top row for the HUD which gets its own lane so it can go about the task of rendering text unhindered by any other sprite needs. Despite being able to walk over the stats in the original SMB you sure can't do that on an Atari.

Well it started as a discussion of multi-color use and it became a total restructuring of how I'd approach SMB on the Atari. Still you have to work out ahead of time what object renders which sprite, the average costs of any rendering tricks needed, and possible graphical step downs for everything involved.



I'm going to say as a general guideline the pursuit of multi-color doesn't just come with CPU costs but also limits your gameplay structure at times just to keep the visuals "solid" and consistent. A good example is Grand Prix on the 2600, it looks nice but the gameplay is incredibly limited just to maintain its graphics standard.

 I keep coming back to the polygon analogy to describe how graphics limits work on the 2600 as every graphical enhancement adds rendering cost just like increasing poly counts or effects passes as it dictates what you can do in the game as a whole while tilemapping is more about the palette limits of all tiles as a group since you're never limited in the number of tiles that can be rendered on screen nor are you restricted in the design of its form.

Something that can reveal more than I can ever describe about object distribution in 2600 graphics rendering is if you download the Stella emulator and try the debug mode on some game ROMS (Alt+Comma on Windows/Linux) as this will show the method employed if you're trying to make a particular type of game and need to know the way the 2600 achieves that.
http://www.atariage.com/2600/emulation/index.php?SystemID=2600
http://www.atariage.com/system_items.html?SystemID=2600&ItemTypeID=ROM


Multi-color Sprites?

If I had any advice for sprites on the 2600 is to either prepare to reduce quality to get the desired gameplay within your cycle budget or alter and scale back gameplay to cater to your visuals.

Here's a couple familiar characters I've tried to translate into 2600 form, I decided to give myself carte blanche in width resolution suggesting a setup with Missile and Ball based pixel extensions so its plausible but would be a rather limited game with only 1 or 2 sprites per vertical zone at most for the most colorful versions if at all. Regardless it demonstrates the basic color techniques and layouts used with early Atari sprite design.

-Despite the dubious nature of my highest color variant the concept behind it is sound which is to share colors between both Player objects by using the opposing Missile on the opposing Player object to create instances of 2 colors per sprite scanline as well as leveraging the Ball for a limited use of a 3rd color. I say dubious because despite these two guys sharing the same colors the setup would work better if they had roughly the same height and build(EG. River City Ransom) so the vertical color zones wouldn't be so different from each other. Perhaps you'll have more luck with this setup than I did.

-The most basic step down is using a single color instead of using interrupts to change the colors per scanline. I'd say this option works better under a 1 line kernel setup as the single color will have you carving outlines and shapes into the sprite thus more height resolution equals better results. It truly comes down to making sure the forms are readable with this option and maintaining contrast between your foreground and background color, which a lot of 2600 games failed at in the pursuit of using every single color put before them.

-As you can see a 2 line single color sprite isn't a simple transfer from the 1 line version, it instead has to be optimized to its own standard often times adding height just to define forms better.

-Using basic color changes per scanline in the sprite is the most reliable way to increase the number of colors per sprite as it confines its color influence to itself which is the main drawback of mixing objects for more colors. Probably the hardest thing to deal with in the color changes per scanline is the vertical orientation as it only works well if your character is standing upright but it can't deal with rotation or diagonal slanting of character poses. The only leeway I've found in slanting or irregular section borders is to use a gradient to smooth the difference between these very short instances while drastic orientation changes need to default to a single color or consider overlays.
When switching from one color to the next I'd suggest avoiding total omission and instead outline forms with this differing color as you don't want entire body parts clipped off when one color zone dominates another.

The 2600 be a harsh mistress for any pixel artist as it demands much and offers little compromise. I'd say most of the time 5200 sprite work is transferable to the 7800 or even the C64 with some palette changes but much of 2600 sprite design is so specific to said platform that it only really supports itself unfortunately.
One minor exception is the Intellivision since when the 2600 uses a 2 line kernel they then share the same basic screen resolution if not the same on screen color count or the number of sprites possible per scanline, still is offers a rudimentary base for cross platform support.

I should mention mid-line color changes as it applies to Player objects. The 3 color clock or 6 pixel distance used in mid-line color change is a fixed value so using it to change the color of Player objects requires horizontal color zone borders to line up favorably with the copy gap distances.

In Medieval Madness the 4 player score numerals are spaced correctly so that they can have 4 unique colors. Also the Playfield use a combo of mid-line color change and the SCORE bit to create instances of unique colors in the Playfield as well such as the crowns and the section of wall next to them.


For reference here's a fellow making 5200 games which discusses in part the challenges of layering Players and Missiles, the 5200 uses more objects than the 2600 but I think it is still relevant to the 2600 subject matter.
http://cafeman.www9.50megs.com/atari/5200dev/KoffiArchives.html

Also here's Atari sprite work by PAC MAN RED who is quite good and a good reference point for Player object based sprite art.
http://www.atariage.com/forums/topic/169238-free-sprites-for-the-taking/

And for inspiration the Homebrew available at AtariAge, plenty of screenshots and reviews.
http://www.atariage.com/store/index.php?l=product_list&c=24

Plus the games that will hopefully eventually be for sale.
http://www.atariage.com/development_list.html