📄 svgacc.txt
字号:
REFERENCE MANUAL
FOR SVGACC
THE SUPER VGA
GRAPHICS LIBRARY
FOR USE WITH
MICROSOFT
COMPATIBLE C/C++
COMPILERS
1993-2000 by Zephyr Software - Stephen L. Balkum and Daniel A.
Sill
All rights reserved. No part of this book shall be reproduced or
transmitted by any means, electronic, mechanical, photocopying,
recording or otherwise, without written permission from Zephyr
Software - Stephen L. Balkum and Daniel A. Sill.
Although every effort has been made to insure the accuracy of the
material in this book, Zephyr Software, Stephen L. Balkum and
Daniel A. Sill assume no responsibility for errors or omissions.
In addition no liability is assumed for damages resulting from
the use of the information contained herein.
Printed in the United States of America
Trademarks
Sound Blaster and Sound Blaster Pro are trademarks of Creative
Labs, Inc.
All others are trademarks of their respective owners.
ii
SOFTWARE LICENSE AGREEMENT
By using this software, you agree to the terms of this
agreement.
No warranties are expressed or implied. In no event
shall Zephyr Software, Stephen L. Balkum or Daniel A.
Sill be held liable for damages resulting from the use
or misuse of this product, including but not limited to
implied warranties of fitness for a particular purpose.
The shareware version may be freely distributed as long
as all files stay together and are not modified in any
way. No cost may be charged for the shareware version
beyond normal and reasonable copying and distribution
expenses.
No products developed with this software shall be sold
unless this software has been registered with Zephyr
Software, Stephen L. Balkum or Daniel A. Sill.
At no time for any reason shall this software be
reverse engineered, decompiled or disassembled.
This software may not be rented or leased.
This software may be used only on one terminal or one
computer at any one given moment in time. This
software may not be installed on a network of any type.
Contact Zephyr Software, Stephen L. Balkum or Daniel A.
Sill for networking options.
United States Government Restricted Rights:
Use, duplication or disclosure of this software and
documentation by the U.S. Government is subject to the
restrictions as set forth in subparagraph (c)(1)(ii) of
the Rights in Technical Data and Computer Software
clause at DFARS 252.227-7013. Contractor/manufacturer
is Stephen L. Balkum and Daniel A. Sill, P.O. Box 407,
Pflugerville, Texas 78619-0407.
The ownership of this software may be transferred as
long as Zephyr Software, Stephen L. Balkum or Daniel A.
Sill is notified in writing of the transfer date and
new owner. The new owner must agree to this contract.
The transfer must include all registered updates and
previously registered versions. The original owner may
not retain any copies in any form of the registered
software or its documents.
iii
INTRODUCTION
We spent weeks searching the depths of the internet ftp sites for
a library that would allow the programmer full access to the
abilities of Super VGA. We wanted the colors VGA could provide
and better resolution than EGA could provide. Professionally
developed libraries with this ability were definitely out of our
price range. After our searches continuously returned nothing,
we decided to fill the apparent void in the shareware market.
Our searches did give two useful packages: John Bridges' VGAKIT
and Finn Thoegersen's VGADOC. We began with these two works and
developed a graphics library intended to allow the programmer
access to the huge world of high resolution programming.
On the surface the task appeared quite simple. However, it
quickly became obvious that the routines in this library would be
required to affect extremely large amounts of data. Operations
must be quick to be successful. Therefore, every effort was made
to create the fastest code possible - even at the expense of
size. For this reason we opted to write code with the 32 bit
instructions of the 80386 and better processors. It is our
opinion that anyone with a hi-res card in a lesser machine may
have some priorities out of order. All routines are written in
assembly and use absolutely no floating point values. Anytime a
real number was required, fixed point notation was used. In
addition we attempted to write the routines such that any
reasonable argument passed can be interpreted intelligently by
the library.
With the numerous Super VGA cards available and no well
established standard we chose John Bridges' identification and
bank switching routines as a beginning. These two routines have
undergone some modification, but not enough to justify
copyrighting this portion of the library's code by Zephyr
Software. We have no intentions of releasing our changes to
these routines into the public domain. From that point onward
all code is original. In some instances common algorithms were
researched and original code written according to that algorithm.
This Super VGA library gives the programmer transparent access to
twenty different Super VGA cards. These cards include Acumos,
Ahead, ATI Technologies, Avance, Chips and Technologies, Cirrus
Logic, Everex, Genoa, MXIC, NCR, Oak Technologies,
Paradise/Western Digital, Primus, Realtek, Trident, Tseng Labs,
Video 7 and the VESA standard. Please see the WHICHVGA function
for the specific chipsets. The programmer only needs to verify
that the end user's card has been identified, but not which card
was recognized. After proper identification, all functions react
in exactly the same fashion. The library contains functions to
draw all of the major primitives. In addition there are
functions that modify the screen palette, write text on the
screen with a choice of fonts and modify the reaction of the
primitives. Identification routines include not only the video
2
card, but also the amount of video memory, type of processor and
installed pointing devices. Advanced functions provide full
mouse support (when used with a Microsoft compatible driver) and
joystick support. Finally, support for two dimensional and three
dimensional coordinate systems is provided including rotation,
translation, scaling and projection.
3
SUGGESTED METHODS FOR USING THIS LIBRARY
VERIFICATION OF A COMPUTER'S HARDWARE
It is strongly recommended that any program written with this
library first verifies that the computer is a 80386 or better by
calling the WHICHCPU function. Many of the library's functions
use 386 exclusive code which may cause a computer with a lesser
processor to crash. In addition WHICHMOUSE must be called before
calling any of the mouse functions. Lastly, it is recommended
that WHICHJOYSTICK be called before a program uses the joystick
routines.
It is required that a program call WHICHVGA prior to any function
that communicates with the video card. If WHICHVGA returns a
zero for unknown card type, the program should not call any
graphics function. Without proper identification of the video
card any graphics function will likely cause a system failure.
It is recommended, although not necessary, that a program call
WHICHMEM prior to calling any RES function. Although the video
card was properly identified, it may not have sufficient onboard
memory to support the desired resolution. As a second check the
RES functions will do nothing if the video card has not been
identified or if the video card does not support the specified
resolution for memory or hardware reasons.
THE 256 COLOR PALETTE
The 256 color palette of the Super VGA cards is a six bit
palette. Each of the 256 colors of the palette are described by
three values representing the intensity of the colors red, blue
and green. These values can range from 0 to 63. Anytime a value
outside of this range is used, the video card simply ignores the
upper two bits. Therefore, 64 is the same as 0. This should be
taken into consideration when manipulating the palette or when
importing a palette from an external source such as a PCX image.
USE OF 2-D AND 3-D FUNCTIONS
In the interest of speed, the 2-D and 3-D functions were written
to best work on multiple points at once. We refer to these
functions as object-oriented. This means that the points
defining an object (a box, a house, etc.) should be contained
within one array or part of an array and calls to the functions
should act on all of the points in the array. Calls to functions
have a high speed overhead, therefore, placing more than one
object in the same array and passing the entire array to the
functions can be beneficial. However, these functions will work
on a single point as well.
A consequence of our object-oriented 2-D and 3-D functions is the
use of the scaling functions. When scaling objects, we recommend
the object be defined about the origin. D2SCALE and D3SCALE both
work with respect to the origin. This eliminates a significant
4
number of translations that would otherwise be required by having
a definable scale origin. For example, to draw two boxes, one
scaled by one-half of the other, each rotated by 45 degrees at
the center of the screen, the recommended procedure is as
follows:
define an array BOX containing the 2-D points: (100, 100), (-
100, 100), (-100, -100), (100, -100), (note: the box is
centered about the origin.)
rotate BOX by 45 degrees about (0, 0) and place the output in
RBOX,
scale RBOX by 50% (scaling factor would be 128, or 80 hex) and
place output in SRBOX,
translate RBOX to the center of the screen - a translation of
320, 240 in 640x480 resolution - and place output in TRBOX,
translate SRBOX to the center of the screen - same translation
as for RBOX - and place output in TSRBOX,
draw TRBOX and TSRBOX on the screen.
Notice that by defining the box centered about the origin the
translation values were extremely intuitive. Also notice that if
we had scaled the second box after the translation, it would have
been draw in the upper left quadrant of the screen instead of the
center.
In mathematics and many sciences it is customary that in a 2-D
coordinate system the Y axis increases upward and the X axis
increases to the right. The computer industry has decided the Y
axis should increase downward. The 2-D functions are not
affected by the choice in coordinate systems. However, it is
important to remember that a positive rotation in D2ROTATE
rotates from the positive X axis to the positive Y axis.
Therefore, when using mathematical conventions, a positive
rotation moves counter-clockwise. On the computer screen a
positive rotation moves clockwise.
The 3-D coordinate system follows mathematical conventions by
using a right-handed coordinate system. The easiest way to
visualize this coordinate system is by using your right hand.
Place your index finger and thumb at a right angle to one another
as if to form an imaginary pistol. Now place your second finger
at a right angle to your index finger. It should be at a right
angle to your thumb as well. This represents the three axes.
The index finger is the X axis, the second finger is the Y axis
and the thumb is the Z axis. The easiest way to remember
rotation directions in this system is cyclically. A positive
rotation about the X axis rotates the Y axis into the Z axis. A
positive rotation about the Y axis rotates the Z axis into the X
axis. A positive rotation about the Z axis rotates the X axis
into the Y axis.
After doing all necessary 3-D transformations, projection onto
the 2-D computer screen is required. Although the computer
screen's coordinate system does not follow mathematical
5
conventions, the D3PROJECT function automatically takes care of
all conversions. The programmer only needs to draw the resulting
object on the screen with FILLCONVEXPOLY, FILLPOLY or a series of
DRWLINEs.
THE CONCEPT OF SPRITE GRAPHICS
The key to sprite graphics is the assumption that only a small
percentage of the pixels in a graphics block are used by the
animation and the remaining pixels should be treated as
transparent, revealing the background behind the sprite. The
sprite routines in this library only act on non-transparent
colors, thus, saving time by ignoring a large number of pixels.
When retrieving the background for a sprite, prior knowledge of
the sprite itself permits obtaining background only where it is
necessary.
The following steps outline an example of the recommended
procedure for using the sprite functions:
1. draw the sprite on the screen - a white stick figure on a
black background, for example
2. use BLKGET to place the sprite in an array STICK
3. use SPRITEGAP to simultaneously retrieve the background into
BACKSTICK and place STICK on the screen, declaring black as
the transparent color
4. use SPRITEPUT to replace the background BACKSTICK in the
same location as step 3
5. repeat steps 3 and 4 as many times and in as many locations
as desired
GLOBAL VARIABLES
Access to several global variables provided to the programmer.
The most important two variables are MAXX and MAXY. These two
values give the current resolution and are set by the RES###
functions. They should not be changed directly at any time by
the programmer. Doing so may cause erratic results from many of
the graphics functions in this library. These variables
initially contain 0.
Four other variables, VIEWX1, VIEWY1, VIEWX2, VIEWY2, can be
accessed by the programmer. They define the current viewport
used for clipping purposes. These values, also, should not be
changed directly by the programmer. The SETVIEW function should
be used to change these values as it performs important error
checking. The viewport is defined as the whole screen by the
RES### functions. If drawing on more or less than the entire
screen is desired, call SETVIEW as necessary.
EXTENDED MEMORY SUPPORT
With the higher screen resolutions, more memory may be needed for
data storage. For this reason extended memory support is
6
provided. Accessing extended memory requires the computer to
switch into protected mode. The process of switching into
protected mode and returning is handled by the extended memory
manager, usually HIMEM.SYS. The switch is relatively slow.
Therefore, it should be used as fast storage access since it is
much faster than disk access.
Extended memory access is also limited by the number of available
handles. The limit is controlled by a switch on the extended
memory manager's command line and normally defaults to 32. Also,
it is imperative that all allocated extended memory blocks be
freed before the program terminates. Unfreed memory blocks will
be unavailable until the computer is rebooted.
CONVENTIONS USED IN THIS MANUAL
All parameters, other than pointers, passed to and from functions
and procedures in this graphics library are short (two byte)
integers A byte variable type is assumed to be an unsigned
character. No floating point values are used. By not using real
numbers round-off error can be a concern. Under most
circumstances this error will not be a problem and will not be
noticed. The use of large numbers in rotations is recommended.
No functions in this library allocate memory for the programmer,
except, of course, XMSALLOCATE. It is the programmer's
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -