Re: R: [stella] PCMSG 2.5 (Oystron?)

Subject: Re: R: [stella] PCMSG 2.5 (Oystron?)
From: Glenn Saunders <krishna@xxxxxxxxxxxx>
Date: Tue, 2 Sep 1997 21:18:00 -0700 (PDT)
On Tue, 2 Sep 1997, Nick S Bensema wrote:
> Multicolored double-line graphics seldom look as good as monochrome
> single-line graphics....

I feel the opposite.  Color changes exploit the 2600's generous 128 color
palette.  In the era of 8 or 24-bit graphics it's very important these
days to exploit that capability even more than it is to do single line
resolution.  Throw up as many colors as possible.  Doug Neubauer knew
this, which is why Solaris, Radar Lock, and Super Football almost
exclusively use sprites with wild gradients.  They also use single line
res almost exclusively as well, but still...

However, sometimes it is better to use single line res if the screen is
getting crowded with huge sprites.  Piero's game doesn't require single
line res sprites.  If his oysters (or asteroids) were single line res but
monocolored I don't think they would have looked as good.  Not if he
adopted the same basic shape.  If he actually gave them a scallopped
outline, maybe, but overall the resolution would have been wasted just to 
make the edges smoother.

> If you have a single object available through the entire length of the
> screen, preferably always the same color, you could plant it in a single
> spot at the top of the screen, but as the rest of the screen is rendered,
> move the sprite left or right by one pixel every eight or more scanlines.
> If my imagination has this right, it should look great as lightning if
> applied to only a few frames at a time, or as some kind of electromagnetic
> attack from above if used continuously for a while.

I will be logging my footage in a day or two, but there was someone who
said that they started with the kernel and made a game out of it rather
than the reverse. 

With the 2600, it's sometimes best to do it this way because you have
already figured out how to display something.  Finding a way to make it
into a game is easy.  Starting with a concept and then having to get the
2600 to jump through the hoops to pull it off can sometimes be frustrating
and disappointing.  The 2600 provides you with certain resources, not all
of which can necessarily be exploited at once due to memory limitations,
running out of cycles for both number crunching operations and writing to
graphics registers, and so on.  It's a miracle, for instance, that David
Crane's movable 6-digit score routine in Dragster actually works, and even
then, the problem becomes that there is no CPU time left to speak of to
fill either side of the huge megasprite.  That's why the dragon in
Dragonfire shoots up.  It's quite a balancing act, and is what makes the
2600 such a fascinating machine to play with as people push and pull it in
various ways with an infinite number of combinations.  Contrary to Mr.
Moeller's opinion, I don't see how the Intellivision is in any way
analogous for the potential programmer.

Anyway, kernel-first.  That's how Piero's game came about.  He started
with an exercise on how to get multiple independently moving objects
sliding back and forth in discrete vertical slots.  Pretty soon he was
color-striping the players like the thieves screen in Raiders of the Lost
ark and things were looking nice.  It's something that the 2600 does very
well, and is the best way to get the 2600 to give the illusion of having a
shitload of colorful sprites when it only has a few monochrome ones.

> "Curvy" might refer to steerable shots that can be controlled with the
> joystick.  This has been around since Combat.  I don't think it would
> look good considering your current implementation of missiles.

Sometimes curvy shots can be more of a liability, in which case it can be
used as a way to make the game more difficult for certain variations.

Archives updated once/day at
Unsubscribing and other info at

Current Thread