home *** CD-ROM | disk | FTP | other *** search
-
- 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.
-
-
-