home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Fresh Fish 5
/
FreshFish_July-August1994.bin
/
useful
/
dist
/
gfx
/
show
/
superview-lib
/
docs
/
svobject-docs
/
svo.doc
< prev
next >
Wrap
Text File
|
1994-07-04
|
7KB
|
220 lines
SVO.svobject
© 1993-94 by Andreas R. Kleinert.
FREEWARE. All rights reserved.
Version : 2.8
Release Date : 01.07.1994
Requirements
~~~~~~~~~~~~
- OS V2.04+ (V37)+ and its libraries
- superviewsupport.library V3+
- xpkmaster.library V2+
Description
~~~~~~~~~~~
SVO.svobject is an external Library-Module for the superview.library V2+.
It contains SVDriver-Support for the superview.library V3+, and
needs any SVDriver with Bitplane-/ChunkyPixel-Support.
It supports reading and writing of SVO Files.
In detail these are :
Reading :
- SVO V1.0 ONEPLANE/BITPLANE (includes 24 Bit Files)
Writing :
- SVO V1.0 ONEPLANE/BITPLANE (includes 24 Bit Files)
ControlPad-Switches
~~~~~~~~~~~~~~~~~~~
ControlPad-Name : "ENV:superview-library/SVO.controlpad"
ControlPad-Commands : - PACKMETHOD=<xxxx>
; if this one is specified, it is tried to
; pack the resulting file with the specified
; XPK-Packer. If this fails, the file keeps
; unpacked.
File Format Information
~~~~~~~~~~~~~~~~~~~~~~~
Pictures in the "SVO Graphics File Format" consist of two Files :
The Header-File (<Picture>.svo) and the Data-File (<Picture>).
The Header-File contains information about the Raw-Data in the
Data-File. For loading and saving the Graphics it makes no difference,
which FileName - Header-File or Data-File - is given.
This is managed by the svobject.
Because recognition of the Types of packed Files is only possible
by reading the whole File into a buffer and then check it, we use
two different Files for both : Graphics Information and Graphics.
The Data-File CAN be packed, the Header-File MUST NOT be packed.
The SVO.object does NOT save packed data by default, but you may either
specify an appropriate Xpk-Packer in the ControlPad or just pack it
with a Xpk-Packer-Program after writing.
The Data saved into the <Picture> File is read from a SV_GfxBuffer
structure, which has either been supplied by the calling application
or has been created from a supplied Screen-Pointer.
This data may be of type BITPLANE (like in an IFF-ACBM : BitPlane
after BitPlane, but without padding) or ONEPLANE (8 Bit ChunkyPixel
or 24 Bit RGB-Data).
This allows efficient packing and unpacking with PowerPacker and all
other XPK-Packers.
Remember, that the original Data written by the SVO.object may not
necessarily be packed and therefore might need a lot of diskspace.
So better pack it immediately after it has been written.
Source-Code
~~~~~~~~~~~
The "SVO Graphics File Format" is an "Open File Format", which means,
that everyone is invented to use and support it and to make suggestions
to improve the File Format or the Algorithms to handle it.
To allow support of the File Format and to give an example, how to write
your own superview.library compatible "svobjects", this distribution
contains the full SourceCode of the "SVO.svobject".
Feel free to use it for your own, commercial or non-commercial, programs !
Author
~~~~~~
Andreas R. Kleinert
Grube Hohe Grethe 23
D-57074 Siegen
Germany
History
~~~~~~~
V2.8 (01.07.1994) :
- writing of SVO-Files did not work since V2.6
- now it may be specified in "ENV:superview-Library/SVO.controlpad",
whether written SVO-Files should be packed and which packer should
be used ("PACKMETHOD=xxxx")
- SVO-Files now are written in the way the data has been stored
in the GfxBuffer (either ONEPLANE or BITPLANE).
Screens are transferred to BITPLANE data.
Reading of such files was already possible, but not yet writing.
This will sometimes allow more efficient packing with XPK
(e.g. when ONEPLANE-8 data with only 16 Colors is used as input).
V2.7 (05.06.1994) :
- SVObject flags now reflect, that GfxBuffers can be written
V2.6 (27.05.1994) :
- 17.05.94 : modified Doc-File slightly
- now saving of GfxBuffers is possible : internal write routines have
been completely rewritten, so that supplied Screens are transferred
to GfxBuffers before saving. BitPlane AND OnePlane Buffers upto
8 Bit are supported : they are converted to each other by using the
appropriate functions of superviewsupport.library V3+.
V2.5 (07.05.1994) :
- use of SAS/C V6.51
- use of new "superviewsupport.library" V1
This saves some space again (here : ca. 500 Bytes).
- version still reflected 2.3 instead 2.4. Now we're at 2.5 :-)
V2.4 (27.03.1994) :
- removed internal SVDriver-Replacement, so that we now are really
dependent on external SVDrivers in libs:svdrivers.
This saves about 1600 Bytes diskspace and reduces redundancy.
- replaced SAS/C's sprintf()-routine with own, RawDoFmt()-based one.
This saves again about 1800 Bytes.
- now using Utility-Library for integer operations (activated
SAS/C's UTILLIB option) : this increases 68000-codesize a little
bit, but increases speed on 68020+ systems
(should also decrease codesize, but does not ...)
V2.3 (25.03.1994) :
- slightly improved internal BitMap-to-BitMap routine
V2.2 (17.03.1994) :
- fixed "large memory usage" bug in internal ECS-ChunkyPixel routine
- added several security checks (zero-pointers)
V2.1 (09.03.1994) :
- very first "version 2" SVObject with SVDriver-Support
- found bug in the SVO-FileFormat, when storing the 16-Bit and
32-Bit ModeIDs :
both are just defined as 16-Bit-UWORDs, so that the 32-Bit ModeID
is theoretically _scratch_ !
It does seem to work with SAS/C V6.5 nevertheless, but with this
version the following work-around is done :
The former "svo_Pad1" field becomes "svo_Version", which indicates
extensions to the old 822-Byte-Header.
With V1 a new 32-Byte-ModeID field is added, so that the old one
becomes obsolete for reading of newer files.
The OLD ViewMode32-Field is still written as before, but will only
be read when handling files with version < 1 (= (BYTE)0).
- internal routines : AUTOSCROLL now really works with big-sized Screens
- fixed small bug im memory management routines
V1.4 (24.01.1994) :
- little internal improvements
V1.3 (16.01.1994) :
- improved speed
V1.2 (04.01.1994) :
- changed to recognize (reject) possible enhanced, future SVO Files
(16-24 Bit)
V1.1 (19.12.1993) :
- first version
Credits
~~~~~~~
The "xpkmaster.library" V2+ is (C)opyright by its authors
(c/o Urban Dominik Müller).
The Library is freely distributable and is needed by SVO.spobject,
to be able to read XPK-packed Data.
Copyrights
~~~~~~~~~~
Some of the mentioned names or products above may be copyrighted by
companies or trademarks of companies.