home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
World of Shareware - Software Farm 2
/
wosw_2.zip
/
wosw_2
/
QBAS
/
VGX3.ZIP
/
VGXSPECS.DOC
< prev
next >
Wrap
Text File
|
1993-01-06
|
7KB
|
156 lines
VGX FILE FORMAT SPECIFICATION
Version 3.0
January, 1993
Dwain Goforth
Milestone Software
1260 Sunset Ave.
Arcata, CA 95521
The VGX file format uses a run-length encoding scheme for each of the four
video banks (or planes.) Like BLOAD, it uses 64k EGA banks; like PCX, it
uses run-length encoding. Each bank is one color attribute (red, blue,
green, intensity). Compressing banks is more efficient than scan lines -
VGX changes banks only 4 times for each file while PCX changes 1920 times
for a VGA 640x480 16-color image (four times each scan line.)
Using VGXLoad will add approximately 8k to your finished EXE program. Using
VGXSave will add approximately 6k of compiled code to your EXE program.
In addition to this compiled code, the routines will allocate additional
memory each time they are called.
While running, VGXSave will allocate 78k of RAM, while VGXLoad will need 56k
of RAM. Please note that this used RAM is released after each call (except
for the VGXGRAB.COM TSR's which allocate RAM permanently - until you re-boot
your computer.)
Most critical DOS errors are "passed through"; that is, if an error occurs
(filename, disk or memory), the VGX routines will pass control back to your
program (the call may fail, but your program will not crash, though your
palette may be all black.) However, you do have to have sufficient RAM
available. Remember that speed was the guiding criterion when designing
VGX. If error catching is essential you will need to use ON ERROR in your
program.
VGX will work with any IBM-compatible microcomputer with a VGA display
adapter. DOS 2.1 and above are required. Versions of Microsoft BASIC
supported are PDS BASIC 7.x.
The VGX routines are "word-aligned"; that is they are optimized for the 286
CPU. 8088 CPU machines (PC's and XT's) will work just as fast, and 386
CPU's will work to nearly as fast as possible.
VGXSave and VGXLoad were written in MASM assembly language and BASIC itself.
FILE FORMAT:
The first 48 bytes of a VGX file contain the palette information. Each of
the 16 colors has a byte for red, blue and green, respectively. Thus byte
#1 is the red value for color 0, byte #6 is the green value for color 1,
etc...
Following the 48-byte palette header is the compressed bank data. Three
flags (words or 2 bytes) are used to indicate runs or bank changes. These
are:
893E - run of zeros follows
883E - run of ones follows
0F27 - end of bank
The data is stored as words (2 bytes.)
Those of you on the astute side may be wondering what happens if the data
contains these words. Well, one is subtracted from the data; that is, 893E
becomes 893D, 883E becomes 883D and 0F27 becomes 0F26. In these cases, one
of your pixels on the screen will have one bank (red, green, blue or
intensity) off when it should have been set. Since, on the average, there
is a .0000457 probability of this happening, you will only notice this in
the unlucky event of geometric patterns you are trying to save as a VGX file
that has many repetitions of these "reserved" numbers. Oh, well, but did I
tell you how fast it is?
The following is an example of the beginning of a VGX file which has a
custom palette and red circle in the center of the screen:
00 00 00 00 12 13 24 1C 1D 2D 21 1F 3F 2B 1F 3F \
38 20 3F 29 0A 3A 3A 0C 35 26 09 31 13 07 2C 05 > palette header
07 28 02 12 23 01 1B 1C 00 1F 0E 00 1B 06 06 32 /
0F 27 0F 27 89 3E F3 15 01 FF FF C0 89 3E 25 00
skip bank 1 . . . . . .
. . . . . .
skip bank 2 . . . . .
. . . . .
run of zeros next word . .
. . . .
5619 words of zeros (decimal of F315)
. . .
01FF as bit pattern (= 0000000111111111)
. .
FFC0 as bit pattern
.
run of zeros next word
37 words of zeros (dec. of 2500)
00 01 FE 00 00 3F C0 00 89 3E 24 00 00 3E 00 00 etc....
00 00 3E 00 89 3E 24 00 03 C0 00 00 00 00 01 E0
89 3E 24 00 1C 00 00 00 00 00 00 1C 89 3E 24 00...
------------------------
OPTIMIZING VGX FILES:
Because VGX files are stored in banks (red, green, blue and intensity) it is
to your advantage to design colors in your pictures that allow continuous
runs of banks.
Consider the relationship of the palette and the banks:
BANK0 BANK1 BANK2 BANK3
(RED) (GRN) (BLU) (INT)
----------------------------------------
COLOR 0
COLOR 1 X
COLOR 2 X
COLOR 3 X X
COLOR 4 X
COLOR 5 X X
COLOR 6 X X
COLOR 7 X X X
COLOR 8 X
COLOR 9 X X
COLOR 10 X X
COLOR 11 X X X
COLOR 12 X X
COLOR 13 X X X
COLOR 14 X X X
COLOR 15 X X X X
If you look at LASSEN1.VGX you see blue sky with lots of light blue words
("Milestone Software") and a brown mountain with a black "web" on it.
The sky is Color 1 and the words are Color 3 which means most of the sky
area is stored very efficiently for Bank 2 (blue) as a solid run of FFFF
bytes. Bank 1 (green) is broken by the words (and accounts for much of the
file size.) Had I used, say, Color 12 for the words, I would have not only
broken up the continuous Bank 2 (blue) in the sky, but I would also have
dragged Bank 4 (intensity) into the top of the picture and added greatly to
the file size. If I wanted the words to be bright red (normal for Color 12),
I would have *changed* Color 3 to be bright red (and still used the more
efficient bank choice.)
I pulled a similar trick with the "black" web on the mountain. The mountain
is actually Color 9 and the web is Color 11, so Bank 2 is an efficient solid
run of FFFF bytes. In fact, Bank 2 is solid FFFF for the whole picture!
Keeping these relationships in mind when making pictures for VGX can make
highly efficient and small VGX files :)