From: peterk@cbmger.de.so.commodore.com (Dr Peter Kittel Germany)
Newsgroups: comp.sys.amiga.advocacy
Subject: Re: **** A1200 Info **** (200+ lines)
Date: 13 Nov 92 14:16:11 GMT
Reply-To: peterk@cbmger.de.so.commodore.com (Dr Peter Kittel Germany)
Organization: Commodore Germany

In article <1992Nov12.205833.44294@news.th-darmstadt.de> wallmann@backus.pu.informatik.th-darmstadt.de (Natuerlich!) writes:
>In article <10046@cbmger.de.so.commodore.com> peterk@cbmger.de.so.commodore.com (Dr Peter Kittel Germany) writes:
>>In article <1992Nov7.174103.20817@news.th-darmstadt.de> wallmann@backus.pu.informatik.th-darmstadt.de (Natuerlich!) writes:
>>
>>Why "convert"??? You store it away like you want it on screen, perhaps
>>additionally compressed in some run-length or delta scheme, but that's
>>no conversion. What do you mean???
>
>I hope you didn't make your Dr. in Informatik or EE. 

Physik.

>Do you think
>your graphics hardware grabs the bytes out of RAM and hands them 
>to your monitor ? 

Yes, sure.

>It converts the binary information into analog signals.
>   --------

But that's nothing where the CPU or Blitter is involved, this is totally
separated electronics, called DAC, and it's the same principle in the
Amiga and the Falcon, though Amiga feeds 24 bits to the DAC and the
Falcon only 15.

>Again: the context was, that I said operating on HAM must be done with
>the CPU, 

You still don't get it: You *only* have to do really more work, when
you are generating/painting a *new* HAM picture. When this is all done
and lays ready on your harddisk, there is not any difference in speed
or effort for a HAM picture than for a "normal" palette (or true color)
picture with the same number of bitplanes! It's just setting some mode
bit when opening a screen and then feeding bytes to your bitplane data.
No more work for HAM than for any other mode. - The only difference
arises when you are painting or constructing a picture.

>It's apparently even for Amiga-users a
>much to wide step to think of a HAM screen as anything more than a 
>static display else neither the reply above nor the reply below would
>have happened. Procesing a HAM screen is synonymous for displaying it
>not changing it...

Sigh. You don't get it. E.g. let's consider a HAM animation. This is
normally stored as delta information, i.e. you only store changes to
previous frames. So you load some control bytes from your disk that
tell you where in your bitplanes (not necessarily HAM, it's the same
for all modes) you have to insert which new values. So you take these
bytes and put them in the appropriate places in your bitplane memory.
Again, no special procedure for HAM, except that you need considerably
fewer bitplanes to achieve the same graphical effect.

>Well I am no broadcasting corporation, nor am I a video amateur. If the
>Amiga is considered nowadays to be a video processing computer foremost,
>sorta like a microwave oven with a 68000 is not considered a home computer
>foremost, so be it. I am not quite sure all Amigoids know about it.

Oh, most know. And who owns an Amiga will do easy to recognize it in
various TV shows where it does some splendid graphics. (Ex. ZDF Gluecks-
telefon)

>OK I'll believe you there (for the sake of argument). The methodology is 
>still very wasteful (even If you don't have to start at pixel 0) on 
>CPU time. 

*Only* in special, *not* everyday cases! Namely when constructing
a picture, *not* when just displaying it. I still fear you think
just to display such a picture also loads the CPU like hell, and
this is not the case.

>I can't quite imagine how one knows from looking at a pixel (#1#)
>that you have reached a basepixel there. Is there a little bit saying, 
>"hey, I am a basepixel, my color register hasn't changed ?"

YES! YOU GOT IT! WOW! Look, in either HAM mode, you have 6 or 8 bits per
pixel. Always two of them contain control information: If they both are
zero, it indeed means, this is a base color!!! The other three possible
cases identify which of the three color components shall get modified
with the rest of the bit data (4 or 6 bits).  So, is your problem now 
solved???

>Anyway this apparently means for 16 or 64 colors I am guaranteed a 'hit' 
>whereas for the other couple of thousands I am still losing. 

No, look at real-world situations, where the color shade does not change
so rapidly, like human skin, portraits. With a well selected base color,
you already come *near* to the real shade, so that it doesn't jump in
your eyes as a wrong pixel. And with the next or second next, you can
get *perfect*. And here I mean perfect up to the color resolution which
your computer provides. On AA and HAM8 this means 24 bits color resolution,
which the Falcon does not provide. HAM shines when you have not too many
and not too different or drastic edges in your picture. This is luckily
the case for most real-world applications. If a picture is very detailed,
then there are still cases, where HAM can show off ideally, when the
occuring colors don't vary too much and can get covered considerably
well by the base colors.

Believe me, I do know a little about the ins and outs of HAM, as I have
spent some time to write a software to convert pictures from 24 bit
true color to HAM. I'm not yet a master in this art, but I learnt already
much from it.

-- 
Best regards, Dr. Peter Kittel  // E-Mail to \\  Only my personal opinions...
Commodore Frankfurt, Germany  \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk