Author Topic: Atari 2600 Pixel Art Guide  (Read 10361 times)

Offline BladeJunker

  • 0001
  • *
  • Posts: 84
  • Karma: +0/-0
  • Know your limits, then break them.
    • View Profile
Atari 2600 Pixel Art Guide
« on: March 01, 2012, 02:25:52 am »
Hello, long time lurker (about a year), big fan of this forum, and just signed up today. :)

I could ask where is all the Atari 2600 pixel art at but I already know the answer. The 2600 is shall we say "resistant" to art to say the least lol. If you've never delved into a TIA manual I can tell you its amazingly complicated for what amounts to a very basic graphics hardware.

So what am I here about?  Well I'm crafting a sort of artist's guide for 2600 based sprite design, techniques and methods that work well within its unique limitations. The aim is to foster a greater following in Atari 2600 based pixel art to something along the same lines as the C64 has in demos and those that enjoy drawing within any specific hardware limit challenges. I feel there is a rift between pixel art and the 2600 I'd like to bridge.

My guide is nowhere near complete so I'm mostly just testing the waters on whether there is any interest in this idea. I'm far from an expert but I have been experimenting within these limitations for several months, consulted at AtariAge on the feasibility towards rendering, and have found many "standard" methods and practices for adapting most common pixel art types (Sprite sizes, Portraits, Title Screens, Genres, etc.) to a compatible 2600 equivalent.

Anyway too early for a submission yet but I'd like to hear everyone's thoughts on the subject, anything really, perhaps someone has already done this?

Never stop drawing,

Bladejunker :D

« Last Edit: April 17, 2012, 05:42:58 pm by BladeJunker »

Offline HughSpectrum

  • 0010
  • *
  • Posts: 279
  • Karma: +0/-0
    • View Profile
Re: Atari 2600 pixel art?
« Reply #1 on: March 01, 2012, 02:54:00 am »
I find the Atari 2600's restrictions to be fascinating because it's so different from even the most limited computers and the quirks go beyond the resolution.

Do you have any examples of games or game mockups to give an idea of how an Atari 2600 game might look in the hands of a seasoned pixel artist?

Offline Kasumi

  • 0010
  • *
  • Posts: 167
  • Karma: +1/-0
    • View Profile
Re: Atari 2600 pixel art?
« Reply #2 on: March 01, 2012, 04:48:40 am »
There's this topic that has posts about the limitations of various consoles that caters to pixel artists. Atari 2600 is not on the list, and I'm sure if you made such a thing someone would appreciate it.
I program NES games. Thus, I'm the unofficial forum dealer of too much information about the NES.

Offline BladeJunker

  • 0001
  • *
  • Posts: 84
  • Karma: +0/-0
  • Know your limits, then break them.
    • View Profile
Re: Atari 2600 pixel art?
« Reply #3 on: March 01, 2012, 05:53:28 pm »
I find the Atari 2600's restrictions to be fascinating because it's so different from even the most limited computers and the quirks go beyond the resolution.

Do you have any examples of games or game mockups to give an idea of how an Atari 2600 game might look in the hands of a seasoned pixel artist?

I know what you mean since the early Atari hardware is nothing like a Nes or ZX Spectrum, such a basic pipeline for graphics.

I do have many examples but it was tricky to pick ones that wouldn't create false expectations at this premature stage in my research as it is incredibly easy to exceed the 2600s rendering limits, hence a lot of neat looking but impossible 2600 mockups we see every day which was what sparked my interest.

Something I'd like to mention is that much of this work uses other peoples characters since its easier just to grab an existing image and translate it so if you recognize something credit the original artist or shout yourself out. I would do so every time but saved image file reference doesn't always contain the artist's name and I forget where I find things originally.

Anyway on to the examples, mostly tried to stick to Playfield based level art and Playfield+Bit related setups as that is the safest place to draw within the 2600 hardware as it is prominently used in demos because it is cheapest to alter in real time. Like I mentioned I don't want to misrepresent the 2600 and while much of what I propose has examples of actually working I'm still a dunce when it comes to Cycle Costs which is the fulcrum of everything rendered on the 2600.

They aren't complete examples but I think they are "safe" in regards to the 2600 limits.






Offline BladeJunker

  • 0001
  • *
  • Posts: 84
  • Karma: +0/-0
  • Know your limits, then break them.
    • View Profile
Re: Atari 2600 pixel art?
« Reply #4 on: March 01, 2012, 05:57:01 pm »
There's this topic that has posts about the limitations of various consoles that caters to pixel artists. Atari 2600 is not on the list, and I'm sure if you made such a thing someone would appreciate it.

Thanks for the directions, if I ever get this guide done I should follow this as a template for the document format. Well if you think someone will want it I'll keep at it. :)

Offline BladeJunker

  • 0001
  • *
  • Posts: 84
  • Karma: +0/-0
  • Know your limits, then break them.
    • View Profile
Re: Atari 2600 pixel art?
« Reply #5 on: March 05, 2012, 11:43:47 pm »
Why did I set my sights on the Atari 2600 for a discussion of pixel art? The main reason is that the machine gets a lot flack unjustly, I'm sure you've heard derogatory statements like "That looks so bad it looks like Atari." or patronizing it "It doesn't look good but what can you expect, its Atari.". Every game system has its strengths and weaknesses but each has a maximum quality level that should always be met, like with pixel art you want it to look as good as it possibly can get whether 2600 or PS3 the standard should always be the same.

I'd say its safe to say we're a visual lot on this pixel art forum and although being a good artist doesn't negate programming ability its safe to assume an abridged cliff notes approach is more useful here than a long description of how the TIA works. I'm not a great writer so might as well try some descriptions out and work out the kinks. :)

Well might as well start by saying that 2600 graphics design is directly transferable to the Atari 5200 and 7800 as the hardware architecture of graphics rendering is pretty much the same. So even if you go overboard on a design and it ends up not being possible on the 2600 you can always go up a hardware generation. I mostly focused on the 2600 because it was the most popular of the 3 consoles having the longest life span ever for a game console.
I don't know the 7800 well enough but the 5200 has twice the sprite objects of the 2600 and includes hardware acceleration for many of the common code kernels used in Atari based graphics rendering so its significantly faster and more versatile despite not selling very well when it was released. One good thing is that Atari 400/800 computer line(Which did sell fairly well.) and the 5200 console share the same hardware design except for a few small differences but it does expand the retro user base further for software of this type.

Atari 2600 object list: Playfield, Background, Ball, Player0, Missile0, Player1, Missile1

Atari 5200 object list: Playfield, Background, Player0, Missile0, Player1, Missile1, Player2, Missile2, Player3, Missile3
*As you see 4 Players & Missiles but I couldn't find a Ball object on the 5200, Atari cutting to the bone as always offering no extras. :'(

I should explain Color Clocks since the 2600 doesn't technically deal in pixels with the TV acting as part of the video card. Despite looking like pixels they are actually analog drawing units thus being able to literally stretch instead of doing so with scaling calculations like you would normally do with pixels. Anyway I'm making it sound complicated so here's a conversion table so you can use actual 2600 terminology so mis-communications don't occur if you pursuit a 2600 homebrew project and need to speak more literal Atari terms.

1 color clock=2 pixels wide
2 color clocks=4 pixels wide
4 color clocks=8 pixels wide(A Playfield pixel is 4 color clocks wide.)
8 color clocks=16 pixels wide
...and so on.

I find this table helpful when trying to describe the dimensional size of a sprite or explaining distances to an actual 2600 programmer. Not to knock programmers but they tend to be a literal bunch without any means of interpretation for less than specific programming terms. Perhaps I'm being hard on them since "moving" within any programming environment is probably hard that sticking to a single mind set makes navigation easier. :sry:

Let's explain the canvas size I use when screwing around with 2600 graphics design. It's 320X192, while the 2600 is technically capable of doing more than 192 vertical lines of resolution, on average most games do not exceed this amount for CPU and overscan considerations. Despite using a single layer canvas the actual 2600 is a multi-layer system of differing resolutions.
My buddy SeaGTGruff uses 800X576 as he is trying to approximate the vertically stretched pixel into a crisp exact pixel unit of 5:3 in shape but even that isn't perfectly 4:3 in aspect ratio. In the end the stretch is "soft" and analog that I think for the sake of file sizes in mockups 320X192 would suffice as old VGA 320X200 was also a stretched standard too.

*Exceeding 192-200 active scanlines can result in the top & bottom of the screen being chopped off. While it varies from TV set to TV set 192 is the safe overscan limit most likely to work with the widest range of NTSC sets. The overscan is different for PAL standard but you would be better off asking someone who lived in PAL regions to get a proper assessment since I just barely understand NTSC as a standard. ;)

The Playfield is your primary means of rendering level graphics which is only 40 "pixels" wide. Its not as bad as it seems since realistically much of level construction is bulk fill but you do have the option of changing the color per scan line, changing the color mid-line, or stripping out pixels and having the background color show through the holes. Before someone mentions mirrored Playfields, asymmetry has been conquered on the 2600 so its "mostly safe" to draw freely across the screen with Playfield pixels.

