[comp.sys.apple] Response to Amiga HAM question

campbellb@viking.UUCP (Brian Campbell) (02/28/90)

Because of some interest on the apple news group,
what follows is a technical description of the Amiga HAM mode.
This info is based on discussions from my "Amigoid" friend, but I can not guarentee
it accurateness.

In the HAM mode the screen is represented by a six bit plane, i.e. six bits per pixel.
Two of these bits is used to represent one of four control values, and the other four
bits is used to represent a color value, whose meaning depends upon the control value.
One of the control values means that the color value represents one of 16 colors
from the color pallette (like on the IIGS).  The other three control values represent
Red, Green, and Blue modifications, and the pallette is ignored (at least directly).
That is, one of the color (R, G, or B) components is defined directly by the color
value, and the other two color components are borrowed from the previous pixel.
For example, with a red modification control value, the pixel assumes blue and green
values of the previous pixel, and assumes a red value defined in the pixel's four bit
color value.

What this means (if this explanation is correct) is that the Amiga can NOT arbitrarily
depict 4K colors anywhere on the screen, as implied by others comparing the IIGS and
the Amiga.  It can display any one of 4K colors WITH restrictions.  This mode is good
when adjacent pixels have similar color values.  But what if you want adjacent pixels
to differ in more than one color component.  You can't do it, unless one of the colors
is represented in the color pallette.  To change from one arbitrary color to another
arbitrary color, you need, in general, three pixels to do it.  The colors of the two
intervening transition pixels will not necessary blend in well with the first and
fourth pixels, particulary if the first and fourth pixels represent contrasting colors.
This may account for the "rainbow effect" reported by others on the net.
                                         

toddpw@tybalt.caltech.edu (Todd P. Whitesel) (03/03/90)

Your description is correct as I understand it from reading an Amiga hardware
reference. According to Amigoid friends (?) of mine (one is an ex-//e owner
and is really caustic towards Apple and everything they do) HAM is pretty much
annoying for anything besides ray traced pictures whose color gradations are
representable in HAM.

Give me Fill Mode any day. We need a killer demo that does some full frame rate
fill mode animation. (Memory hog, I know, but it'd look great)

Todd Whitesel
toddpw @ tybalt.caltech.edu

jason@madnix.UUCP (Jason Blochowiak) (03/10/90)

toddpw@tybalt.caltech.edu (Todd P. Whitesel) writes:
> [Deleted discussion of the Amiga's Hold-And-Modify graphics mode]
>Give me Fill Mode any day. We need a killer demo that does some full frame
>rate fill mode animation. (Memory hog, I know, but it'd look great)

	What about Jason Harper's "FillMaze" and "PolyGonia I" (as in 1)?
I got 60 frames/second with FillMaze (even with the auto-solve on), and I got
some decent frame rates with PolyGonia. They were basically demos of what
can be done with fill mode... Oh, the 60 frames/sec thing - I do have a TWgs,
but a friend who doesn't said that he got 50some frames/sec with a 2.6MHz gs.

	For those who haven't seen them, FillMaze is a 3D maze program, and
PolyGonia is a 3D object viewer (the objects are predefined, and they rotate
around - I believe you can control the rotation, but it's been a little
while since I've run the thing). I think they qualify as "killer demos" :)

>Todd Whitesel
>toddpw @ tybalt.caltech.edu


-- 
                      Jason Blochowiak - jason@madnix.UUCP
or, try:         astroatc!nicmad!madnix!jason@spool.cs.wisc.edu
       "Education, like neurosis, begins at home." - Milton R. Saperstein

toddpw@tybalt.caltech.edu (Todd P. Whitesel) (03/10/90)

jason@madnix.UUCP (Jason Blochowiak) writes:

[ stuff deleted ]

>	For those who haven't seen them, FillMaze is a 3D maze program, and
>PolyGonia is a 3D object viewer (the objects are predefined, and they rotate
>around - I believe you can control the rotation, but it's been a little
>while since I've run the thing). I think they qualify as "killer demos" :)

FillMaze, yes, but Polygonia NO. I got horrid frame rates with Polygonia on
a 2.6 Mhz GS. Maybe I have a freak motherboard or something; I thought that
Polygonia was slow because the 3D transformations were being done with the SANE
toolset (are they?) and the SANE toolset is notoriously slow.

The kind of fillmode demo I'd like to see would be one that runs a sequence
of animation, at 60 frames/sec on a stock GS w/ no accelerator. This of course
puts a limit on the complexity of the pictures so they would need to be custom
generated or if they were digitized Japanimation (my favorite example) they
would need to be cleaned up in a major way. This and the sheer hours of
digitizing that would be required explain why such a demo has not been done.

But it would look pretty darn good to have a few minutes of Lum or something
running on a ROM 03 motherboard or equivalent...

Todd Whitesel
toddpw @ tybalt.caltech.edu

jason@madnix.UUCP (Jason Blochowiak) (03/16/90)

	Well, you could just use a PaintWorks animation file - granted, it'd
be huge, but you can get some pretty good frame rates, even without using
fill mode - with fill mode, you could get better rates, of course. I don't
have the time, equipment, or inclination for that sort of thing, tho'.
-- 
                      Jason Blochowiak - jason@madnix.UUCP
or, try:         astroatc!nicmad!madnix!jason@spool.cs.wisc.edu
       "Education, like neurosis, begins at home." - Milton R. Saperstein