[stella] Newbie Screen Design Documentation

Subject: [stella] Newbie Screen Design Documentation
From: Christopher Tumber <christophertumber@xxxxxxxxxx>
Date: Fri, 12 Sep 2003 13:17:46 -0400
This is a first draft of a document explaining the limitations of Atari 2600 screen design. It's intended as fairly comprehensive documention for all the non-coders designing mock-up screenshots. It doesn't touch on really sophisticated techniques (yet?) like the RESPn trick or VDELPn (Well, possible use of VDELPn is implied). It's just intended as a non-technical reference guide to designing realistic screens.

Any comments would be appreciated...

The screen is 160 pixels wide. In NTSC mode it's 192 scanlines high in PAL it's 242, however you generally want to leave a couple lines at the top and bottom for "housekeeping" (ie: positioning sprites) as well as because not all TVs are positioned the same vertically (ie: the very top and bottom rows may not be visible on some TVs).

The screen is drawn from top to bottom and left to right. The display is generated by the program "on the fly" by changing registers (bitmap, colour, etc) either between scanlines or while a scanline is being drawn.

There are 128 colours available in NTSC and 104 in PAL as shown in this chart:


There are two player sprites, each are 8 pixels wide. Each sprite is one scanline tall so to create a "real" bitmap, the sprite bitmap register must be changed every scanline.

There are two missile sprites and a ball sprite. Each may be set to 1, 2, 4, 8 pixels wide and are switched on and off as needed. These are "blocks" not bitmaps but sometimes they are used to create simple sprites (ie: not just missles). Two or three missles/ball used together can create a pretty wide variety of shapes.

The player sprites (independant of each other) may be doubled in width or quadrupled in width or duplicated or triplicated. The distance between duplicate/triplicate sprites is limited (Close, Medium, Wide). Close is 8 pixels between sprites. Medium is 24 pixels between sprites. Wide is 56 pixels between sprites. Wide is only available to duplicate sprites, not triplicate. Duplicating or triplicating a sprite also creates the same affect with its missile.

Sprite colours may be changed between scanlines. They may be changed mid-scanline as well (ie: between duplicate/triplicate sprites).

Sprite bitmaps may be changed between scanlines. They may be changed mid-scanline as well (ie: between duplicate/triplicate sprites).

Sprites will "wrap around" the edges of the screen.

Generally, repositioning any sprite (ie: to re-use it) horizontally takes a scanline per sprite and what can be done on that scanline is EXTREMELY limited (ie: that scanline will often be a duplicate of the previous one, or maybe a blank scanline). The exception is if you only need to move the sprite anywhere from 7 pixels to the left to 8 pixels to the right from it's current position. That generally doesn't require a whole scanline (ie: moving a sprite +1 usually won't require a whole scanline).

Backround (also known as playfield) blocks are 4 pixels wide (40 blocks). The playfield is two colours, foreground and background. Foreground and background colours may be any colour. The 2600 actually only uses playfield bitmap data for the left half of the screen. The right hand side of the screen is either a copy of the left or a mirror image of the left. It is possible to make an asymetrical playfield by changing the bitmap data mid-scanline. However this counts as a "change" (see next paragraph). The playfield data is 3 bytes wide so a truly random playfield will count as 3 "changes". For this reason some playfields use a static border and only the center of the playfield varies.

Every "change" (ie: colour change, bitmap change) to the screen from the previous scanline or from what's already been drawn this scanline takes time. There is a limit to the amount of time available to you during scanline as well as between scanlines. In addition you may run into timing problems if you're trying to make multiple changes at the same point on a scanline (ie: trying to change a sprite colour at the same time as changing a playfield bitmap).

The minimum amount of time between changes is 9 pixels. However this may be difficult to do and may introduce other limitations - doing this often requires limiting the type of changes on that scanline severely (ie: only changing the background between two colours).

For static displays, 15 pixels between changes is usually safe. For dynamic displays 18 pixels is usually required. For truly flexible displays (ie: a huge number of different levels) you may need 21 or even 24 pixels. This is a bit generalised, but it's difficult to get more specific without understanding the coding requirements which are what determine these limits.

Generally the only things that get chaged between scanlines are:

- Player sprite bitmaps
- Sprite colours
- Foreground/background colours
- Background bitmaps

The amount of time between scanlines is equivalent to 68 pixels. Occaisionally things like missile width and sprite positionings will be changed between scanlines but that's not common.

The only things that usually get changed during a scanline are:

- Foreground/background colours
- Background bitmaps (asymetrical playfields)

Occaisionally you'll be changing sprite bitmaps and/or colours during a scanline (ie: duplicated sprites using two different bitmaps/colours) but that's uncommon.

It is very difficult to make these horizontally "changes" mobile. For example, if you have a player sprite that can move any position from left to right and you need to do a "change" to that sprite (ie: change the colour or bitmap for a duplicate sprite) mid-scanline this is quite difficult. You generally want to try to only apply "changes" to stationary objects (like the background or sprites that don't move) unless you have a REALLY good reason for doing so.

Some games use multi-plexed sprites in order to display, for example, more than 2 player sprites on a scanline. This is done by drawing an object only every other frame. So for example Sprite0 would be used to draw a player's ship on even numbered frames and an alien ship on odd numbered frames. If you're careful with this technique the results can still look pretty good but you want to avoid Pac-Man like flicker. Good colour selection helps, as does motion.


Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/

Current Thread