From: wallmann@backus.pu.informatik.th-darmstadt.de (Natuerlich!)
Newsgroups: comp.sys.amiga.advocacy
Subject: Re: **** A1200 Info **** (200+ lines)
Date: 12 Nov 92 20:58:33 GMT
Organization: MSD software vault #9 @THD

OK the previous Article was supposed to be my last one, but I'll make one 
exception here. It's just somehow much more fun to Followup on a
commodore.com post. Anyway, replys IF you care that I read them please
forward them to me by Email since I'll be unsubscribing today (Diploma-work..)
otherwise c.s.a.a have a ball!

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

I hope you didn't make your Dr. in Informatik or EE. Do you think
your graphics hardware grabs the bytes out of RAM and hands them 
to your monitor ? It converts the binary information into analog signals.
                     --------

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

Read the thread this reply was directed at. It's probably too much to ask
for, but there is a context to be considered. James McCoull said something
about using sprites with HAM, and I replied like above..

>>>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.
Again: the context was, that I said operating on HAM must be done with
the CPU, and in ways that are way more wasteful than the usual videomodes
(where you can also use a blitter). 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...

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

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.
People who run applications and program, they really DO like windows (if
they know them).

>>>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.
Well tell me how you blit lets say a pix rectangle at 20/20-100/100
to 120/120-200-200 in HAM (with useful results) ?
Amiga answer: Easy, I open another screen, that is not HAM, and do it 
there!

>>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*
Wow! *nineteen* in numbers 19. This is almost TrueColor!

>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-
                ^^^^^
               (chuckle)
>ponents.
Yeah, right. You can do even better, reduce the portrayable colors downto
16 (HAM6) and get RAPs. This is sooo cool!

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

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

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. I am somehow 
still not jubilant about this HAM stuff. Given a choice I'd rather take a
RAP screen.

>>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 just proves what I always said about HAM, nice for static and
semi-static pictures. Even Commodore employes can only imagine painting
programs to ever wish to change pixel values in a HAM screen.

Case closed.

	Nat!
(#1#)
Amiga lamers take note: looking at a pixel does NOT mean in this case
looking at the monitor and identifing it as "sorta-mellow-brownish-
with-a-blue-tint".
-- 
 -----   Email: wallmann@backus.pu.informatik.th-darmstadt.de  -----
               "Bang that bit that doesn't bang"   
Album of the month: "The plague that.." Infectious Grooves (an oldie)
Newsgroups: comp.sys.amiga.advocacy