[stella] Some experiments in Interlaced graphics

["Andrew Davie" <atari2600@xxxxxxxxxxxxx>]

Hi All.

Was going to write and suggest someone try this... but ended up doing it
myself.  So here it is...

Some may be familiar with the "interleaved chronocolour(TM)" technique,
which achieves a colour display by successively displaying three different
frames of graphics, each of those frames consisting of red, green, and blue
lines of pixels from an original image.  The trick being that successive
frames show (for any line) the red, green, and blue pixels for each line.
Combined with judicious dithering of the separated colour planes (this step
is VERY important, otherwise you just get monotone 8-colour images) to give
shading of the colours, this gives a reasonable colour image on the '2600.
The attached "marioRGB_ICC.bin" (NTSC) "marioRGB_ICCPAL.bin" (PAL) and
"marioRGB_ICCSECAM.bin" (SECAM) files show this technique in action.

I got to thinking that it would be nice to use interlacing (proven to work
in late 2002 by Billy Eno - and whose code I directly lifted - thanks!) -- 
in combination with interleaving and dithering -- to improve the colour
display techniques on the '2600.  In particular, I was thinking that if two
successive scanlines were RED pixels and GREEN pixels of an image (on one
field of a frame), then if the next field had the BLUE pixels first, that
would effectively be placed between the RED and GREEN.  Thus, they'd form a
triad, giving a perceived colour pixel.

More to the point, if a single field is displaying R G B R G B R G B
(scanlines) and the next field is displaying B G R B G R B G R...
(scanlines) then the combined fields (giving a frame) would essentially be
(RBG)(RBG)(RBG) -- the grouping just a conceptual one -- which could also be
seen as R(BGR)(BGR)(BGR).  That is, triplets of colour.  So, on any FIELD we
are seeing triplets of RGB (over 3 scanlines), but also on any FRAME we are
also seeing triplets (but over only 2 scanlines).  I hope that's clear!  It
sounded very interesting, so I thought I'd suggest someone tried it.  I
wrote my proposal, but then I started tinkering!  Oops!  Several hours
later, here we are.

There are a couple of interesting points to note.  Firstly, as the ICC
system interleaves 3 frames, the data size is 3 'colour planes' (even though
these are interleaved themselves).  Since the interlaced display only has
field 0 and 1, I dropped one of the three ICC colour frames (remember, a
whole frame isn't red or green or blue, it's lines of red AND green AND
blue).  The result, then, is that the data required to display an
interleaved, interlaced mario is only 2/3 of the size of that required for
an interleaved chronocolour(TM) mario (simply because we're using only 2 of
the 3 frames).  Remember, to run interlaced mode in z26, you must use the -!
command line flag.  The binary "marioInterlaced.bin" demonstrates the first
'picture' interlaced image on a '2600, I think -- prior demos were just
hand-drawn lines, etc.

I took one frame consisting of RGBRGB... scanlines, and display that on
field 0 of the interlaced display.  Then, on field 1 I display a frame
consisting of BGRBGR... scanlines (or was it GRBGRB -- it doesn't really
matter -- just have to make sure the combined frames form triplets).  The
theory is that when combined into a true interlaced display, the blue lines
will effectively sandwich between the previous frame's R and G...  etc.  So
I went ahead and did this, and here are the results.

What's REALLY interesting (to me, anyway) is that the mariointerlaced.bin
binary looks good even when NOT viewed in interlaced mode.  Sure, it's a bit
stripey... but it doesn't exhibit the rolling colour lines and 'shimmer'
associated with the Interleaved Chronocolour(TM) process.  In fact, it's a
pretty good colour image by itself.  I found this out accidentally, by not
including the -! switch in my tests.

So, what's different about the technology from Interleaved ChronoColour(TM)?
Not much, possibly -- it's a variant to put in your toolbox.  The use of 2
of the 3 Interleaved Chronocolour(TM) frames... gives a non-shimmering
colour image with a bit less vertical colour resolution.  The incorporation
of interlacing with these two frames should (on a real TV) provide a
higher-resolution 'blended' version of the two frames.  The attached
binaries show reasonable colour images using interlaced video.  The images
also look just fine (even better than Interleaved Chronocolour(TM)??) when
viewed as NON interlaced images under Z26.

I'm interested on reports from those who can test these on the Real Thing
for me.

Cheers
A

Attachments (OK, I went overboard...)...

marioRGB_ICC.bin            NTSC Interleaved ChronoColour(TM) Mario
marioInterlaced.bin            NTSC Interlaced Mario
marioRGB_ICCPAL.bin        PAL Interleaved ChronoColour(TM) Mario
marioInterlacedPAL.bin        PAL Interlaced Mario
marioRGB_ICCSECAM        SECAM Interleaved ChronoColour(TM) Mario
marioInterlacedSECAM.bin        SECAM Interlaced Mario

Attachment: marioRGB_ICC.bin
Description: Binary data

Attachment: marioInterlaced.bin
Description: Binary data

Attachment: marioInterlacedPAL.bin
Description: Binary data

Attachment: marioRGB_ICCPAL.bin
Description: Binary data

Attachment: marioInterlacedSECAM.bin
Description: Binary data