home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Graphics 16,000
/
graphics-16000.iso
/
msdos
/
utils
/
fbm2fl03.lha
/
fbm2fli.doc
next >
Wrap
Text File
|
1993-11-16
|
13KB
|
274 lines
===========================================================================
/* fbm2fli.doc */
Copyright (C) 1993 by Klaus Ehrenfried.
Permission to use, copy, modify, and distribute this software
is hereby granted, provided that the above copyright notice appears
in all copies and that the software is available to all free of charge.
The author disclaims all warranties with regard to this software,
including all implied warranties of merchant-ability and fitness.
The code is simply distributed as it is.
===========================================================================
About FBM2FLI:
The program `fbm2fli' allows to generate FLI-animations
from series of single images. `fbm2fli' uses the standard function from the
FBM library to read the image files. Thus it can handle various
file formats including GIF, SUN-raster and FBM. See the FBM
documentation about which other graphic formats are supported.
The program requires that the images are mapped and have 8 bit per pixel.
In contrast to the very popular "DTA" program for MS-DOS the
quantization of true-color images (e.g. POV output images)
has to be done separately. `fbm2fli' simply puts the prepared images
together. If true-color pictures should be processed, the
the quantization has to be done before `fbm2fli' is called.
For example the quantization can be done by the `fbquant' utility
included in the FBM package or by the `fboctree' program (see `fboctree.doc').
Together with the FBM package it should be possible
to deal with most of the graphic standards and file formats.
I have tested `fbm2fli' on a PC running Linux and on SUN workstations and
I used version 1.0 and 1.2 of the FBM package.
===========================================================================
Usage:
fbm2fli [options] list animation
Parameters:
"list" is the name of a file which contains line by line a list of names
of image files which are merged together in the given order.
"animation" is simply the name of the generated animation file.
Options overview:
-b* : border color = *
-D : double buffering
-m* : map-file name = *
-O : generate FLI with old format
-ox* : horizontal origin = *
-oy* : vertical origin = *
-rx* : horizontal resolution = *
-rx* : vertical resolution = *
-s* : animation speed = *
Options details:
-b* (border color):
In regions where no input data is available, because the input image
doesn't cover the hole display area of the animation,
the pixel value is set to the given value. By default zero is used.
See also the "-ox" option.
-D (double buffer):
By default the generated FLI chunks only hold the update information
with respect to the last frame. If the "-D" option is given, the FLI
chunks additionally provide the update information with respect
to the frame before the last. In both cases the FLI animations
work with standard players. The additional update information is useful
for players which use double buffer technique (see remark below).
If you have not such a player this option is useless.
-m* (map file):
The color table of the given image file is used for all images
in the animation. The original color table in the animated images is
ignored. The map file itself becomes not part of the animation.
Only its color table is used. This option is useful in many
circumstances. E.g: it is possible to change the colors in the
hole animation simply by manipulating the table of one file.
-O (old format)
An old format FLI with Magic Number 0xAF11 is generated. Instead of the
DELTA_CHUNKS (7) the old LC_CHUNKS (12) are used and COLOR_CHUNKS (11)
instead of COLOR_256_CHUNKS (4). Some older players cannot handle newer FLI
animations with the Magic Number 0xAF12. This option allows to generate
FLIs for this players. When the "-O" option is given the default
resolution is set to 320x200. Otherwise 640x480 is used.
Note: Often the new format FLIs are called `FLC'-files but I use the name
`FLI' for both the new and the old standard.
-ox* (horizontal position):
By this option the horizontal position of the left border of the
input images in the display area of the animation is controlled. The value
gives the number of pixels from the left border of the displayed area to
the left border of the image. By default the input images are centered
in the display area. If the width of an input image is less than the
chosen resolution, borders are inserted on both sides of the image
symmetrically. The border area is filled with the pixel value given
by the "-b" option. If the width of an input image has a higher value
than the chosen resolution, an equal amount of pixels is cut off from
both sides of the input image. Thus, when the size of the animated
images varies, the left border of the images is at different locations
in the display. If the "-ox" option is given, the automatic centering
is disabled and the left border of the input image is kept fixed at the
given horizontal position. This can be used to place small input images
at a certain position in the display, or to animate only a certain section
of larger input images.
-oy* (vertical position):
Same as "-ox" but for the vertical position. The value gives the number
of pixels between the upper border of the display area and the upper
border of the input image.
Note: With "-ox" and "-oy" also negative values are allowed. Then parts
of the input images are outside the display area.
-rx* (horizontal resolution):
With this option the horizontal resolution can be modified. The value can
range from 10 to 1280. If an odd value is given, 1 is added automatically.
I do not know if all players (especially the players which only handle
old format FLIs) can deal with all resolutions. In principle the VGA
resolution 320x200 should always work. For players which can play the
FLIs with Magic Number 0xAF12 at least 640x480 should work also. When
strange numbers are used nothing is guaranteed.
-ry* (vertical resolution)
Like "-rx*" but for the vertical direction. In contrast to "-rx*" here
also odd numbers are accepted. Maximum value is 1024.
-s* (speed):
In the header of the FLI file a default value for the animation speed
is stored (Actually not directly the speed but the delay time between
two frames is stored).
This default value is used by some players if no other speed
is set at playing time. The meaning of the value depends on the format
of the FLIs. For old format FLIs the value gives the number of video
ticks between two frames. If "-s*" is omitted a default of 5 is used.
For new format FLIs the delay between two frames is given in 1/1000
seconds rather than video ticks. In this case a default of 72/1000
seconds is used. This results in approximately 15 frames per seconds.
In both cases a higher value reduces the speed.
===========================================================================
Examples:
Pathological example to explain the use of "-ox", "-oy", "-rx" and "-ry":
-------------------------------------------------------------------------
We have a series of images with different resolutions. We want a 36x10
resolution for the FLI animation. We want that the images are not
automatically centered, but that the upper-left corner of the images is
located at the position (6,2) in display area. The origin (0,0) of the
coordinate system of the display area is located in the upper-left corner.
The name of the list file is "example.lst" and the name of the generated
FLI file is "example.fli". We type:
fbm2fli -rx36 -ry10 -ox6 -oy2 example.lst example.fli
The following figure shows the resulting location for an input image with
9x5 pixels:
0123456
|< - >|
------------------------------------ --0
| | 1
| --------- | --2
| | input | |
| | image | |
| | 9x5 | |
| --------- |
| |
| |
------------------------------------
( Display area 36x10 pixel )
More reasonable example to explain the use of "-ox", "-oy", "-rx" and "-ry":
---------------------------------------------------------------------------
We have a series of 768x512 images produced by someone else or by a
commercial software. We want to animate these images, but we want that
the top 20 lines of each image are cut off, because there occurs something
disturbing (advertisement or so).
Again the name of the list file is "example.lst" and the name of the
generated FLI file is "example.fli". We type:
fbm2fli -rx768 -ry492 -oy-20 example.lst example.fli
Note 1): 492 = 512 - 20.
Note 2): Also negative values are allowed with the options "-ox" and "-oy".
Of course, if a negative value is given the upper-left corner
of the images is outside the display area.
Example to explain the use of "-m":
-----------------------------------
We have a series of images and all have the same color table. But the
used colors are ugly and it is much work to change all color tables.
Then we generate a special image (using a color-table editor)
which has a better color table. We assume that the name of this file is
"nice_colors.gif".
Again the name of the list file is "example.lst" and the name of the
generated FLI file is "example.fli". We type:
fbm2fli -mnice_colors.gif example.lst example.fli
===========================================================================
Remarks about double buffering (PC players only):
[About the sense of the "-D" option]
One special feature of `fbm2fli' is that the program can generate
animations for players which use double buffering. The advantage of
players which use double buffering is that they allow a smooth
and undisturbed display even in cases where almost all pixels are
changing from one frame to the next. Most players write directly to
the visible part of the video memory. The FLI-file holds the update
information for the next frame. The player waits until the beginning
of the vertical blank period of the video signal (this is the time
in which the electron beam in the monitor moves from the bottom to
the top) and then it starts to update the video memory. If too much
pixels have to be updated or the access to the video memory it too
slow (ISA bus and higher resolution ...) one gets disturbances in the
display. The reason for this is that an image is shortly visible on
the screen which has a part at the top already updated to the next
frame but the remainder at the bottom still shows the information from the
previous frame. Only if the player writes faster to the video
memory than the video chip reads this memory one gets
an undisturbed animation. But this can only be archived by very fast
graphic boards (50 MHz local bus and low resolution) or by animations where
not more than a certain amount of new pixels has to be updated
between the frames.
Double buffering simply overcomes these restrictions by using a
second buffer and writing to an invisible part of the video memory.
When the update of one buffer is complete the player switches the
display to the ready buffer and starts to process the next frame in
the other -- now invisible -- buffer.
But in this case the player needs the update information with
respect to the frame which previously was located in the same
buffer. And this frame is not the last one, which was processed in
exactly the other buffer, but the frame before the last.
===========================================================================
Installation:
Necessary requirement for `fbm2fli' is the correct installation of
the FBM package from Michael Mauldin (mlm@nl.cs.cmu.edu).
Is is available via FTP as "nl.cs.cmu.edu:/usr/mlm/ftp/fbm.tar.Z".
Probably some changes in the makefile are required to indicate
where the FBM stuff is located on your machine and which compiler
is used. I have tested the code only with GCC 2.*.*. Because
I didn't use any dirty tricks it should also work with other
standard compilers.
===========================================================================
History:
25-April-93 Initial Release.
28-May-93 Corrected one bug in fppcolor.c. Now the -m option
should work correctly.
08-Oct-93 Added the file fpplc.c. Now also old format FLIs can
be generated.
Some other changes:
- New command line syntax
- More flexible way to choose resolution
- Internal compression slightly improved
-- Klaus Ehrenfried (klaus@spock.es.go.dlr.de)
===========================================================================