Overall the Playfield should be thought as a single image or a low resolution bitmap that fills the screen in regards to the degree of segmentation possible. There is no tile sheet or tilemapping to speak of except for a few small exceptions(The Playfield columns,the Missiles, and the Player objects.). While you can design blocks of graphics to specific block sizes for the sake of balancing the level graphics scale to the sprite scale for the most part the Playfield is just one big chunky bitmap, sort of liberating in its own way. :)

Here's some testing of block sizes from 1X1 up to 8X8 blocks(1X6 pixel block).





Something of note about the Playfield is its a 20 bit or pixel register split into 3 columns of 4 blocks wide(PF0), 8 blocks wide (PF1), and another 8 blocks wide (PF2) to the center which by default mirrors or tiles the other half to complete the full 40 of the screens width(4-8-8-Center-8-8-4). I mention this since these horizontal breaks can be used in a semi tile fashion to repeat image blocks or to omit areas of the screen as in pillar boxing. Yeah I know they are giant tiles but it is supported in hardware.
For the curious I'll mention vertical splitting of the Playfield for tiling purposes, while a single split added for the HUD is common to 2600 games splitting the Playfield vertically for tiling purposes is a difficult programming task only accomplished by a few 2600 masters over at AtariAge (EG. Boulderdash on 2600,check it out.).

http://www.youtube.com/watch?v=w6Ge6G9sT9E

The complication in smaller scale tiles is the code kernel related to the division itself as the Playfield image data (tiles) can exist in a variety of sizes or dimensions when not being displayed but when actually rendered on screen the 40 bit wide Playfield register is the end result always meaning it has to be converted to the larger Playfield bank size (4 & 8 bits wide respectively.). It really comes down to overburdening the CPU with so many tasks and those precious few cycles afforded to you.

EG.(Typical)
-Game Logic
-Sound
-Standard Display Kernel(Default use of all sprite objects.)

EG.(Small Tiles)
-Game Logic
-Sound
-Tile construction
-Tile sheet combiner
-Asymmetrical Playfield
-Standard Display Kernel

EG.(Small Tiles+Sprites+)
-Game Logic
-Sound
-Tile construction
-Tile sheet combiner
-Asymmetrical Playfield
-Missile Sprite Left Kernel, Missle Sprite Right Kernel
-Ball Sprite Player Extension Left Kernel, Ball Sprite Player Extension Right Kernel
-Standard Display Kernel

Although just a basic example you can see how tasks accumulate and the timing and execution of them can overwhelm the 6502 CPU quite easily when the vast majority of CPU time is spent with real time rendering everything both visible and behind the scenes with no hardware assistance.

This aspect wouldn't be so bad if there was more room to segment and module the engine like we do now for convenience at what is now a minor cost in CPU time. However with the 2600 there is little opportunity to segment making the engine a fully integrated optimized code base, much like the game Jenga push one block out and the whole structure could cease to work.
As an example David Crane didn't have a Lives meter in Pitfall initially until his colleagues badgered him to add it which was worth while since it made the game more accessible to the large majority of players. Despite this addition being warranted he basically had to take the entire engine completely apart to add this gauge since it was so tight with 1-line kernel graphics and the level generating demands.
I bring this up since the 2600 development environment is the polar opposite of something like Flash where you can just add things at will. I'm a terrible game designer with bad habits but even I would say a well thought out design document is needed before you actually make an Atari 2600 game.


