Provided by: libsvga1-dev_1.4.3-31_i386 bug


       vga_accel - calls the graphics accelerator


       #include <vga.h>

       int vga_accel(unsigned operation, ...);


       This  is  the major function of the new accelerator interface which was
       sketched in version 1.2.3 (Michael: Hmm, it must have been  later)  but
       was implemented much later.

       The  main  goal  is  to  define  functions  that can be used as part of
       certain kinds of  interesting  graphical  operations  (not  necessarily
       interesting  primitives  on  their  own).  Obvious useful primitives in
       their own  are  FillBox,  ScreenCopy,  DrawHLineList  (solid  polygon),

       An  interesting  purpose  is  the  fast  drawing of color bitmaps, both
       straight and transparent  (masked,  certain  color  not  written).  For
       masked  bitmaps ("sprites"), there is a number of possible methods, the
       availability of which depends on  the  chips.  Caching  in  non-visible
       video  memory  is  often useful. One way is to use a transparency color
       compare feature of a BITBLT chip, either transferring  the  image  from
       system  memory  or  cached in video memory.  If transparency compare is
       not available, it may be possible to first clear (zeroe)  the  mask  in
       the  destination  area,  and then use BITBLT raster-operation to OR the
       image into the destination (this requires the mask color to  be  0).  A
       higher level (library) interface should control this kind of operation.

       vga.h contains several macros which may be used for operation.  Most of
       them accept several optional arguments  which  you  may  specify  after
       them. The accel(6) svgalib demo shows basic usage of this function. The
       function returns -1 if the operation is not available and 0  if  it  is
       (or better: wasi and could be performed).

       Currently the following parameters for vga_accel() are defined:

       vga_accel(ACCEL_FILLBOX, int x, int y, int w, int h)
              Simple  solid  fill  of  a  box  at pixels x, y with width w and
              height h in the current foreground color

       vga_accel(ACCEL_SCREENCOPY, int x1, int y1, int x2, int y2, int w,  int
              Simple  screen-to-screen  blit.  It  copies a box of width w and
              height h pixels from position x1, y1 to position  x2,  y2.   You
              may   assume  that  the  copy  is  non  corrupting  in  case  of
              overlapping source and destination areas.

       vga_accel(ACCEL_SCREENCOPYMONO, int x1, int y1, int x2, int y2, int  w,
       int h)
              Monochrome screen-to-screen blit. It copies a box of width w and
              height h pixels from position x1, y1 to position x2, y2.

              However, each pixel will all bits set  to  0  is  drawn  in  the
              background  color, each pixel with all bits set to 1 is drawn in
              the foreground color.  To  allow  many  different  architectures
              supporting  this  routine,  behaviour  is  undefined  for  other
              values. Bitmap transparency might be supported as well.

              You   should   not   expect   ACCEL_SCREENCOPYBITMAP    handling
              overlapping screen areas gracefully.

       vga_accel(ACCEL_PUTIMAGE, int x, int y, int w, int h, void *p)
              Straight image transfer. It fills the given box with the data in
              memory area p.  The memory buffer must contain the pixels in the
              same  representation  as used in the vga memory, starting at the
              top left corner, from left to right, and  then,  line  by  line,
              from up to down, without any gaps and interline spaces.

       vga_accel(ACCEL_DRAWLINE, int x1, int y1, int x2, int y2))
              General  line  draw. Draws a line from x1, y1 to position x2, y2
              in the foreground color.  You should not expect the reverse line
              from  x2,  y2 to position x1, y1 to use the exact same pixels on
              the screen.  Several, esp. hardware, algorithms tend to yield to
              surprising results.

       vga_accel(ACCEL_SETFGCOLOR, int color)
              Sets foreground color. It is used by most other draw commands.

       vga_accel(ACCEL_SETBGCOLOR, int color)
              Set  background  color.  It is used by draw commands which might

       vga_accel(ACCEL_SETTRANSPARENCY, int mode, ...)
              Set transparency mode, see the table below  for  an  explanation

       vga_accel(ACCEL_SETRASTEROP, int mode)
              Set  raster-operation, see the table below for an explanation of

       vga_accel(ACCEL_PUTBITMAP, int x, int y, int w, int h, void *p)
              Color-expand bitmap. This works similar  to  ACCEL_PUTIMAGE  but
              the  bitmap *p is a one bit bitmap.  Each pixel related to a set
              bit in *p is drawn in the foreground color, the other pixels are
              drawn in the background color.

              Each byte at *p contains 8 pixels.  The lowest order bit of each
              byte is leftmost on the screen (contrary to the VGA  tradition),
              irrespective  of  the  bitmap  bit  order flag. Each scanline is
              aligned to a multiple of 32-bits.

              If  the  transparency  mode  is  enabled  (irrespective  of  the
              transparency  color),  then bits that are zero in the bitmap are
              not written (the background color is not used).

       vga_accel(ACCEL_SCREENCOPYBITMAP, int x1, int y1, int x2, int  y2,  int
       w, int h)
              Color-expand  from screen. This works similar to ACCEL_PUTBITMAP
              but the bitmap lies at position x1, y1 and the  destination  box
              at x2, y2.

              Alas,  the sizes of the pixels in both bitmap are different. The
              bitmap *p must have the format corresponding to  ACCEL_PUTBITMAP
              but  will  start  at  the screen memory location where the pixel
              (x1, y1) would be (probably in off screen memory).

              In  modes  where  pixel  will  not  start  at  byte   boundaries
              (typically  those with less then 256 colors), the pixel (x1, y1)
              must start at a byte boundary (for example in a  16  color  mode
              (4bpp rather than 8bpp for 256 colors) this means that x1 should
              be an even number).

              The easiest way to achieve this is probably to choose x1 == 0 in
              these situations.

              You    should   not   expect   ACCEL_SCREENCOPYBITMAP   handling
              overlapping screen areas gracefully.

       vga_accel(ACCEL_DRAWHLINELIST, int y, int n, int *x1, int *x2)
              Draw horizontal spans. Each of the *x1 and *x2 arrays contains n
              x-coordinate  pairs.  Starting with a horizontal line from *x1,y
              to *x2,y consecutive horizontal lines (with increasing y values)
              are  drawn  using the start and end points in *x1 and *x2.  This
              is usually a very quick operation and useful to  draw  arbitrary
              polygons  (when  the  accelerator cannot do an arbitrary polygon
              fill itself).

       vga_accel(ACCEL_POLYLINE, int flag, int n, unsigned short *coords)
              draws a contiguous line through the n points listed in  *coords.
              *coords  contains  n  pairs  of  shorts,  the  first  is  the  x
              coordinate, the second is the y coordinate.

              Normally flag should have the  value  ACCEL_START  |  ACCEL_END.
              However,  if the evaluation of the points is costly, you can mix
              calculations    and    drawings.     Your    first    call    to
              vga_accel(ACCEL_POLYLINE,  ...)  must have ACCEL_START set. This
              will  initialize  the  accelerator.  If  you  do   not   specify
              ACCEL_END,  you can (actually you have to) follow your call with
              another vga_accel(ACCEL_POLYLINE, ...)   call  which  will  give
              additional points to connect.

              It  is  important  that  no  other  operations  (even  no  color
              settings) take place between a call with ACCEL_START and the one
              with  the  corresponding ACCEL_END.  Because of this, it is also
              important that you  lock  the  console  with  vga_lockvc(3)  and
              vga_unlockvc(3),  s.t.  you  cannot  be interrupted by a console

              It is allowed not  to  set  ACCEL_END  for  your  last  call  to
              ...).Thiswillnotdrawthelastpixelofthelast    line    which    is
              important   for  some  raster  operations  when  drawing  closed
              polygons.  The accelerator will automatically deinitialize  when
              called with another operation in this situation.

              It  is  undefined what happens when you specify other values for
              flag and when your polyline contains only a  single  point.  The
              line segments must also not be of length zero.

              For   implementors:   In   conjunction  with  raster  operations
              (ROP_XOR, ROP_INV) it is important that endpoints of inner  line
              section  are  only  drawn  once. If you cannot achieve that, you
              must signal that this function cannot  be  used  in  conjunction
              with raster operations.  In this case it is valid to always draw
              all  points  of  the  line  segments  including  the   endpoints
              regardless of the existence of a ACCEL_END parameter.

       vga_accel(ACCEL_POLYHLINE,  int  flag,  int  y,  int  n, unsigned short
              This  function  combines  the  features  of  ACCEL_POLYLINE  and
              ACCEL_DRAWHLINELIST.   Starting  in  row  y horizontal lines are
              drawn from top to  bottom.  For  each  horizontal  scanline  the
              *coords   array  will  contain  a  number  m  followed  by  m  x
              coordinates in left to right order. Horizontal lines  are  drawn
              between  the  first  and  the second, the third and the fourth x
              coordinates, and so on. If the m coordinates are exhausted, y is
              increased,  a  new  number  m is read from the *coords array and
              operation continues.

              This procedure is done for n scan lines.

              In addition there is a flag parameter  which  works  similar  to
              ACCEL_POLYLINE.   Your  first  call  to ACCEL_DRAWHLINELIST must
              have the ACCEL_START bit set for proper  initialization.  The  y
              parameter is ignored when ACCEL_START is not given.

              On  contrary to ACCEL_POLYLINE it is required that the last call
              has the ACCEL_END bit set.

              The function is intended for  drawing  complex  filled  polygons
              using horizontal scanlines.  By issuing small and fast calls for
              few scanlines only  it  is  possible  to  intermix  drawing  and

              The   operation   of  ACCEL_POLYHLINE  is  undefined  if  the  x
              coordinates are not sorted from left to right or there are  zero
              length  segments  in  any  scan  line  or  if  n or one of the m
              counters are zero, or one of the m's is not even.

       vga_accel(ACCEL_POLYFILLMODE, onoff)
              Switches polygon fill mode on (onoff non-zero) or off.

              When in polygon fill  mode,  ACCEL_DRAWLINE  and  ACCEL_POLYLINE
              will  only  draw  a  single  point on each scanline of each line
              segment.   ACCEL_SCREENCOPYMONO  will  horizontally  scan   it's
              source  area  and  start drawing in the foreground color when it
              encounters a set pixel. When the next pixel is  encountered,  it
              will start using the background color and so on.

              This can be used for hardware filled polygons:

              1.     Enable polygon fill mode.

              2.     Fill  an offscreen rectangular area with a the color with
                     all bits zero (usually black).

              3.     Draw a (usually closed) polygon outline in this offscreen
                     area  in  the color with all bits set (usually white). To
                     get the proper bits set for the polygon  outline,  it  is
                     recommended  to use ROP_XOR s.t. outlines intersecting in
                     a single point are  handled  correctly.  To  ensure  that
                     polygon  corners  are  handled  right, both start and end
                     points must be drawn (in ROP_XOR mode). Thus it  is  best
                     to   use   ACCEL_DRAWLINE   instead   of  ACCEL_POLYLINE.
                     Finally, skip drawing all horizontal lines  (which  would
                     confuse ACCEL_SCREENCOPYMONO).

              4.     Set fore- and background colors, raster operation, bitmap
                     transparency to those you want for your polygon.

              5.     Use ACCEL_SCREENCOPYMONO to copy the offscreen pattern to
                     the screen.

              The  rasteroperations and transparency which are signalled to be
              supported for ACCEL_POLYFILLMODE by vga_ext_set(3) are  actually
              meant to apply to the last ACCEL_SCREENCOPYMONO call.

              Because   this  polygon  drawing  uses  more  screen  read/write
              operations it is probably slower than using  ACCEL_DRAWHLINELIST
              or  ACCEL_POLYHLINE  for drawing a polygon scanline by scanline.
              However, it is easier to use and it  will  work  mostly  without
              intervention  of  the  CPU which can do other calculations then.
              See BUGS below.

              It is unspecified if  the  left  or  right  end  points  of  the
              scanlines  are drawn, and most probably some cards (like Mach32)
              will omit them on one end, at least. Because of that you  should
              always  draw  the  boundary  line  in the fill color (or another
              color) after filling the polygon.

       vga_accel(ACCEL_SETMODE, mode)
              Set blit strategy.  There  are  two  choices  for  mode,  namely
              BLITS_SYNC  and  BLITS_IN_BACKGROUND.   The first ensures that a
              vga_accel() call only returns when the accelerator has  finished
              its  operation.  The  second  allows for an immediate return and
              thus allows parallel operation of the CPU and  the  accelerator.
              Consecutive  accelerator  operations will wait for each other to
              complete (and block if necessary). However, direct screen memory
              access  (also  when  done  implicitly by some call to an svgalib
              function) may find any intermediate state in vga memory or  even
              corrupt the running accelerator operation.

              Wait      for      accelerator     to     finish     when     in
              vga_accel(BLITS_IN_BACKGROUND) mode.

       vga_accel(ACCEL_SETOFFSET, int address)
              set a screen offset as  vga_setdisplaystart(3)  does.  The  same
              restrictions for this function as reported by vga_getmodeinfo(3)
              apply to address.

              Whenever the video screen offset is modified, the  accelerator's
              offset  will  follow.  However you can modify it later with this

       The      following      mode      values      are      defined      for
       vga_accel(ACCEL_SETTRANSPARENCY, int mode, ...)

              Whenever one of the vga_accel() operations would draw a pixel in
              color color, no operation is performed and the destination pixel
              is  left  unchanged.  In  fact  that  color  is  defined  to  be

              disables the previous functionality.

              in  the  bitmap   expanding   operations   ACCEL_PUTBITMAP   and
              ACCEL_SCREENCOPYBITMAP whenever a non set bit is encountered, to
              not perform any draw operation. The 0 bits do not  draw  in  the
              background color. Instead they are defined to be transparent.

              disables the previous functionality.

       The  following mode values are defined for vga_accel(ACCEL_SETRASTEROP,
       int mode)

              Straight  copy.  Pixels  drawn  by   vga_accel()   replace   the

       vga_accel(ACCEL_SETRASTEROP, ROP_OR)
              Logical  or.  Pixels  drawn by vga_accel() are logical (bitwise)
              ored to the destination.

       vga_accel(ACCEL_SETRASTEROP, ROP_AND)
              Logical and. Pixels drawn by vga_accel() are  logical  (bitwise)
              anded to the destination.

       vga_accel(ACCEL_SETRASTEROP, ROP_XOR)
              Logical  exclusive  or.  Pixels drawn by vga_accel() are logical
              (bitwise) exclusive ored to the destination  (bits  set  in  the
              drawn pixels flip those pits in the destination).

       vga_accel(ACCEL_SETRASTEROP, ROP_INV)
              Inversion. Pixels drawn by vga_accel() are inverted. Which color
              is  drawn  is  actually  ignored.  Any  pixel  which  would   be
              overwritten is simply inverted (bitwise) instead.

       IMPORTANT!      Please     note     that     a     0     returned    by
       vga_accel(ACCEL_SETTRANSPARENCY,     int      mode,      ...)       and
       vga_accel(ACCEL_SETRASTEROP,  int  mode)  simply  means  that  the  set
       function is available (and thus probably some of  above  features)  but
       only  partial  functionality  may be available.  The VGA_AVAIL_ROPMODES
       and VGA_AVAIL_TRANSMODES subfunctions of vga_ext_set(3)  allow  you  to
       check     for     valid     parameters.     The    VGA_AVAIL_ROP    and
       VGA_AVAIL_TRANSPARENCY  subfunctions  return  which  of  the  vga_accel
       operations are actually affected by these set functions.

       Instead  of calling vga_accel() for each operation to find out if it is
       supported, you can call:

       #include <vga.h>

       int vga_ext_set(VGA_EXT_AVAILABLE, VGA_AVAIL_ACCEL)

       When the logical bitwise and of  the  return  value  with  one  of  the
       following  predefined (one bit set only) integer constants is non zero,
       the   corresponding   operation   is   available:    ACCELFLAG_FILLBOX,

       In addition, calling

       #include <vga.h>



       int vga_ext_set(VGA_EXT_AVAILABLE, VGA_AVAIL_ROP)

       does  not  list  the  supported  values  for  raster   operations   and
       transparency   but  instead  returns  the  ACCELFLAG_  values  for  the
       accelerator  operations  which  respond  the  raster  operation   resp.
       transparency settings.

       The  availability  of the operations will usually depend on the current
       video mode selected.  You should not try  to  use  them  or  check  for
       availability  prior  to  selecting  the  mode  you  want  to  use  with


       I found the Mach32 buggy in that it  occasionally  omits  drawing  last
       pixels  of lines when in polygon fill modes (that means, a single point
       for the last scanline touched by a line).  Obviously this confuses  the
       polygon  fill  hardware.  However,  screen  corruption  will  always be
       restricted to a small area as ACCEL_SCREENCOPYMONO will work only on  a
       limited  area.  It is not clear if this is a driver error, but it seems
       to be a hardware bug, and I don't know a clutch to  avoid  it  yet.  In
       case  you  experience  problems  with  certain  applications,  try blit
       nopolyfillmode  in  the  configuration  file  or   the   SVGALIB_CONFIG
       environment variable.

       You must ensure that the given screen coordinates lie in screen memory.
       Actually you may not really be sure how offscreen  areas  are  handled,
       you  can  only  really  trust  that  coordinates  which are visible are
       supported. For example, the Mach32 restricts  the  allowable  x  and  y
       coordinates  to  the  range  -512  ..  1535. However, even on a 1MB VGA
       memory card, the offscreen point  (0,  1599)  would  identify  a  valid
       screen memory location (if you could use it).

       Where  supported,  the vga_accel(ACCEL_SETOFFSET, ...)  directive might
       help to ease things a bit in such situations.

       Svgalib's accelerator support is a mess. Right now, only the  Ark,  the
       Cirrus,  the  Chips&Technologies,  and  the  Mach32 svga drivers really
       support this function. The Mach32 still also  supports  the  old  style
       accelerator  functions  vga_bitblt(3), vga_blitwait(3), vga_fillblt(3),
       vga_hlinelistblt(3) and vga_imageblt(3) which were first  designed  for
       the  Cirrus  cards and thus the Mach32 has its problems emulating them.
       The gl_ functions use the accelerator to some extend. Currently the use
       both  the  new  and  the old style accelerator. You should avoid mixing
       calls of the new and the old style kinds.

       These functions are not well tested. You should expect weird  bugs.  In
       any  case,  the  accelerator is of not much use in many typical svgalib
       applications. Best if you are not using them.

       BEWARE!  You should not use the graphics accelerator together with  the
       background  feature  of  vga_runinbackground(3).   However, you can try
       using vga_lockvc(3) to lock the vc prior to using the accelerator.

       The Mach32 driver does this on it's own, and  even  keeps  the  console
       locked  while  background  accelerator functions are in progress. Other
       drivers might not be as graceful.


       svgalib(7),  vgagl(7),   libvga.config(5),   accel(6),   vga_bitblt(3),
       vga_blitwait(3),  vga_ext_set(3),  vga_fillblt(3),  vga_getmodeinfo(3),
       vga_hlinelistblt(3),      vga_imageblt(3),      vga_runinbackground(3),


       This  manual  page  was  edited by Michael Weller <eowmob@exp-math.uni->. The exact source of the referenced function as  well  as  of
       the original documentation is unknown.

       It is very likely that both are at least to some extent are due to Harm
       Hanemaayer <>.

       Occasionally this might be wrong. I hereby asked to be excused  by  the
       original author and will happily accept any additions or corrections to
       this first version of the svgalib manual.