[Freeciv-Dev] Re: unit animation file format

["Baumans" <baumans@xxxxxxxxxxxxx>]

----- 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).
>