Sorry this should have been in here from day one. :-[
The Playfield has a SCORE bit which allows you to change the Playfield color at the center of the screen to a different color for the left and right side of the screen. This is hardware based so it doesn't come with the usual software based CPU costs of mid-line color changes. So this is another safe bit of color change you can invoke in the Playfield. :)



Here's an example of the Playfield columns, added some arrows to show the default mirroring directions.


Same thing but here's the Playfield tiling option which in my opinion doesn't get employed enough despite being a default setting.


Something I should mention about using the Playfield columns as a tile grid is that you can only use it to expand configuring options under an asymmetrical rendering setup but not to save image space because the Playfield register has a fixed linear reading order. To be specific you actually use 50% more image space IE. 2 full Playfields for asymmetrical rendering since each Playfield Tile has to include both a left and right facing copy in order to render in the correct orientation for each side of the screen.
The Mirrored or Tiled Playfield modes are completely fixed layouts where you can omit a column completely but any exchange of one column graphic for another would be reflected in its opposing column register.
Lastly these are 2 column widths of 4 and 8 bits respectively which aren't interchangeable so its an either or situation in that regard making 2 distinct groups or types of Playfield columns.

Whoops sorry again. :-[
The Background layer actually does have a small amount of resolution control in it that you can change the color per scanline IE. a 1X192 image layer. Despite limitations these 2 layers combined (Playfield & Background) do offer possibilities of 2 color background graphics if catered to.

Here's an example of a simple background made using the Background layer, I could use the Playfield to layer on some other details, or make a giant Playfield sprite,  etc.

2 Color tiles:Mostly concept work of Playfield+Background colors and others that use Missile layers.

Despite a lack of true tiling options its best to cater to the Playfield as if it had tiling when it applies to bitmap patterns and you should also try to fit things to the natural horizontal breaks in the Playfield register of 4 or 8 bit wide banks.

Options: Default savings through mirroring always present with tile mode offers varying amounts of image space savings.

-40:40 bits(Playfield pixels) wide or the full screen of completely freeform bitmap data, other than mirroring no image space savings.

-40:12 bit wide tiles, partial savings in PF0 & PF1 which do tile but PF2 requires 2 unique tiles or island tile.
-40:8 bit wide tiles, decent tiling option as two-4bit and one 8:bit wide Playfield bank can tile fill whole screen.
-40:6 bit wide tiles, partial savings in PF0 & PF1 which do tile but PF2 requires 2 unique tiles or island tile.
-40:5 bit wide tiles, tiling option will save space but right side of screen irregular unless you use isolated tiles with border trim or islands.
-40:4 bit wide tiles, best tiling option as one-4bit and one-8bit wide (Two 4-bit wide tiles paired)Playfield bank can tile fill whole screen.
-40:2 bit wide tiles, same as 4 bit wide option.

The canvas is 320 wide simply because 40 Playfield pixels fit inside as do Player objects drawn to double wide res(160 to 320) or C64 width standards and Missile and Ball bits at variable widths. So in this canvas approximation all your sprite object designs will fit and align to the varied 2600 layer resolution scales.

I mentioned 192 as the basic height resolution used in most 2600 games but it is actually variable based on the thickness of line kernel used within the engine, using thicker lines is used to save cycles during rendering but typically helps with animation smoothness. At 192(1 line) regardless of pixel widths its about as sharp as C64 graphics, at 96(2 line) lines of vertical resolution its close to 1:1 pixels looking a lot like an Intellivision standard, at 64(3 line) its gets chunky and similar to a 80X64 screen resolution in practice, and 48 lines(4-Line) which is pretty much like 64 vertical lines but taller lol.

You can actually set line thickness differently between all 6 sprite objects per scanline (Playfield/Background/Ball/Player0/Missile0/Player1/Missile1) but for visual consistency and engine efficiency its best to stick to 1 global line thickness standard. If you do want to differ the height resolution its best to cordon it into deliberate areas of use like a single object or scanline height zone instead of changing it sporadically since everything invoked including line thickness changes consume those precious 76 machine cycles per scanline.
EGs. HUD bar scanline zone is 1-Line but game graphics region is 2-Line rendered, Player objects are 1-Line but all other objects are 2-Line rendered.

Playfield resolution options:
-40X192(1 line)
-40X96(2 line)
-40X64(3 line)
-40X48(4 line)


Note this example demonstrates line thickness but the pixel width is strictly different between Playfield, the 2 Player objects, and the 2 Missiles and the Ball which all have different pixel width standards(EG. 1 Playfield pixel is 8 pixels wide in the canvas while 1 Player object pixel is 2 pixels wide in the canvas.).

The grid scale in the canvas uses 40X32 blocks of 8X6 pixels each to compensate for the heavy vertical stretch that occurs when graphics are actually rendered to the 4:3 aspect ratio. Its not perfectly exact but its a close enough in dimensional size that each block will be close to equal in width and height when stretched. For game graphics I just rescale my mockups to 800X600 to test how tall things will be after stretching.
Overall the canvas block size of 8X6(Well really 1X6 on an actually 2600.) pixels is a sturdy guide for plotting out level structures and should be thought of as your minimum level block size akin to the 8X8 used on other platforms.

Here's an example of what 3 line kernel graphics would look like.

As you can see its very tight and the thicker vertical lines handicap any finer resolution horizontally in composition, used 4 pixel width standard to compensate. Level layouts are definitely made smaller or more simple at 3 lines thick out of necessity, it looks like 2 floors would probably reasonable and some added vertical scrolling or extremely spartan level design would balance out screen space constraints.
I know I overdid it a bit in colors and bits per scanline but it was mostly just seeing what could be drawn into the resolution well. Such a setup would have benefits in cycle cost reduction being only 64 lines tall, things like animation smoothness, multi-color graphics, and sprite multiplexing would have less drag on the CPU even when used in combination compared to doing the same with 1 or 2 line rendering.


Actually the formula for vertical aspect ratio stretch that SeaGTGruff gave me should work with one tweak. Take your height resolution value multiply that by 3 and divide that by 5 to get the color clock width, lastly multiply that by 2 to get the width resolution that is compatible with the canvas size I posted. Depending on the result of the width value you get you might have to round up or down so it will fit the resolution limits.
FYI I tried favoring the width dimension when trying for approximately equal height and width after stretching but was informed that catering to the height value was better since it falls more in line with how efficient kernels and graphics are rendered on the 2600 IE. per vertical scanline which is especially true with curves & circles.
Its not that you can't favor the width its just that it will be far less efficient in cycle usage if you vary line thickness and horizontally shift pixels differently per vertical zone in actual rendering just to get the exact height you're aiming for, its better to have a consistent basic display kernel using one line thickness option top to bottom and take advantage of tables and inverting width and position values for less CPU drag. It depends on the context which dimension you favor EG. Game graphics versus an Art Slide.


Sprites?  Whoops wrong credit, here is where I found these animal sprites. :-[
http://www.photonstorm.com/archives/2291/16x16-pixel-art-tutorial

The 2 player objects are 8 bits or pixels wide but since they are double wide they take up 16 pixels of width of on screen width not unlike C64 sprites. You have unlimited height resolution but that is actually a pretty useless feature except for a few isolated contexts where that factor can be utilized. You can pair both Player objects together for a 16 pixel width but its quite a sacrifice unless you can ensure both players never reside on the same scan line as in a Tennis game where the net separates them or that all other sprites can be made using Missile0, Missile1, and or the Ball pixel.

The standard 2600 sprite description of 2 Player objects 8 pixels wide is often enough to stop a pixel artist dead in their tracks based on its meager offering so I'll instead go over some options to make the 2600 less stifling.

The 2 Player objects will probably be the most familiar and friendly object found on the 2600 as its the closest you'll get to standard pixeling. There are quite a few editing programs to create standard Player object sprites but I haven't found any that support bit constructed sprites or extensions to the Player object as that is typically handled by a programmer.

The easiest way to describe Missile0, Missile1, and the Ball is to think of each as a single pixel with multiple width settings and any height you choose. There names denote there most infamous uses in most 2600 games as each Player object has a Missile object that acts as its projectile and the Ball object or sprite was first used as a ball that the 2 players could bat around. Over the years after the 2600's release both Missiles and the Ball started to get used in a myriad of ways beyond there initial purpose.

You can actually extend the default Player objects 8 pixel width using the Player objects corresponding Missile object up to a minimum 9 pixels wide with a basic kernel. Pretty basic but when dealing with so few pixels even a single pixel is a banquet. I mention the minimum of adding a single pixel to the width of both Player objects with there corresponding Missile because the Missile can copy 3 times like the Player objects so you can make three 9 pixel wide Player sprite copies quite easily.

The next best step to extending Player width is to utilize Missile0, Missile1, and the Ball bit all along one scanline which can each be set to different widths greatly expanding what can be done using the Player sprite object. Something to note about this usage is that if you need a lot of projectiles you won't have free bits to use for pixel extensions (Melee VS Shooter).

The 2 Player sprite objects can be copied 3 times per scan line at 3 possible mandatory distances from each other, the minimum gap size is 4 blocks(32 pixels) wide with the Player object included within that gap distance specifically to the left most side of the gap(See my spacing chart below.). All Player copies move in unison by default while true independent movement of entities requires flicker based multiplexing of Player objects or 1 object rendering multiple sprites with multiple screen renders(EG.Pac-Man ghosts.). The next 2 wider gap distances simply double the previous width or 32,64, and 128 (EG.Space Invaders 2600). This mandatory gap distance also applies to both Missiles objects and its 3 copies. The Ball object has no copy ability at all so copy gap distance is not applicable



2 sprites, that's not very many and I need more?  ???

The 2600 is extremely frugal in its construction since it doesn't have a frame buffer or video RAM of any kind meaning it has to refresh the screen pixels constantly without a break. While this puts quite a burden on the CPU as the level of instruction complexity is fairly high to form the graphics on screen it also mean everything is modular and alterable in real time as everything is real time rendered by default.
One interesting property of this is using one Player object sprite across multiple sprites since you can switch the bitmap pattern within set heights of vertical resolution as each objects copying ability and appearance is only influenced or limited by the scanline height zone it occupies. The height is completely negotiable as every sprite object has unlimited height resolution so you can set its vertical zone of influence to where ever you desire.

How far can you push the Player objects?

The most they have ever been pushed practically is 6 sprite blocks of unique appearance through multiplexing or flicker based passes. One of the more popular implementations of this is the Title Screen Kernel which can essentially render a bitmap of 48 pixels of width and any height you desire but only that since the timing and CPU needs are quite high that nothing can render on or beside it. As you can see in this example layering is also offered in this kernel but the increase in colors per scanline is minimal and it increases the flicker frequency. This was an elaboration on the score rendering approach which you see at the bottom with the 6 numerals that became a staple in 2600 games where score was the only stat required you could make the characters more fancy than the Playfield or Missiles would allow for.

Now I didn't put this here to scare you away from multiplexing your sprite objects beyond there default of 3 copies, I only wanted to express the costs involved with the maximum amount. Multiplexing sprites is a common practice in many 2600 games such as Ms Pac-Man & Jr Pac-Man which render there ghosts with minimal flicker unlike the crappy first effort in Pac-Man. So if you're careful and frugal with its use you can do a great many things. ;)


Another common issue faced with only 2 actual sprites is the need for a 3rd or a 4th type per scan line where your only option for an additional independent sprite is to build a sprite manually using the 3 loose bits of 2 Missiles and Ball separately or together.
Based on this canvas you can make each bit object(Missile0/Missile1/Ball) 2, 4, 8, or 16 pixels wide but only one width setting per object per scan line, actually in code its much more efficient to set all 3 bit objects to one default width for every scan line jsyk. Each Missile provides 3 pixels each through copies and the Ball one pixel by default, multiplexing with flicker can extend the amount of Missile copies you can use but its far less reliable in cycle costs and on screen appearance(The flicker burns my eyes!  :blind:)than just sticking to the default. Unfortunately the Ball literally can not multiplex at all which has something to do with the hardware architecture, perhaps its loss on the 5200 and 7800 wasn't such a bad thing. ;D

Its worth noting that the Player objects can be stretched too just like the 3 bit objects but unfortunately doing so cancels out its corresponding Missile and its ability to copy, yikes. To get around that the Ball is employed as the stretched Player objects projectile. Because of the Missile loss and copy cancellation I find this particular option unattractive to say the least but it has its uses within specific contexts(EG. The walker legs in Empire Strikes Back 2600.)

The major limiting factor of loose bit construction is that each bit has to be "tiled" with those damn color clock based gaps between each copy. Since that is so far apart we use the 3 bit objects and there copies at different horizontal alignments to compensate for that. Here I just show the default maximum number of copies but multiplexing with a moderate amount of flicker can extend the number of copies further IE. more than 3 Missile sprites per scanline. Also any bit constructed sprite has the same moving in unison gap distance requirement that the Player sprites do jsyk.

Something else I should warn you about bit constructed sprites is that they lack native hardware flopping, while the Player objects flop horizontally with a simple hardware setting switch the bit constructed sprites require separate Left & Right code kernels adding to the cycle overhead of using them.


Okay lets look at what we can build.


-In practice 1 bit is only capable of producing basic solid shapes through changing the bit width and horizontally offsetting the Bits position per scanline. Try to think of it like an Abacus with set distances between each bead where at its most basic a shape is split into 3 slices of Top, Middle, and Bottom.


-2 bits together is far more versatile when each is set to different widths per scan line. Something of note is that the 3 bit objects can overlap and occlude each other being on separate rendering layers which is handy for creating odd value widths more efficiently using 2 Bit Object widths rather than building a particular width with 3 different bits at 3 different widths butted directly against each other in horizontal alignment.

-3 bits is the easiest to use and has the fewest limitations especially in regards to non solid shapes and patterns. Most of the challenge is utilizing copy ability and trying to form the intended pattern.

-You can make center flopped sprites with the Player objects using both Players but that pretty much defeats the purpose of flopping in the first place. You can flop one Player object to create the other side but the mandatory distance between each copy requires a bit construct to fill the middle in.

-Generally speaking the 2 Missiles are your bread & butter when it comes to bit constructed sprites having a native copy limit of 3 and potential for multiplexing. The Ball is truly singular in use which is why Pitfall has a single swinging vine and Adventure has its single blocky knight. So in practice you could make a cursor, a simple main player sprite(Think Pac-Man), one additional sprite per vertical zone, a weapon for the main player with a distinct color,or to generically fill a portion or along a single edge of a Playfield graphic.

-One trick I forgot about is the use of very quick HMOVE functions applied to the sprite to streak in appearance odd value width sizes(EG. 3&6 wide pixels.) Basically by changing a pixels horizontal position every time the screen is rendered you can produce what appears to be a solid line(Bird in cage flicker.).
Don't get too excited about this function since its costly enough to invoke that its best to isolate its use to a few sparse places IE. using the Ball object to make one small odd value line segment width within a bit constructed sprite.


Sprite sizes?

One thing I learned about bit objects on the 2600 is that it doesn't matter how big you make sprites just as long as you have enough bits to fill the distance.

-Boss Sprites can be rendered using the Playfield itself as the large scale of the pixel doesn't look out of scale. Moving a Playfield sprite on the 2600 is similar to how the Nes did big Boss sprites in that you blank the background color and pan or scroll the image to "move" the giant sprite. While vertical movement of the Boss sprite can be done cheaply horizontal Boss movement requires the use of all 3 loose bit objects to render approximate interim horizontal positions between each Playfield pixel width distance across the screen otherwise it moves jerky.

-Medium scale sprites vary in size potential but one thing is certain which is you're better off using 4 pixel wide line segments or wider to plot its overall design as you don't have enough loose bits to vary the outline shape and fill shapes to the same crispness of a Player object.

-Small scale doesn't need much description as its straight forward pixeling with the Player object.

Probably the easiest way to compose an Atari sprite with multiple layers or bits outside of the actual hardware implementation is to take advantage of whatever paint program you're using and put each distinct sprite object onto image layers which should help greatly to keep things organized and discrete especially in regard to overlapping. Also most have options for tile or stamping grids to set distances which should help with plotting out sprites and there copies.


In my next post I'll likely go into scan line isolation, using objects in different ways, and or multi-color issues. Till next time. :D
« Last Edit: June 12, 2012, 12:43:57 am by BladeJunker »

Offline HughSpectrum

  • 0010
  • *
  • Posts: 279
  • Karma: +0/-0
    • View Profile
Re: Atari 2600 pixel art?
« Reply #6 on: March 06, 2012, 02:53:03 pm »
I seriously need to try and break down your post and simplify things for reference.

Do I get this right?

Standard Resolutions: 320x192, 320x96 (double tall pixels), 320x64 (triple tall pixels), or 320x48 (quadruple tall pixels)

Playfield: 8x1, 8x2, 8x3, or 8x4 pixels (depending on resolution) of foreground & background color, foreground color can change within the scanlines (I assume keeping to the 8 pixel wide grid?)  Normally symmetrical.

Player sprites: Up to two unique sprites on screen, 2x1, 2x2, 2x3, or 2x4 size pixels, must be 8 2x pixels wide, can be as tall as desired.  Can have three copies of each, but the copies move with the original.

Missile 1 & 2 sprites: Single pixel that is 2x, 4x, 8x, or 16x wide, can be any height.  Corresponds to relative player sprites.

Ball sprite: Single pixel that is 2x, 4x, 8x, or 16x wide, can be any height.
« Last Edit: March 07, 2012, 01:15:32 am by KittenMaster »

Offline BladeJunker

  • 0001
  • *
  • Posts: 84
  • Karma: +0/-0
  • Know your limits, then break them.
    • View Profile
Re: Atari 2600 pixel art?
« Reply #7 on: March 06, 2012, 04:10:07 pm »
Quote
I seriously need to try and break down your post and simplify things for reference.

Do I get this right?

Standard Resolutions: 320x192, 320x96 (double tall pixels), 320x64 (triple tall pixels), or 320x48 (quadruple tall pixels)

Playfield: 8x1, 8x2, 8x3, or 8x4 pixels (depending on resolution) of foreground & background color, foreground color can change within the scanlines (I assume keeping to the 8 pixel wide grid?)  Normally symmetrical.

Player sprites: Up to two on screen, 2x1, 2x2, 2x3, or 2x4 size pixels, must be 8 2x pixels wide, can be as tall as desired

Missile & Ball sprites: ???  I don't think these were properly introduced, you only talk about how to incorporate them into player sprites instead of what they are on their own.

At times it doesn't look it but this is actually the simplified description, the real 2600 development environment is primarily a programmer's domain. Believe me I barely understand it even after of months of research and consulting with anyone who would answer my many questions which probably seemed elementary to them.

Sorry about the missing info, those are those kinks I mentioned lol. I revised my post and I hope it is better, if not I'll change it some more. :)
« Last Edit: March 06, 2012, 04:40:08 pm by BladeJunker »

Offline HughSpectrum

  • 0010
  • *
  • Posts: 279
  • Karma: +0/-0
    • View Profile
Re: Atari 2600 pixel art?
« Reply #8 on: March 07, 2012, 01:20:28 am »
I understand that Atari 2600 games is much more largely defined by its programming than anything, but I find it nice to have a quick summary of each of the sprites and the playfield.

Updated my post above.  Again correct me if I got any info wrong.

Offline BladeJunker

  • 0001
  • *
  • Posts: 84
  • Karma: +0/-0
  • Know your limits, then break them.
    • View Profile
Re: Atari 2600 pixel art?
« Reply #9 on: March 07, 2012, 03:06:28 am »
Quote
Do I get this right?
I think so.

Quote
Standard Resolutions: 320x192, 320x96 (double tall pixels), 320x64 (triple tall pixels), or 320x48 (quadruple tall pixels)
Looks okay to me as long we call it the Standard Canvas Resolution since you never actually get to use all 320 pixels on a real 2600. Just making sure. :)

Quote
Playfield: 8x1, 8x2, 8x3, or 8x4 pixels (depending on resolution) of foreground & background color, foreground color can change within the scanlines (I assume keeping to the 8 pixel wide grid?)  Normally symmetrical.
Yeah that will work, I'm guessing you're going to try to setup a specific pixel size within a paint program and save yourself a lot time versus etching them out manually like I've been doing which is slow? Yes keep each Playfield pixel 8 pixels wide only as that will approximate the real thing. I wouldn't get too hung up on symmetry unless you intend to use a lot of color changes per scanline, asymmetrical rendering does use a moderate CPU cycle cost.

Quote
Player sprites: Up to two unique sprites on screen, 2x1, 2x2, 2x3, or 2x4 size pixels, must be 8 2x pixels wide, can be as tall as desired.  Can have three copies of each, but the copies move with the original.
Well specifically up to 2 unique Player sprites per vertical scanline height as you can create more sprite variations with vertical isolation from each other. Okay 2X1, 2X2, etc. size pixels, yes that will work for Player object sprites. Yes the 2 Player objects only have 8 bits or pixels across its width. And yes 3 copies of the Player sprites which all move and animate in unison with fixed mandatory distances between each other, there are 3 gap distances for copies which basically doubles with each setting higher.
I'll cover more of this in my next post, just been tired so its taking a while to get everything together. :)

Quote
Missile 1 & 2 sprites: Single pixel that is 2x, 4x, 8x, or 16x wide, can be any height.  Corresponds to relative player sprites.

Ball sprite: Single pixel that is 2x, 4x, 8x, or 16x wide, can be any height.
Everything looks in order here too. Just be careful with the horizontal alignments as its easy to put pixels where you want them versus where they can actually be. ;)

