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

In article <1992Nov7.174103.20817@news.th-darmstadt.de> wallmann@backus.pu.informatik.th-darmstadt.de (Natuerlich!) writes:
>As to the questions I am not going to answer: There was a diatribe
>portraying in length how just very useful HAM is. Dudes for the last time:
>as useful as it may be (for you) you cannot say HAM is just as useable as 
>a RAP mode. (Else you would have only HAM modes on computers.)

Ok so far. Nobody can seriously deny that there exist limitations when
using HAM mode.

>So when comparing screenmodes to establish some 'bogus' superiority of the 
>AA chipset, using HAM colors is bullshit. 

Now you sound stupid again. There *are* many many occasions where HAM turns
in as superior: Number of colors on screen, animation and its speed. These
are vital issues in graphics applications and make HAM a very good choice
for a big number of graphics applications. Perhaps (perhaps!) not the
majority of them, but with the above mentioned ones, a considerable share.

>A better metric is Mbytes/s on 
>the graphic hardware. How many RAM bytes are converted by the graphics 
>hardware each second. My original remarks on the cheesiness
>of HAM stems from someone comparing A1200 screenmodes to the Falcon030.

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???

>>>	Har, you aren't doing fast graphics in HAM you are doing stuff
>>>	on top of, or under HAM.

No, this is only true for games applications. In the other main application
of HAM, you do *animations*. And here the compact format of HAM really
makes for speed, and this is one reason why the Amiga shines in graphics.

>>it doesn't work that way.  You don't store your data to be shown in a
>>24-bit format and convert, you store it in the 8-bit HAM format.  Any
>>"processing" happens in real-time on the chip, and it doesn't slow
>>down the system to any degree.

Yes, correct.

>Chuckle. This is only true for the borderline case, where your data is
>the size of the complete screen.

?????????????  This is *A* *FEATURE* of the Amiga!!! We have a thing
called "screens". We don't *need* to cram each and every application
into a window on our GUI! And also video applications, where you can
ask nearly every TV station on earth (yes, also in Germany, though we
don't have a PAL toaster, ask BR, RTL, WDR,...), they *demand* having
full-screen graphics without window borders! And this is exactly what
the Amiga gives them, in terrific speed.

>>Wrong on both counts, fortunately.  The only thing HAM costs is the
>>cost of a six-bitplane display, the only thing HAM8 costs is the cost
>>of the 8-bit display.  And our beloved blitter will work just fine.
>
>It's just not of any use. 

You're wrong.

>Judging from your post you have a very naive
>view of what HAM is and how you access/change pixel values in a HAM
>screen. 

Oh my god. Concluding from the following paragraph, it's *you* who has
to go back to school:

>If you want to color a pixel in plain red at coordinates x/y you
>must know the color of the pixel at 0/y then you have to calculate all the
>pixel colors between 0-(x-1), in order to get the color you want to modify.

Wrong. You obviously forget one thing that's called "base color". In old
HAM, there were 16 of them, in HAM8 we have even 64. These base colors
are *freely* choosable. Now in a real-world scenario, if you have to deal
e.g. with lots of portraits, you will choose some of your base colors to
skin shades, others for the other prominent colors occuring in your
pictures. So, to color a certain pixel in old HAM6, you have up to *nineteen*
choices: one of the 16 base colors, or modify either red, green, or blue of
the preceding pixel. This demonstrates that in many cases you already
get a good approximation through one of your base colors (*you* have the
possibility to choose them appropriately), so if you use *only* them, you
already would get a rather nice picture. That's already RAP, in a not too
badly reduced way, and in HAM8 even better. But on top of this, if your
preceding pixel is already in some similar shade, you can get it *perfect*
by applying the real HAM mechanism, modifying only one of the color com-
ponents.

The only thing I admit is that for knowing which color your preceding
pixel has, you perhaps (if this pixel is not in a base color) have to
go back through that line, until you find a base colored pixel and
recompute all the changes. But this is typically *not* the first pixel
in the line!

>Assume you want to 'blit' a little shape from HAM to HAM. 

Yes, blitting in HAM is not always recommendable. But as already said,
there are numerous other applications that can use HAM favorably and
do not need the Blitter at all.

>In laymans terms, it is comparable to editing a plain ASCII file (RAP-edit)
>and lossily editing a compressed ASCII file (HAM-edit). What would you
>rather do ?

HAM painting programs (and *only* they) have to deal with this. And there
are some of them that do it astonishingly nicely.

>This IS a speed penalty. Compare to that the beauty of plotting a 
>pixel in "Falcon TrueColor" mode;

But this *only* is true for painting a picture by hand. This is the more
rare case for HAM applications. You more often have some ray-tracer or
other software that does it for you. And there the speed gain through
the reduced RAM usage outweighs the computational overhead for optimizing
your HAM display. And once this image generating program is done and has
stored away the image data, you don't have speed penalties anymore, you
only have advantages because of the lower amount of data.

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