
  AGA.svdriver

  © 1994 by Andreas R. Kleinert.

  FREEWARE. All rights reserved.

  Version      : 1.4
  Release Date : 18.04.1994
  OS Version   : OS V3.00+ (V39)


  Description
  ~~~~~~~~~~~
  AGA.svdriver is an external Library-Module for the superview.library V3+.

  It supplies functions for V2+ SVObjects to allow object-orientated
  displaying of graphics on AGA Screens.

  The internal graphics interchange format is the same as supported by
  superview.library V3+ in connection with V2+ SVObjects, which can be
  used by external custom programs.

  AGA.svdriver is identical to ECS.svdriver, except to the "chunky pixel"
  support and other features, which have been realized with V39 functions
  here.

  This Driver supports the following :

  Dimensions	    Depth	  Type

  [AGA] 	    [AGA]	  BITPLANE
  [AGA] 	    8		  ONEPLANE    (Chunky Pixel)

  ONEPLANE 24 Bit Graphics (RGB 3x8-ONEPLANE) will be dithered to 8 Bit.

  Autoscrolling of Screens larger than the actual display is supported :
  Just move the mouse to the boundings !


  Author
  ~~~~~~
  Andreas R. Kleinert
  Grube Hohe Grethe 23
  D-57074 Siegen
  Germany


  Known Bugs
  ~~~~~~~~~~
  This bug only concerns to File-Formats in which pictures with only
  2 Colors may be represented as Chunky-Pixel data, e.g. :

   - 2-Color GIF87a/89a
   - 2-Color IMG
   - 2-Color BMP
   - 2-Color FBM

  This bug does not occur always : Whether you get it or not depends on
  the actual width of the image in the file.
  For example a 354x410x1 graphics from a BMP File will as well cause
  problems as a 694x136x1 FBM graphics file.

  What do these have in common ?

   - they are written to the RastPort via WritePixelLine8(), using
     a TmpRas-Structure with attached BitMap
   - they will both be displayed on a Screen, which actually has a larger
     width than the display itself (320 <-> 354 and 640 <-> 694), so
     that the Autoscroll-feature has to be used
   - both width values do not exactly end on byte-, word- or longword-
     boundaries

  Due to the fact, that all other graphics, with the same width and
  height, but other color-depth and/or bitplane organization (no
  WritePixelLine8() needed) are displayed correctly, I believe
  that this is the result of a bug in the OS V39, maybe also V37.
  Perhaps WritePixelLine8() is not fully free of bugs yet.

  Try using other programs with some "critical" graphics and I guess,
  that you will get the same results like with this SVDriver :

   - either the system will slow down very much (silent crash)
   - or after closing the display and freeing all memory : problems
     with the memory list will be reported by exec (Recoverable or
     DeadEnd Alert) when using "avail flush"


  History
  ~~~~~~~
  V1.4 (18.04.1994) :

   - improved internal "regular case" BitMap-to-BitMap routine
   - added code for dithering 24 Bit RGB-Oneplane pictures
     (is quite slow, but results in good pictures)


  V1.3 (25.03.1994) :

   - slightly improved internal BitMap-to-BitMap routine
   - removed bug-fix from V1.2, now using BMF_DISPLAYABLE flag, no matter
     if this will help or not


  V1.2 (19.03.1994) :

   - tried to fix bug with strange-sized (temporary) bitmaps like 694x136 :
     now uses size = (((x + 15) >> 4) << 4) for determinating the
     desired width.
     This is not completely fixed yet (seems to be an OS bug ...)


  V1.1 (09.03.1994) :

   - first version


  Copyrights
  ~~~~~~~~~~
  Some of the mentioned names or products above may be copyrighted by
  companies or trademarks of companies.