Offline HughSpectrum

  • 0010
  • *
  • Posts: 279
  • Karma: +0/-0
    • View Profile
Re: Atari 2600 pixel art?
« Reply #10 on: March 07, 2012, 04:20:31 am »
Quote
Everything looks in order here too. Just be careful with the horizontal alignments as its easy to put pixels where you want them versus where they can actually be.
I'm honestly not sure what you mean.  Are you saying that the missile and ball sprites' x & y positions are attached to a grid based on their size?

Offline BladeJunker

  • 0001
  • *
  • Posts: 84
  • Karma: +0/-0
  • Know your limits, then break them.
    • View Profile
Re: Atari 2600 pixel art?
« Reply #11 on: March 07, 2012, 08:07:27 pm »
Quote
Everything looks in order here too. Just be careful with the horizontal alignments as its easy to put pixels where you want them versus where they can actually be.
I'm honestly not sure what you mean.  Are you saying that the missile and ball sprites' x & y positions are attached to a grid based on their size?

Sorry I didn't describe the width distance between object copies very well, but I think I made it more coherent now hopefully.

Offline HughSpectrum

  • 0010
  • *
  • Posts: 279
  • Karma: +0/-0
    • View Profile
Re: Atari 2600 pixel art?
« Reply #12 on: March 08, 2012, 03:52:49 am »
Okay so...  The missiles cannot intrude on another player copy's personal space just as another player object cannot? 

Offline BladeJunker

  • 0001
  • *
  • Posts: 84
  • Karma: +0/-0
  • Know your limits, then break them.
    • View Profile
Re: Atari 2600 pixel art?
« Reply #13 on: March 08, 2012, 05:28:27 am »
Okay so...  The missiles cannot intrude on another player copy's personal space just as another player object cannot? 
No all 5 movable objects including Player0, Missile0, Player1, Missile1, and the Ball can all overlap with each other but when you render a copy of any of these objects(excluding the Ball which has no default copy ability.) it requires a mandatory gap of 3 possible distances from itself not the other objects.

