AuthorTopic: Atari 2600 Pixel Art Guide  (Read 44727 times)

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: 59
  • Karma: +0/-0
  • Go Commander! Go!
    • http://pixeljoint.com/p/17621.htm
    • http://jinndev.deviantart.com/
    • http://jinndevil.tumblr.com/
    • 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: 59
  • Karma: +0/-0
  • Go Commander! Go!
    • http://pixeljoint.com/p/17621.htm
    • http://jinndev.deviantart.com/
    • http://jinndevil.tumblr.com/
    • 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.   ???