home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Fresh Fish 5
/
FreshFish_July-August1994.bin
/
useful
/
dist
/
gfx
/
show
/
superview-lib
/
docs
/
svobject-docs
/
pcx.doc
< prev
next >
Wrap
Text File
|
1994-07-04
|
7KB
|
242 lines
PCX.svobject
© 1993-94 by Andreas R. Kleinert.
FREEWARE. All rights reserved.
Version : 2.13
Release Date : 05.06.1994
Requirements
~~~~~~~~~~~~
- OS V2.04+ (V37)+ and its libraries
- superviewsupport.library V3+
Description
~~~~~~~~~~~
PCX.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 PCX Files.
In detail these are :
Reading :
- PCX V2.5 upto 16 Colors (supports 4/8 color EGA/VGA palette)
- PCX V2.8a upto 16 Colors (supports 4/8 color EGA/VGA palette)
- PCX V2.8b upto 16 GreyScales
- PCX V3.00 upto 256 Colors
- PCX V2.5 - V3.00 with 24 Bit Data (see Remarks !)
Writing :
Depending on the Colordepth of the source - no matter, which WriteSubType
has been specified - the following is written :
Source Colors Version Type Destination Colors
2 .. 16 PCX V2.8a planar bitmap 16
32 .. 256 PCX V3.00 chunky pixel 256
It is always tried, to write the files RLE-encoded, but if encoding
is ineffective (output data nearly as large or even larger than input
data), the files will be written unencoded.
Remarks
~~~~~~~
- Why writing only 16/256 Color files ?
When loading 4 Color PCX files, some programs might expect a CGA style
color palette, while we only write EGA/VGA palettes. For 8 Color graphics
it is not clear how they should be handled.
Also, most programs do not support 32 .. 128 Color graphics, perhaps
because it is not clear, how the colormap has to be stored :
all at the end of the file or one hunk in the header and only the rest
at the end of the file ?
So why should PCX.svobject support things, which are not defined as
clear as they should be ?
- Then, why reading 4/8 Color files nevertheless ?
Because PCX.svobject wrote them - this was my fault - before I fixed
this bug. So it still reads them, but no longer writes them.
- What about PCC-Brush-Files ?
These should also be supported, because they're just a variation
of PCX-Files - usually only the extension is changed - but it seems
to me, that some of them are not correctly written, so that reading
may sometimes result in garbage.
- What about 24 Bit-Files :
Reading of RLE-encoded files works. It has been tested.
Reading of uncompressed files should now works, due to the bug-fix
in V2.11, although it has not been tested yet.
Send me your Public Domain 24 Bit Pictures, if they do not work
with PCX.svobject yet !
Author
~~~~~~
Andreas R. Kleinert
Grube Hohe Grethe 23
D-57074 Siegen
Germany
History
~~~~~~~
V2.13 (05.06.1994) :
- SVObject flags now reflect, that GfxBuffers can be written
V2.12 (27.05.1994) :
- 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+.
- if RLE-encoding is ineffective (output data nearly as large or even
larger than input data), the files will be written unencoded
now
V2.11 (22.05.1994) :
- added code for reading of RLE-encoded 24 Bit Files
(I tested it : it works)
- (hopefully) fixed bug in code for reading uncompressed 24 Bit Files
(it forgot to adjust the code to the way, how 24 Bit Data is stored
in the PCX FileFormat)
V2.10 (07.05.1994) :
- use of SAS/C V6.51
- use of new "superviewsupport.library" V1
This saves some space again (here : ca. 1600 Bytes).
V2.9 (01.05.1994) :
- slightly changed writing and RLE encoding routines
- added note about PCC files to documentation
V2.8 (23.04.1994) :
- created new hierarchy for decoding routines : they are now much more
flexible and error-resistant. Future expansions will be easier to make.
- temporary buffer for rawdata is now delocated immediately after use
- simplified ColorMap reading/handling (and GreyScale generation)
- added support for 24 Bit graphics. Not yet tested.
- Fixed FileInfoRequest() :
- PCX V2.8b was reported to be "V2.5 without Palette". Fixed.
- "ColorPlanes" was reported to be "Colordepth". Fixed.
Now there are four different values for all : pixelbits, pixelbits-
sized planes, colordepth and colornum.
So the user may reconstruct the original file structure in mind.
V2.7 (18.04.1994) :
- changed internal creation/handling of ColorMaps :
now PCX 2.8b with Black&White or GreyScaled BitMap-Data is
_really_ supported.
Side effect : simplified handling of different PixelBits/Plane
combinations
V2.6 (02.04.1994) :
- improved speed of RLE decoding routines
V2.5 (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.4 (25.03.1994) :
- slightly improved internal BitMap-to-BitMap routine
V2.3 (18.03.1994) :
- removed some dead code (not compiled nor linked ?!)
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) :
- now with SVDriver-Support. Not yet necessarily needed.
- improved internal "Chunky Pixel to BitMap" (8 Bit) Routine
- writing routine(s) :
- added code for writing 256 Color graphics (chunky pixel)
- 2, 4, 8, 32, 64 or 128 Colors are expanded to either
16 or 256 Colors before writing
- 16 Colors now written as V2.8a, also fixed some small bugs
- increased speed for writing 16 Colors
- fixed bug in setting map for 16 Colors
(same as in reading routine, which was fixed in V1.2)
- fixed small bug in memory management routines
- internal routines : AUTOSCROLL now really works with big-sized Screens
- fixed several little bugs
V1.3 (24.01.1993) :
- fixed bug with setting ColorMap under V37/V38
V1.2 (02.01.1993) :
- fixed "wrong colors" bug
- improved speed
V1.1 (19.12.1993) :
- first version
Literature
~~~~~~~~~~
[1] "Supercharged Bitmapped Graphics", Steve Rimmer, Windcrest/McGraw-Hill,
© 1992 by Windcrest Books (registered Trademark of TAB Books).
ISBN 0-8306-3788-5
[2] "Amiga Magazin", Issue 2/1992, Markt & Technik Verlag AG
[3] "DOS Extra", Issue 4/1993, DMV-Verlag
Copyrights
~~~~~~~~~~
Some of the mentioned names or products above may be copyrighted by
companies or trademarks of companies.