Try to think of it as a multi-layered abacus where the beads are locked to a set distance apart from each other if that helps.

Offline HughSpectrum

  • 0010
  • *
  • Posts: 279
  • Karma: +0/-0
    • View Profile
Re: Atari 2600 pixel art?
« Reply #14 on: March 08, 2012, 06:22:47 am »
How correct is this summary I'm working on so far?

Technical Resolutions: 320x192, 320x96 (double tall pixels), 320x64 (triple tall pixels), or 320x48 (quadruple tall pixels)

Playfield: 8x1, 8x2, 8x3, or 8x4 pixels (depending on resolution) of foreground & background color, foreground color can change within the scanlines on an 8x-width pixel by pixel basis.
Hardware demands the playfield to be symmetrical, but coding can overcome hardware to be asymmetrical.  [See BladeJunker's guide on how collumn splitting works]

Player sprites: Up to two unique sprites, 2x1, 2x2, 2x3, or 2x4 size pixels, must be 8 2x pixels wide, can be as tall as desired.  Can be copied*.

Missile 1 & 2 sprites: Single pixel that is 2x, 4x, 8x, or 16x wide, can be any height.  Corresponds to relative player sprites.  Can be copied*.

Ball sprite: Single pixel that is 2x, 4x, 8x, or 16x wide, can be any height.  Cannot be copied.

* Whenever you copy a sprite, it shares the same x origin of the original sprite for movement, and must be offset by 32, 64, or 128 pixels and + width pixels.
« Last Edit: March 09, 2012, 04:27:59 pm by KittenMaster »

Offline BladeJunker

  • 0001
  • *
  • Posts: 84
  • Karma: +0/-0
  • Know your limits, then break them.
    • View Profile
Re: Atari 2600 pixel art?
« Reply #15 on: March 08, 2012, 01:53:37 pm »
Quote
Technical Resolutions: 320x192, 320x96 (double tall pixels), 320x64 (triple tall pixels), or 320x48 (quadruple tall pixels)
NOTE: Depending on the game, some horizontal pixels may be omitted where clock cycles were used to process game logic.
Some horizontal pixels may be omitted sounds kind of vague, if you are referring to what I said about pillarboxing then yes omission of certain Playfield columns is possible. I tend to find clipping the first 4 blocks off the left and right useful for some games as well as dedicating the first 12 blocks on either side of the screen for a menu or HUD.
As far as processing game logic that is usually done in between graphics rendering passes. The reasons for omitting a column or bank of Playfield pixels tend to vary.

Quote
Playfield: 8x1, 8x2, 8x3, or 8x4 pixels (depending on resolution) of foreground & background color, foreground color can change within the scanlines on an 8x-width pixel by pixel basis.
Hardware demands the playfield to be symmetrical, but can be coded to be asymmetrical.  [See BladeJunker's guide on how collumn splitting works]
That looks right to me about Playfield pixel size. However the hardware defaults are Symmetry mode or mirroring and Tiling mode like you see in my column split chart. Only asymmetry requires special coding.

Quote
Player sprites: Up to two unique sprites on screen, 2x1, 2x2, 2x3, or 2x4 size pixels, must be 8 2x pixels wide, can be as tall as desired.  Can be copied*.
Okay pixel sizes look accurate to what I described. However up to two unique sprites on screen isn't exactly true since you can vary the Player sprite vertically based on a set height resolution. Let's say you use a Player sprite that is 24 pixels tall, based on 192 lines of vertical resolution you could vary that one sprite 8 times. A good example of this feature is Frogger where the type of sprite switches from different car styles up to logs and turtles which all use the same Player objects but are isolated into vertical bands.
This will be featured as part of my scanline isolation post jsyk.

Quote
Missile 1 & 2 sprites: Single pixel that is 2x, 4x, 8x, or 16x wide, can be any height.  Corresponds to relative player sprites.  Can be copied*.
Looks good on pixel size. I'd say Missile0 and Missile1 are associated to there Player counterparts as each share the same default color with there pair but should still be thought as there own separate independent movable object. Can be copied up to 3 times*. I'm guessing the * is related to the unique visual quirks when copies are invoked?

Quote
Ball sprite: Single pixel that is 2x, 4x, 8x, or 16x wide, can be any height.  Cannot be copied.
Pixel sizes look good. Can not be copied is a little strict since by default the hardware may not support a copy per se, but with the right setup of multiplexing you could get more than one per scanline. I admit that multiplexing is a less stable and dependable option but it still exists. Perhaps another * is required? ^_^

Quote
* Whenever you copy a sprite, it shares the same x & y origin of the original sprite for movement, and must be offset by 32, 64, or 128 pixels.
It only really needs to share the X axis of the original sprite in movement, refer to what I said about Frogger. The offset pixel widths are fine but its important to remember that the said objects width is included as part of the offset distance rather than just added to the width of the object and the origin point is to the left most side. Can't hammer this point enough I'm afraid since its not at all like "regular" tiling on other platforms. :)

Offline HughSpectrum

  • 0010
  • *
  • Posts: 279
  • Karma: +0/-0
    • View Profile
Re: Atari 2600 pixel art?
« Reply #16 on: March 09, 2012, 01:22:35 pm »
I edited my previous post based on your corrections.  When you said that a game might not use the entirety of the 320 horizontal resolution I thought you meant games like Pitfall which hid the part of the screen that would have had black lines.

Quote
Okay pixel sizes look accurate to what I described. However up to two unique sprites on screen isn't exactly true since you can vary the Player sprite vertically based on a set height resolution. Let's say you use a Player sprite that is 24 pixels tall, based on 192 lines of vertical resolution you could vary that one sprite 8 times. A good example of this feature is Frogger where the type of sprite switches from different car styles up to logs and turtles which all use the same Player objects but are isolated into vertical bands.
This will be featured as part of my scanline isolation post jsyk.
So...  Two unique sprites per horizontal scanline as long as sprites are not occupying the scanlines?  Or are you talking about a very specific programming trick.

I'm going to be honest, learning about Atari 2600 hardware restrictions becomes that much more difficult for the purpose of doing mockups (that have no programming backing) and pixel art when one also has to learn about every specific programming trick in very specific games that have broken the restrictions.  I'm hoping to mostly get a summary of the hardware itself with some minor exceptions that can be made.

---

I did want to ask, is it possible to feasably alter a chunk of the playing field (such as the middle two columns) without affecting the rest of the playfield?  I'm thinking about doing an Atari 2600 mockup of a first person view AD&D style game and I'd like the view of a first person area to change to that of a detailed creature.
« Last Edit: March 09, 2012, 01:27:21 pm by KittenMaster »

Offline BladeJunker

  • 0001
  • *
  • Posts: 84
  • Karma: +0/-0
  • Know your limits, then break them.
    • View Profile
Re: Atari 2600 pixel art?
« Reply #17 on: March 09, 2012, 04:10:29 pm »
Quote
So...  Two unique sprites per horizontal scanline as long as sprites are not occupying the scanlines?  Or are you talking about a very specific programming trick.
I know it seems confusing when compared to how scanline to sprite limits work on other platforms with block based sprites but it is different. Remember what I said about the 2 Player objects being capable of being any height resolution you choose, well the height of the sprite defines the amount of scanline height and its limitations for said Player object. Where ever the sprite is within the vertical field defines the zone at which only 3 copies can be rendered per Player object, and that's per object as Player0 & Player1 do not effect each others rendering limits.

Specific programming task, well everything on the 2600 would fall under that definition lol but if you're asking if its a common practice then yes it can be done without much difficulty. I'll always make sure to clarify anything that could prove difficult or proves to be unreliable for average use or only possible under certain contexts.

Quote
I'm going to be honest, learning about Atari 2600 hardware restrictions becomes that much more difficult for the purpose of doing mockups (that have no programming backing) and pixel art when one also has to learn about every specific programming trick in very specific games that have broken the restrictions.  I'm hoping to mostly get a summary of the hardware itself with some minor exceptions that can be made.
Believe me I sympathize with what you say about no programmer backing as it can put you in a position of much doubt but that's where I'm everyday since starting this quest. I'm afraid there isn't much of anything done on the 2600 that isn't restricted or defined by its unique hardware, as far as breaking the restrictions we're talking hand and glove here since its more like if you want to do X then this is the particular setup you'll need. This is kind of why I described this guide being in terms of sprite contexts(Portraits/HUDs/Text/Sprites/Level Tiles) and or game Genres(Shooter/Platformer/Fighter/Etc.), a lot of my proposals on AtariAge are setups or structural templates for achieving the 2600 equivalent of things done on stronger gaming platforms.

Quote
I did want to ask, is it possible to feasably alter a chunk of the playing field (such as the middle two columns) without affecting the rest of the playfield?  I'm thinking about doing an Atari 2600 mockup of a first person view AD&D style game and I'd like the view of a first person area to change to that of a detailed creature.
Yes you can alter specific Playfield columns while leaving the others unchanged, such setups have been done before since the Playfield columns constitute individual banks in the Playfield register.

I'd love to take a look at it when you're ready to show it. :)


