AGA.svdriver

  © 1994 by Andreas R. Kleinert.

  FREEWARE. All rights reserved.

  Version      : 1.8
  Release Date : 11.06.1994


  Requirements
  ~~~~~~~~~~~~
  - OS V3.00+ (V39)+ and its libraries
  - 68020+
  - superviewsupport.library V1+


  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.8 (11.06.1994) :

   - now at least requires 68020 CPU
     (there are perhaps no AGA machines out there, which have none).
     This should speed up the 24 Bit "dithering" routines.
     Startup-Code is still compatible to 68000, so that an installation
     on 68000 systems will not cause a crash, if running V37/38.


  V1.7 (22.05.1994) :

   - fixed small bug in 24-Bit-Support :
     our single temporary bitplane line always had a PlaneDepth of 24,
     so that 16 planes were wasted useless :-(
     Now this memory is saved and also speed may increase.


  V1.6 (07.05.1994) :

   - use of SAS/C V6.51
   - use of new "superviewsupport.library" V1
     This saves some space again (here : ca. 400 Bytes).
   - version still reflected 1.4 instead 1.5. Now we're at 1.6 :-)


  V1.5 (30.04.1994) :

   - fixed small bug in memory delocation (when multiply called)


  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.