OpenEuphoria

2. Re: .FLI animation format maker thing... (make_fli.zip)

• Posted by Nick Metcalfe <metcalfn at ALPHALINK.COM.AU> Sep 10, 1999
• 378 views

Hey Mike,
Due to the compression method, adding frames to a FLI in any other order
than serially would be very difficult.  This is because each frame is
encoded as the difference between the previous and current image.

If only a small part of the screen changes for each frame, only the
parts of the screen actually affected by this change get encoded in the
file.

I cannot see how to reorder the frames as would be required to implement
image "stamp"ing without keeping and managing a list of uncompressed
images in memory.  This could limit the ultimate size of the animation
:(  This also applies when re-playing a FLI animation backwards, or even
jumping to a frame whats more, as I discovered.  FLI animations like
going one way only, from start to finish, when playing or recording.

Currently, the way it works is after opening the fli file with
  error = open_anim(filename, {xsize, ysize}, speed)
one then renders, loads or retrieves a complete image for each frame
either on the screen for 320x200x256 or in a virtual screen for other
resolutions using whatever method.  It is then compressed and added to
the end of the file with
  error = add_frame(address),
where address is the memory address of the linear image buffer in
memory. For example, if the image is drawn on a 320x200x256 mode #13
screen, one could grab it directly by making the address #A0000.  To get
other resolutions one needs to put the image in a virtual screen by
blitting it from the screen into the virtual screen or creating it
entirely within the virtual screen.
Closing the fli with
  error = close_anim()
cleans up the header, sets the file length and stuff.  The resulting
file is invalid until it is closed.

The library is open-ended, one is expected to prepare the frames of
course.  The benefit is that one can take as much time as one likes
generating each frame initially, and yet have a snappy animation.  For
instance I use it to make fractal zoom animations, one minute of
animation can take all night to generate.

A flame animation may or may not be difficult, I would not know.  What
precisely did you have in mind?  It sounds like you would like a
complete animation design interface, effects lists, drag and drop etc.
Object editing?  This could become complicated, and is far beyond the
capabilities of the fli-maker as it stands but by no means impossible.

Mike Hurley wrote:

> Nick (or anybody else that knows the format) -- Would it be possible
> to go about it differently in the way frames are added to the
> animation?  Maybe something like KidPix that allows you to use
> "stamps," but you can assign this stamp this image, and so on, or some
> automatic animation features...like fire, rain, snow, and the like.
> Also, the features could be boxed in x,y,x2,y2 coords, or a drag box
> like used in Paint Brush/Paint to define an area for
> copy/paste... Just an idea, I think the FLI format would be good for
> the RPG Lewis is making, and I don't know anything about FLI format
> stuff. Mike Hurley

 Nick Metcalfe <metcalfn at alphalink.com.au>
 http://www.alphalink.com.au/~metcalfn