Offline HughSpectrum

  • 0010
  • *
  • Posts: 279
  • Karma: +0/-0
    • View Profile
Re: Atari 2600 pixel art?
« Reply #18 on: March 09, 2012, 04:30:16 pm »
Quote
I know it seems confusing when compared to how scanline to sprite limits work on other platforms with block based sprites but it is different. Remember what I said about the 2 Player objects being capable of being any height resolution you choose, well the height of the sprite defines the amount of scanline height and its limitations for said Player object. Where ever the sprite is within the vertical field defines the zone at which only 3 copies can be rendered per Player object, and that's per object as Player0 & Player1 do not effect each others rendering limits.
I still am not sure what you're trying to say.

Based on the Frogger example, is it just that you're using a single very tall sprite to draw several images, and delaying the drawing during different scanlines to change their positions?

Quote
Believe me I sympathize with what you say about no programmer backing as it can put you in a position of much doubt but that's where I'm everyday since starting this quest. I'm afraid there isn't much of anything done on the 2600 that isn't restricted or defined by its unique hardware, as far as breaking the restrictions we're talking hand and glove here since its more like if you want to do X then this is the particular setup you'll need. This is kind of why I described this guide being in terms of sprite contexts(Portraits/HUDs/Text/Sprites/Level Tiles) and or game Genres(Shooter/Platformer/Fighter/Etc.), a lot of my proposals on AtariAge are setups or structural templates for achieving the 2600 equivalent of things done on stronger gaming platforms.
I can see where you're going with that, I just think it'd be easier to know the sprite limitations and quirks before getting into how to work around them and apply them in certain scenarios.

Offline BladeJunker

  • 0001
  • *
  • Posts: 84
  • Karma: +0/-0
  • Know your limits, then break them.
    • View Profile
Re: Atari 2600 pixel art?
« Reply #19 on: March 09, 2012, 05:06:33 pm »
Quote
I still am not sure what you're trying to say.

Based on the Frogger example, is it just that you're using a single very tall sprite to draw several images, and delaying the drawing during different scanlines to change their positions?
Single tall sprite, no that is not the case in Frogger. Everything on the 2600 is being rendered in real time so it literally changes from one "bitmap"(Player0 or 1) to another bitmap over and over again as it draws the screen top to bottom. The 2600 doesn't have a frame buffer so it constantly has to manually refresh the pixels just to keep them lit. While this is a hectic process always "racing the beam" it makes the data highly modular thus using the same address or object across multiple sprites rather than one sprite per sprite like on other platforms. I know it sounds crazy the first time you hear it but that's the way it works.

Offline BladeJunker

  • 0001
  • *
  • Posts: 84
  • Karma: +0/-0
  • Know your limits, then break them.
    • View Profile
Re: Atari 2600 pixel art?
« Reply #20 on: March 09, 2012, 05:38:32 pm »
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. ;D

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. :lol:
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. :crazy:


Still it demonstrates dithering within the Playfield resolution quite well. ;D


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. :yell:

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. :P 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
« Last Edit: May 30, 2012, 12:35:03 am by BladeJunker »

Offline HughSpectrum

  • 0010
  • *
  • Posts: 279
  • Karma: +0/-0
    • View Profile
Re: Atari 2600 pixel art?
« Reply #21 on: March 09, 2012, 05:51:29 pm »
Quote
Single tall sprite, no that is not the case in Frogger. Everything on the 2600 is being rendered in real time so it literally changes from one "bitmap"(Player0 or 1) to another bitmap over and over again as it draws the screen top to bottom. The 2600 doesn't have a frame buffer so it constantly has to manually refresh the pixels just to keep them lit. While this is a hectic process always "racing the beam" it makes the data highly modular thus using the same address or object across multiple sprites rather than one sprite per sprite like on other platforms. I know it sounds crazy the first time you hear it but that's the way it works.
I know that the 2600 is different from other consoles and that it's on a per-scanline basis instead of a per-screen one, but I'm still failing to grasp what is actually going on in your example.  Are you telling the 2600 to draw the player sprite's line again with different data and then on the next scanline starting from the leftmost sprite again, or are you changing the data of the player sprite when going to the next instance of a copied sprite?

I am thinking of just making a note in my summary about things changing within scanlines.

Offline BladeJunker

  • 0001
  • *
  • Posts: 84
  • Karma: +0/-0
  • Know your limits, then break them.
    • View Profile
Re: Atari 2600 pixel art?
« Reply #22 on: March 09, 2012, 06:34:24 pm »
Quote
I know that the 2600 is different from other consoles and that it's on a per-scanline basis instead of a per-screen one, but I'm still failing to grasp what is actually going on in your example.  Are you telling the 2600 to draw the player sprite's line again with different data and then on the next scanline starting from the leftmost sprite again, or are you changing the data of the player sprite when going to the next instance of a copied sprite?

I am thinking of just making a note in my summary about things changing within scanlines.
Please show mercy, no more questions. :lol: JK

The 3 copies possible with both Player objects and Missiles are guaranteed horizontally, you set a gap distance and the number of copies to 1, 2, or 3 and it draws every copy wanted with a single pass of all the scanlines the sprite occupies within its height. Changing sprite data in Frogger is done within isolated vertical sections of the screen or lanes of any height(Your choice on the height of the vertical zones as its defined by the Player objects height.).

The only instance where you have 2 or more passes of the same scanline involving the same sprite object is when you multiplex flicker one Player object to draw 2 or more different sprites within the same vertical zone or when you draw the same sprite but along the same scanlines at random distances from each other EG. Pac-Man ghosts move independently through the maze so they can't keep a set distance from each other within the same scanlines so they are rendered using multiple passes instead of one like fixed distance copies do.

Its usually costly to change things per scanline thus the vertical isolation and stacking layouts common to 2600 games. I've been mostly trying to work around this limit since it restricts the types of games you can make, how many variations on Pong and Kaboom can the human race endure? :)

Offline HughSpectrum

  • 0010
  • *
  • Posts: 279
  • Karma: +0/-0
    • View Profile
Re: Atari 2600 pixel art?
« Reply #23 on: March 09, 2012, 08:27:44 pm »
Okay so, you just mean that each lane has sprite copies within them, but the sprite changes when you go to the next row?

Offline BladeJunker

  • 0001
  • *
  • Posts: 84
  • Karma: +0/-0
  • Know your limits, then break them.
    • View Profile
Re: Atari 2600 pixel art?
« Reply #24 on: March 10, 2012, 12:27:20 am »
Quote
Okay so, you just mean that each lane has sprite copies within them, but the sprite changes when you go to the next row?
Yes each sprite has its copies within each lane by default, like a conveyor belt. The sprite can change for every row or lane thus in Frogger it starts with a log lane then turtles, then log, log, turtle, truck, car1, car2, and lastly car 3 which all share the same object but since they are vertically isolated from each others scanline "zones" there is no flicker byproduct.
« Last Edit: March 10, 2012, 12:35:34 am by BladeJunker »

Offline Lazycow

  • 0010
  • *
  • Posts: 145
  • Karma: +0/-0
  • Do androids dream of electric sheep?
    • View Profile
    • homepage
Re: Atari 2600 pixel art?
« Reply #25 on: March 17, 2012, 09:22:10 pm »
Standard Resolutions: 320x192, 320x96 (double tall pixels), 320x64 (triple tall pixels), or 320x48 (quadruple tall pixels)
foreground color can change within the scanlines (I assume keeping to the 8 pixel wide grid?)

Nice summary about the restrictions, but I would like to disagree about the point "foreground color can change within the scanlines". You should remove that one, because the screen is build by the CPU in realtime each frame and after handing game mechanics and building up the screen, you do you have any time left for such tricks. (There might be coder-demos, but I do not know one single game which such effects)
A man touched down on the moon, a wall came down in Berlin, a world was connected by our own science and imagination. Yes we can!

Offline BladeJunker

  • 0001
  • *
  • Posts: 84
  • Karma: +0/-0
  • Know your limits, then break them.
    • View Profile
Re: Atari 2600 pixel art?
« Reply #26 on: March 17, 2012, 11:54:24 pm »
Standard Resolutions: 320x192, 320x96 (double tall pixels), 320x64 (triple tall pixels), or 320x48 (quadruple tall pixels)
foreground color can change within the scanlines (I assume keeping to the 8 pixel wide grid?)

Nice summary about the restrictions, but I would like to disagree about the point "foreground color can change within the scanlines". You should remove that one, because the screen is build by the CPU in realtime each frame and after handing game mechanics and building up the screen, you do you have any time left for such tricks. (There might be coder-demos, but I do not know one single game which such effects)


