Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!usc!apple!motcsd!xdos!doug
From: doug@xdos.UUCP (Doug Merritt)
Newsgroups: comp.sys.amiga
Subject: Re: 4096 colors in HIRES
Summary: More like 814 colors in HIRES
Message-ID: <412@xdos.UUCP>
Date: 4 Jul 89 17:30:28 GMT
References: <20069@cup.portal.com> <409@xdos.UUCP> <20112@cup.portal.com>
Reply-To: doug@xdos.UUCP (Doug Merritt)
Distribution: usa
Organization: Hunter Systems, Mountain View CA (Silicon Valley)
Lines: 70

In article <20112@cup.portal.com> stephan@cup.portal.com (Stephen Derek Schaem) writes:
>
>	Let me explain a little more about 4096 hires display, how it work and
> why nobody should cringe about it.

The reason I said some people would cringe is that it's been discussed
before, and some people felt that it was an esthetically "dirty" kind of
approach. But that's esthetics for you; different people have different
feelings.

>If you change the colors registers (384,000 times a second) you get you 4096
> colors screen

As I recall from previous discussions, you can't change that fast due
to latency of response from the chip. Someone once said they'd calculated
that you could change (I think) two colors in the palette per scan line
in the horizontal retrace period, and if you tried to change more, you
wouldn't finish in time for the next scan line. I never double checked
this myself, but you certainly should check before committing to this
approach.

>	You NEED a new way to store colors value since they involve a new
> concept, R,G,B,T.You already now what is RGB but T:-) T stand for
>timg^I5	V-.]X7ce.
^^^^^^^^^^^^^^^^^^^^^^^^^

Remarkably bad timing for line noise; I still don't know what T stands for.
Was that just "timing"?

>	The amiga don't store images as RGB, if you wanted to do so in 'copper
> mode' you would need 3 time the diskspace and alsoask each viewer to develop
> their own copperlist builder...

Actually, yes, I think that each viewer that supported this new IFF type
*should* have its own copperlist builder, because the alternative is to
dump the copperlist into the file, and that's too hardware dependent.

> create a new 'CMAP', a 'CCOP' with the RGBTP or RGBXYP. X,Y will correspond
> to the value for Wait(x,y) and the P to the position in the Amiga ColorTable
> when to store the RGB value.RGB value can be store in 4bits instead of 8bits.

If you mean to create a copperlist that waited until some certain (x,y)
position on the screen, and then switched to the next color map, then I
think that chip latency will screw you up. In other words I really do
think that you need to switch colors between scan lines, during the horizontal
retrace interval, and so you may as well just specify which color registers
to reload on each scan line. And as I mentioned above, you may be limited
to two register changes per scan line.

If this "two new colors per scan line" assumption is true, then at 400
lines per screen you'd get 16 + 399 * 2 == 814 colors per screen.

Another old idea is to time average colors, so that on one frame you
have color X in some pixel, on the next color Y, then back to X, etc, so
that you time average the colors to look like (X+Y)/2 at that pixel.
In hi res the refresh cycle would be 15 hertz (30 hertz / 2 frames per
complete set of colors), so it would help for colors X and Y to be
similar shades to reduce additional flicker.

Besides which, if you do a few experiments on paper using shades of
grey as a model, you'll see you can't get anything better than a new
hue midway between two existing hues even by using highly contrasting
colors, so you may as well use similar colors when possible.

Using this approach you can (ideally) double the number of apparent
on-screen colors, which would give 814 * 2 == 1628 colors.
	Doug
-- 
Doug Merritt		{pyramid,apple}!xdos!doug
Member, Crusaders for a Better Tomorrow		Professional Wildeyed Visionary