[Coco] Re: Ideas for a Graphics Project, part 2

[John Kowalski]

At 05:23 AM 26/10/2005 -0400, Roger Taylor wrote:
>It is much more complicated than that. First, the colors in the image 
>must be counted, determined, and reduced to two sets of dithered colors. 
>The colors for any pixel must be very similar in intensity on each 
>screen to reduce flicker when screen swapping. There is considerable 
>calculation done before the image is seen, taking 5-10 minutes if I 
>remember correctly. A similar method is used by the OS-9 program viewgif 
>written by Vaughn Cato.
>
>The three screen RGB flicker method, as used in the Projector, can 
>rapidly reduce colors to RGB sets. The drawback is that there is no 
>possibility of matching intensity of RGB colors making up any pixel. 
>Therefore flicker is quite noticeable.

Hi Roger,

Well, that's pretty much sums it all up right there :)
HiColor also had the option of disabling any of the steps in the process so
you could see what an image would look like with and without various tricks
- It could drop all the way down to simply rendering the image in 16 colors
with no dithering whatsoever.

Projector already has an algorythm for determining which 16 colors to select
when rendering an image on a 16 color screen, right?  You could just apply
this on a per-scanline basis instead of the complete image and you would get
a nice set of 16 palettes for each scan line.
Then instead of rendering the image to a 320x200 screen, you could stretch
it out so it renders to a 640x200 buffer - the additional resolution doubles
the number of pixels you can dither with.
Then split the 640x200 buffer into two 320x200 screens - every even pixel
goes into the 1st screen and every odd pixel into the 2nd screen.
(Well, that actually causes flicker... because the dithering is not evenly
distributed across both 320x200 screens.)
Then you can have a final pass at the two 320x200 screens that simply
tallies up the brightness (or better, the color error) of each screen and
swaps/reorders the pixels between the two screens so that they are visually
matched.

That isn't really how HiColor does it, but the thing about this technique
is, it doesn't really matter.  All that matters is that there are two (or
more) screens that essentially contain the same, but slightly different image.


*The crazy, more complex, longer-to-compute technique that HiColor supports
relies on the fact that HiColor *knows* it's rendering two screens.  It
doesn't have to use logical color combinations because perceptually, they
will not be noticed when the two images are toggled rapidly.  For instance,
it may dither purple and green in order to achieve grey - if it determines
that that is the best option to get that certain shade of grey.  (Because of
perception, persistance of vision and even the monitor itself, mixing black
and white is not the same as 50% grey...)


                                         John Kowalski (Sock Master)
                                         http://www.axess.com/twilight/sock/