Thanks, the summary is still a work in progress. The quote you have used is from HughSpectrum which isn't my choice of words but as far as changing the Playfield or other sprite objects color per each horizontal line of resolution contained within said object that is done in almost all 2600 games and from what I've learned game mechanics are usually processed in the blanking period of graphics rendering but you're right code kernel timing is a sensitive issue.
I'm glad you brought it up since multi-color use does come with costs and I haven't emphasized that enough in my summary other than telling people go easy on them. I'm not any kind of programmer but I'll try to make sure people understand the double edged sword that is the 2600 IE. if you do this you can't do that and so on. :)

« Last Edit: March 17, 2012, 11:57:02 pm by BladeJunker »

Offline Lazycow

  • 0010
  • *
  • Posts: 145
  • Karma: +0/-0
  • Do androids dream of electric sheep?
    • View Profile
    • homepage
Re: Atari 2600 pixel art?
« Reply #27 on: March 18, 2012, 09:24:12 am »

Atari 2600 / C64
(I think the left screenshot shows the limitations very good)
« Last Edit: March 18, 2012, 09:29:30 am by Lazycow »
A man touched down on the moon, a wall came down in Berlin, a world was connected by our own science and imagination. Yes we can!

Offline BladeJunker

  • 0001
  • *
  • Posts: 84
  • Karma: +0/-0
  • Know your limits, then break them.
    • View Profile
Re: Atari 2600 pixel art?
« Reply #28 on: March 18, 2012, 06:16:30 pm »

Atari 2600 / C64
(I think the left screenshot shows the limitations very good)
Yes very good example, they make very clever use of each individual line of Playfield color in all their tiles plus the blank lines and offsetting all work well together. Thank you I mentioned Boulderdash but I should have posted some images as an example. Definitely best to work with the limitations than against them like I do sometimes. :)

Offline BladeJunker

  • 0001
  • *
  • Posts: 84
  • Karma: +0/-0
  • Know your limits, then break them.
    • View Profile
Re: Atari 2600 pixel art?
« Reply #29 on: March 30, 2012, 06:26:50 pm »
Quote
Ball sprite: Single pixel that is 2x, 4x, 8x, or 16x wide, can be any height.  Cannot be copied.
Quote
Pixel sizes look good. Can not be copied is a little strict since by default the hardware may not support a copy per se, but with the right setup of multiplexing you could get more than one per scanline. I admit that multiplexing is a less stable and dependable option but it still exists. Perhaps another * is required? ^_^
Okay I have to apologize to HughSpectrum for this statement since this is so not true. The Ball is a single entity per vertical scanline zone and I'm sorry to anyone who read this as the Ball object can not multiplex or copy at all. I'm still learning, I thought it was a matter of CPU cycle cost instead of being an impossibility to render. :-[

Offline BladeJunker

  • 0001
  • *
  • Posts: 84
  • Karma: +0/-0
  • Know your limits, then break them.
    • View Profile
Re: Atari 2600 pixel art?
« Reply #30 on: March 31, 2012, 09:18:59 pm »
Still working on my inquiry into HUD/Menu/Text based rendering and memory footprint issues so stay tuned. ;D

I thought I'd discuss isometric graphics on the 2600 a bit for now as one of my mandates for delving into the 2600 was increased depth in graphics since most of the really early games tend to have avoided perspective entirely IE. Egyptian Art even though in most cases they didn't have to. It got better over time on the 2600 but too often depth wasn't even tried for.

I have to say after trying it many different ways your best bet is to use the Playfield solely despite its coarseness, trying to smooth it further using the other sprite objects on average just results in a smoother level graphic with nothing in it. :lol:

Not many isometric games on the 2600 but I'll start with the one most refer to, Crystal Castles.

Here you can see the basic one color setup of wall and top surfaces defined, basic but it works.

Here's my attempt at Super Mario Land 3D, trying for a SMBRPG type of game.

The same rules apply in regards to a master grid scale used by every unit so its still recommended that you create a universal unit or tile size just to plot out dimensional structure and shading consistency. Because of the zig zagging use of multiple colors per scanline I'm looking at per scanline color changes in the Playfield coupled with Missile or other sprite objects overlayed at differing colors to create these instances of more colors per line. The obvious challenge of this is that the sprites would share the same default colors as there paired object(Player & Missile) that they risk disappearing when overlapping. I'll probably have to limit it to 2 colors giving top and wall surfaces a distinct color and do what I can with the remaining 2 distinct colors for game sprites.

Another option is to try and utilize the Background and create bands of color to show through Playfield holes. The main issue with that method is that the Playfield has to be solid outside the isometric squares otherwise you'd have to blank the protrusions with object overlays. It certainly is challenging to increase visual depth in 2600 games but I think its worth it as the flat Egyptian look never looks right. :sigh:

The use of isometric "construction lines" is possible but I find it can get noisy with Playfield pixels to define every square or that every single bit of surface contains dither so I tend to just outline the protruding forms and reserve dither for shadows and or dark shading whether a single color Playfield or not.

Even if you intend to spend all your objects on an isometric graphics rendering alone the basics are a flat shaded polygonal look which allows you to smooth the outer defining edges but fill with general Playfield pixels.

Here's Escape from the Mindmaster.


And here is its rendering distribution.

It uses a diagonally staggered Ball rendered wedge tile on the left and a diagonal Missle1 line to create the same angle on the right, with also Player1 used to create door holes even though it technically is on top. Although not isometric I thought it was a good example of omission through addition.

*Okay I think I can explain the 3 color clock or 6 pixel wide line segment in the wedge tile made from the Ball object. It isn't multiplexing it, its moving it left to right in horizontal position very quickly that it appears to be a 3 color clocks or 6 pixels wide line but its really 2 color clocks or 4 pixels wide rendered to 2 positions. Still that function is worth noting for use in anything rendered with the Ball object IE. a bit constructed sprite.
« Last Edit: April 14, 2012, 11:39:41 am by BladeJunker »

Offline JinnDEvil

  • 0001
  • *
  • Posts: 43
  • Karma: +0/-0
  • Go Commander! Go!
    • View Profile
Re: Atari 2600 pixel art?
« Reply #31 on: April 02, 2012, 01:40:04 am »
Hi pals!

I was playing around and I got this. But I was wondering... Is it a valid atari 2600 mockup?



[edit]

Some more:

« Last Edit: April 02, 2012, 03:25:54 am by JinnDEvil »

Offline BladeJunker

  • 0001
  • *
  • Posts: 84
  • Karma: +0/-0
  • Know your limits, then break them.
    • View Profile
Re: Atari 2600 pixel art?
« Reply #32 on: April 02, 2012, 06:45:02 pm »
Hi pals!

I was playing around and I got this. But I was wondering... Is it a valid atari 2600 mockup?



[edit]

Some more:



First I must compliment your excellent work, very nice. However to answer your question, no its not valid for the 2600. I think it could work on a 5200 but it would be tight, so let's say "as is" would be Atari 7800 valid. :)
Actually most of it could be rendered on a 2600 with careful layout structures but nothing could overlap vertically without severe amounts of flicker since the sprites per scanline limit would exceed if anything moved. So maybe a cutscene storyboard at this graphics standard (EG. Centipede 2600 title screen versus in game graphics.)

edit.

Your color distribution is very good as the deep shadows work well and the instances of differing colors using Background color bands with Playfield holes should work with deliberate vertical scanline isolation which most of it does incorporate already.
Most of my edit deals in utilizing the Playfield resolution solely for your level graphics as the overall scale of the game sprites and the amount of vertical scanlines they occupy in total don't really allow for the use of Player object based tiles for finer detail as the 2 Player objects and there Missiles are completely occupied with the player and enemy sprite rendering. On 5200 and 7800 especially there is more leeway since you have more sprite objects to dedicate to "extra" tasks.

It probably wouldn't be too troublesome to multiplex the Player objects for the 57 numeral, the lighting fixtures, and the bottom screen hanging cables from the Player objects as the game sprites are less likely to vertically overlap with ceiling sprites or sprite zones separated by an unbroken ground line. As soon as Clarke jumps the 57s would most likely clip just to maintain his flicker stability jsyk.

Also you have exceeded 192 lines of vertical resolution which will burden the CPU more which lessens how much change you can invoke per each frame render, things like color changes per scanline and complex sprite kernels will become hard to impossible to get within CPU budget. Although I like 192 or 1 line kernel as a standard its very hard to achieve and maintain on average that exceeding 192 will only work with much more graphically simple games than this.

edit.

Sorry its crude since I just rescaled it but it does demonstrate what would be needed to achieve this size of image on the 2600 which is quadruple wide pixel standard as much of it can be rendered with the Playfield with the remaining smaller 4 pixel wide segments made from any and all applicable sprite objects. If you want it double wide pixel resolution using this style of image you're limited to 48 pixels of width or the Title Kernel Screen standard.

edit.

I'm afraid your sprites are just too big for a 2600, even if you multiplexed both Player objects 3 times max per game sprite the degree of flicker would be very high and there wouldn't be enough machine (CPU) cycles left after to do much else. The more you push each sprite object beyond there defaults the more expensive and unstable they become to render effectively.

Based on trying to maintain the size of sprite used in this mockup the following setup could work:

-Both sprites would have to share the same colors per scanline since they would be sharing color paired objects primarily the Missiles. Because of this I'm thinking a single color would be recommended as multi-color would be hard to achieve unless you prioritize Clarke and just let the Necromorphs scanline colors "twinkle" as Clarke animates.

-The Clarke sprite would be Player0 & Player1 paired together with a 3rd block multiplexed to the right to get the held gun extension. By pairing them and having both objects share the multiplexing duty of rendering the 3rd block the degree of flicker can be reduced to "reasonable" levels.

-The Necromorph sprite uses Missile0 & Missile1 in a low res bitmap manner which varies width per scanline and utilizes Missile copies and there respective color clock tile gaps. While this produces a rather blocky sprite compared to Clarke I thought the alien or monster like qualities could excuse its crudeness.
Also one monster fight at a time or 2-3 monsters of the same type moving in unison.

-Clarke's projectiles would likely flicker since they would have to be multiplexed Missiles which are already rendering the Necromorph. The projectiles would have to be less stable visually to maintain the Necromorph pixels. The problem with using the Ball object as a projectile isn't its lack of multiplexing since a vertical scanline offset per fired projectile would work but rather its that the Ball shares the same color as the Playfield so it get masked.
I'm just spitballing but it might be possible to use a Playfield rendered projectile which omits a pixel creating a hole in the graphic that a Background color line could show through which moves across the screen, kind of like a moving inverse 2600 Pac-Man pellet. Besides the CPU overhead it would kind of be fast moving as it jumps 8 pixel widths.

-Although not used in my edit the Ball object is free to draw one extra detail in the Playfield per vertical scanline zone. It can't do much but varying the width per scanline could form an interesting shape.


Anyway if you want more detail you'll have to go smaller in scale with more isolated individual floors to leverage your sprite objects further since a single floor or level limits what you can do IE. small number of sprites over a small area versus a few sprites over the entire screen.
As far as sprite size it starts out simple enough expanding past 8 pixels of screen width to a moderate size then it gets troublesome to achieve for medium scale sprites before getting easy again with giant blocky Playfield sprites.

Based on your mockup and my edits this would likely be challenging to make on the 2600, I won't lie that an experienced 2600 programmer might say maybe while a 2600 programming novice would say yes but it would take a while, need much assistance, and they would be exhausted afterwards. :lol: It's up to you how you want to proceed since you could make it a 7800 game or with a few small changes could turn your mockup into a very respectable C64 game. :)

