[Freeciv-Dev] Re: unit animation file format

[Jason Short <jshort@xxxxxxxxxxxxxx>]

For now we will stick with PNG for animation and other images.  Although 
this certainly has some drawbacks in the long term, its short-term 
advantages override this.  Later we may switch to something like MNG or FLC.
For rendered animations, we would like to have the original rendering 
model as well.  This won't be distributed directly with Freeciv, but 
will be available for separate download by tileset authors.
jason short
(for the Freeciv maintainers)


Baumans wrote:
> ----- Original Message ----- 
> From: "Lukas Tönne" <lukas.toenne@xxxxxx>
> To: <freeciv-dev@xxxxxxxxxxx>
> Sent: Monday, August 11, 2003 9:36 AM
> Subject: [Freeciv-Dev] unit animation file format
>
>
>
> > I've got an important question (should i say problem ?) for the freeciv
> > developers now:
> >
> > What file format would be the best for the unit animations i'm working on
> ?
>
> > I think the easiest way to _implement_ such animated graphics would be one
> big
>
> > (png-) file with all the single images appended to each other in a line or
> > grid (as for example in the old "unit explosion" or the iso_nuke.png that
> is
>
> > already used in the SDL client). Anyway, this might not be the best
> solution,
>
> > because the resulting file would be extremely large in terms of width and
> > height (at least 1280x3200 using the specification i described below) as
> well
>
> > as in terms of file size (about 1MB per unit, 250KB when using indexed
> > colors). I don't know if the supported png filesize is restricted in any
> way,
>
> > but downloading would also get a big problem since we have about 50 unit
> > types by now (the filesize already refers to compressed files).
> We could consider using the MNG format (that has a delta-mode, where it only
> sends changes).
> It's based on png, but the problem is that it's not widely supported, even
> if there is a reference library.
>
>
> > The second point to discuss is the geometry of the actual animation
> images. i
>
> > suppose a singe image format of 80x80 pixels with the upper corner of the
> > units ground square in the middle and "tolerance" borders of 8 pixels,
> which
>
> > would prevent details from "slipping" out of the frame and allow nicer
> > animations. Have a look at the attached file, this should make it clear.
> > I think it's enough to have 16 images per animation and every animation
> > rendered in 8 directions.
> If we can flip the animations, then 5 directions could suffice for some
> animations (the starting and ending of a move might be separate from the
> actual movement, so that gotos could have smooth transitions).