From: wallmann@backus.pu.informatik.th-darmstadt.de (Natuerlich!)
Subject: Re: **** A1200 Info **** (200+ lines)
Date: Sat, 7 Nov 1992 17:41:03 GMT
Organization: MSD software vault #9 @THD

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.)
So when comparing screenmodes to establish some 'bogus' superiority of the 
AA chipset, using HAM colors is bullshit. 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.

In article <1da7aaINN3c4@uwm.edu> you write:
>In article <1992Nov4.234825.14968@news.th-darmstadt.de> wallmann@backus.pu.informatik.th-darmstadt.de (Natuerlich!) writes:
>higher resolutions, HAM8 has lots of possibilities.

>>	Har, you aren't doing fast graphics in HAM you are doing stuff
>>	on top of, or under HAM.
>
>HAM8 is just as fast as an 8-bit hires mode.  The processor isn't
>doing the work for this, you know, the graphics chips are.
Take at least a minor stab at comprehending, what I or the previous poster
(Hi James) are trying to say.

>>	can suppress the showing of the three intermediate pixels, you are
>>	still in need of recalculating all the 'real' 24-bit values into
>>	HAM values, which will cost you speed wise. There is no workaround on
>
>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.
Chuckle. This is only true for the borderline case, where your data is
the size of the complete screen.

>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. 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. 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.
(#1#) now you can modify your value and then you have to adjust the value
of pixel x+1 so that it remains near the same color. Since you can't change to
any color in HAM (not a RAP) you might not get the red you want but something
close. 
Assume you want to 'blit' a little shape from HAM to HAM. Can you just 
use a memory copy with the blitter? No because the color information of
the HAM pixels are only valid at this position. Hence you must, convert
the HAM pixels into color values, and convert them back into HAM pixels
at the destination.

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 ?

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

typedef struct
{
   int   pixels[240][ 320];
} truecolor;

truecolor	*the_screen;

plot_pix( x, y, col)   /* way non-optimal */
{
   the_screen->pixels[ y][ x] = col;	
}

As to the point, "it's clear that you haven't used an Amiga before".
Not TRUE!! I played on an Amiga with friends (KICK-OFF) for an estimated
48 hours total. (har)

Nat!

P.S. Obvious improv. like hash-tables left out.
-- 
 -----   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)