Offline JinnDEvil

  • 0001
  • *
  • Posts: 43
  • Karma: +0/-0
  • Go Commander! Go!
    • View Profile
Re: Atari 2600 pixel art?
« Reply #33 on: April 02, 2012, 06:51:29 pm »
Whoa!!

Thanks for such a detailed explain, BladeJunker! ;D
I also loved your demakes! Thanks again! ^^

But since it was just a time kill, I'll call it a 7800 game.
« Last Edit: April 02, 2012, 06:54:41 pm by JinnDEvil »

Offline BladeJunker

  • 0001
  • *
  • Posts: 84
  • Karma: +0/-0
  • Know your limits, then break them.
    • View Profile
Re: Atari 2600 pixel art?
« Reply #34 on: April 03, 2012, 05:05:10 pm »
Whoa!!

Thanks for such a detailed explain, BladeJunker! ;D
I also loved your demakes! Thanks again! ^^

But since it was just a time kill, I'll call it a 7800 game.
Well I had some time and I really like your mockup so I thought a full analysis was prudent. Thanks for the compliment, I think demakes are quite neat in general.

Lol yeah I think of jumping ship often to the 7800 since despite some complications in pointer based programming it is much easier to design pixel graphics for. :lol:

Offline BladeJunker

  • 0001
  • *
  • Posts: 84
  • Karma: +0/-0
  • Know your limits, then break them.
    • View Profile
Re: Atari 2600 pixel art?
« Reply #35 on: April 08, 2012, 05:18:35 pm »
Oh I just wanted to recommend this book on the 2600, its a fun read which includes easy to understand tech jargon, amusing anecdotes, and a great deal of Atari history as well. :)

Racing The Beam.

Offline BladeJunker

  • 0001
  • *
  • Posts: 84
  • Karma: +0/-0
  • Know your limits, then break them.
    • View Profile
Re: Atari 2600 Pixel Art Guide
« Reply #36 on: May 24, 2012, 07:03:25 am »
Well I'm not done looking into text related rendering but I can at least discuss the basics to begin with.

The majority of text rendering on the 2600 is Player object based or to be more specific heavy multiplexing of Player0 & Player1 and the application of what is called the Venetian Blind display kernel. So its fair to say you're looking at a very prerendered setup for text display like single words, 2X1 letter clusters, and tile constructed fonts.
The Venetian blind methods primary element in function is the memory nybble that exists in the 2 Player objects which have an upper and lower nybble for every 4 bits wide. Basically it shifts both 4 bit wide segments of the Player object up & down per scanline with some flicker, it has the benefit of being fast to render but also that even with flicker it keeps a solid consistent appearance. The main drawback of this is that a 1-line render will look like a 2 line-render or losing half your visible height resolution despite the benefits.
Also this method has a higher cycle cost than a normal display kernel so those costs have to be considered. How much cycle cost really depends on the design of the game you intend but one thing is certain is that you should really decide upon a maximum character amount as the more you push for more characters the less you can do overall in terms of effects and other display trimmings.

Here's a neat kernel that managed 32 characters with a 3 pixel wide font at 2 characters per Player object. That's the big thing to get the maximum number of characters to display.
http://www.atariage.com/forums/topic/180632-32-character-text-display/page__st__25

I've been aiming for less characters but larger character fonts for better legibility but no one seems to interested in that yet. Mostly I've been pursuing what I would call the standardized CRT to text approach which is best described in this article. I can't see the images in the page but maybe you can. ???
http://www.gamasutra.com/view/feature/130498/crossplatform_user_interface_.php?print=1
I subscribe to the standards set in this article when it comes to retro gaming as we went through many games with fancy fonts that were hard to read on our game consoles over the years. I was actually quite pleased when I started seeing DS games with big letters that compensated for the distance I hold the unit away from myself and I feel the same way about font to CRT clarity issues.

*Actually that issue with Dead Rising on a SD-TV being unreadable is inexcusable since the level of memory and HUD to font scale options possible today allow not just SD support but also help for people with varying levels of eyesight quality. I don't want to rant but for crying out loud don't neglect the deaf or people with poor eyesight who play video games ijs.

Format:

Its not too difficult to produce content at this standard as you just use a 1:1 pixel unit to compose the image, strip out every second horizontal line, and then offset 50% of the width either up or down the for every Player object sprite block.

I mention 1-line kernel rendering that looks like 2-line but this also progresses lower as well with 2-line rendering looking like 4-line rendering which is what I'd consider the limit of this technique except for large screen filling text or a coarse resolution bitmap.

Now this halving of the vertical resolution is not default since you can actually use the venetian blind rendering with 1-line rendering which people have applied to game sprites, its mostly that in large doses of sprite multiplexing the skipping of lines helps overall with timing and CPU demands of pushing beyond 2 Player objects. So if you were doing a 1 on 1 competitive game 2 sprites with 1-line venetian blind rendering would be mostly practical while a sports game with teams of players or in the case of text with its multiple characters would more the likely need to skip lines or even thicken the scanlines to cope.

For a little background on this here's an interview with the inventor of Venetian Blind rendering.
http://www.digitpress.com/library/interviews/interview_bob_whitehead.html
« Last Edit: June 23, 2012, 06:57:32 pm by BladeJunker »

Offline BladeJunker

  • 0001
  • *
  • Posts: 84
  • Karma: +0/-0
  • Know your limits, then break them.
    • View Profile
Re: Atari 2600 Pixel Art Guide
« Reply #37 on: June 23, 2012, 07:54:33 pm »
Well despite being busy with Skyrim like a lot of people lol, SeaGTGruff offered some suggestions to this guide that I will endeavour to integrate. So big thanks to him and all his help. :)

Earlier I mentioned his mockup standard of 800X576 which approximates the 5:3 pixel aspect ratio of the display rendered on actual 2600s. Well he furnished me with his templates that I think I should add here as an option for composition since the stretching aspect can get the better of you (I know it does for me.) at times for large compositions and you end up with skinnier and taller images than intended.

He tends to split his work into seperate layer mockups of Playfield and Player object composition. His template has benefits since it is pretty close to 4:3 in shape that you'll get a more accurate final graphics appearance without the back & forth of mockup resampling tests. Also the guide/approximation of scanlines is fairly authentic to the TIA output visual standard.

Mirrored or Reflected Playfield:


Tiled or Repeated Playfield:


Player object resolution:


And here's a full application:

I'm guessing he copy & pastes sections from both using the grid lines for alignment. Quite a nice layout actually, I'm curious to see how this game will turn out. ;D

Well you can use these directly or setup something similar with layer orders maybe have the scanlines as a layer toggle in your graphics programs.

I've been quite busy house cleaning and designing my 2D block construction game so I'm not too sure when I'll get started adding his suggestions.   ???