🚀 go-pugleaf

Warning:  Long message ahead.  I posted this so that people who want to
know more about the ActionMedia II and its limitations can get a sense
of what it's all about.

In article <1992Oct28.032532.7470@nuscc.nus.sg> joel@iss.nus.sg (Joel Loo Peing Ling) writes:
>A friend of mine (who has no access to this newsgroup) is using
>the ActionMedia II board for displaying both motion video and
>images converted from tif format.

>He faces some problems when he tries to display his AVS files
>which were converted from tif images. Not only are many fine
>details of the original image missing (which he can bear),
>saturated color patches in the image tend to bleed (smudge?
>smear?) to surrounding areas. This is worst when there are
>saturated green or red patches. Furthermore, slanted lines in
>the original images become jagged after the conversion.

>We are wondering whether all these are due to the conversion
>program he is using or is it only natural for the ActionMedia II
>board to behave in this way (since it is a motion video board)?
>Has anybody on the net experienced similar problems with this
>board? Are there remedies? Are there any other PD conversion
>utils available (BMP->AVS, TIF->AVS, JPEG->AVS)?

What you are seeing is an artifact of _one_ of the storage/display
algorithms that the card uses.

I'll bet you anything that he's using '9' bit screens.  The problem
with that is just what you said:  the colors bleed.  The reason is that
the image is stored in 3 planes, the Y, V, and U planes.  The Y, being
more important (it's intensity), is stored on a 1:1 size with the screen
being viewed.  The color components (U and V) are stored in a 1:4 in EACH
direction (x and y), yielding a 1:16 ratio.  Intermediate pixels are
interpolated from the ones that are there.

If you have the book 'ActionMedia II DOS Libraries (AVSS) Software
Libraries Overview', this explanation is on page 4-21.  If you have the
PS/2 AM II Application Programmer's guide, it's on page 8-3.  There's
also discussions of how to minimize it.

My first reaction would be to say 'switch to 16 bit', but you're trying to
display video.  Since video can only play on these 9 bit screens, you have
to be on a 9 bit screen. (no, really?)  What you want to do is display
mostly in 16 bit, except for those times that you are playing video.  There
are 2 ways to do this, both involving using a different section of VRAM for
the 16-bit and 9-bit screens.

1) Have 2 copies of the image.  Load the 16 bit to the currently displayed
16-bit screen, and load the 9-bit image to the (non-displayed) 9-bit screen.
Display the 9-bit screen, show the video, and switch back.  This is how we
accomplished this when in MediaScript.

2) There is a more subtle way to do it that involves using C. (Network
Tech doesn't have it in MediaScript, or didn't when we used it, and that
is inexcusable).  What you do is load the 16-bit image, 'copy' it onto the
9-bit screen, show the 9-bit screen, play the video, and switch back.  The
beauty of this is that you only need one copy of the image, changing things
are easy, etc, etc...

The routine needed to do #2 is contained on page 5-99 of the 'ActionMedia
II DOS Libraries (AVSS) Software Library Reference'.  All you have to do
is add some GrWaitDone calls, and change the addresses of the bitmaps
accordingly.  my version of the procedure is about 40 lines.  I could
probably eliminate most (all?) of the waits I have, and get it down to
about half that.

Any more questions, feel free to E-mail.
--
  Lewis Tanzos -   ljt3@cs1.cc.lehigh.edu - LJT3@PL122.eecs.lehigh.edu 
    They say that man ate the forbidden fruit, but I see few people
     who understand that 'evil' and 'different' are not synonyms.