[Anima-devel] Current Anima Objectives

[Talin <Ta...@AC...>]

OK, here's a summary of the major Anima issues. More details can be read
in the TODO file in the source tree.

I presume that Anima will be converted to a KDE 2.0 application
eventually. At the moment, KDE 2.0 is a little bit unstable and it's
sometimes hard to get it to compile. I imagine that it won't be too much
longer before it becomes usable. Frankly, there is a lot of stuff in KDE
2.0 that would make development quite a bit easier, like floating window
frames, better list views, etc.

There is a long-standing bug where the program segfaults on exit. This
seems to be a memory corruption error - the segfault occurs in the
destructor for the combo box in the color list window. I can make the
segfault go away by commenting out the bcopy statement which initializes
the undo buffer for the color palette window, but as far as I can tell,
this statement is valid, and the addresses it is using are also valid;
So I can only imagine that some erroneous pointer is also pointing to
that same location, but I haven't been able to track it down.

One decision that has not been made is how Anima is going to store
images on disk, that is what is Anima's native file format going to be?
I would prefer not to invent a new file format if possible. GIF would
really be nice, but can't be used because of patent issues. And
unfortunately, PNG doesn't support multiple images per file. There is a
sister format, MNG, but it has very little support, not even a library.

Note that I would like the loading and saving of files to be via a
plugin (I assume there's some sort of standard way of doing plugins in
KDE).

The sequence data (that is, the data that indicates which frames are to
be played in which order) will probably be saved as text comments within
the image file. I have come up with a pretty simple XML format for
representing this data. It's pretty clean, and can support alternative
structures for different projects.

Of course, the actual game is going to want to use a highly compressed,
optimized format for animations. (In fact, I am going to be developing a
file format for my own game, Strattica, which I'm going to work on after
Anima is complete.) This can be done in one of two ways: By writing an
Anima plugin, or by writing a command-line tool to do the conversion.
Anima's "default" file format should probably be designed to make
tool-writing easy, that is a file format which is easily parsed. That's
why I chose an XML-like format.

In Anima, there are two types of data being worked on: Image data and
sequence data. Image data is just a flat series of images - image #1,
image #2, etc. There will be a thumbnail window capable of displaying
the images side-by-side. One thing I've learned working with
professional game artists is that some artists like to "flip through"
images like a flip-book, while others prefer to see all images spread
out simultaneously. The thumbnail window is at the moment merely a blank
window with no content.

The sequence data is the list of which images are played in which order.
A single image can be re-used in many different action sequences, or
even used multiple times within the same sequence. The sequence window,
which I've been working on recently, will show a tree-like hierarchy of
animations and frames. A "cel" is the basic unit of an animation, which
represents a single "layer" of a still "frame". A "frame" is one single
moment in time in an animation, and can contain multiple "cels". Each
cel can be horizontally or vertically flipped, or offset from the
origin.

(Note to readers: The correct spelling for translucent layers of
animation is "cel" not "cell" because it comes from celuloid.)

I want to have the ability to re-arrange frames in a sequence using drag
& drop. This will require heavy overloading of the QListView class (or
perhaps we'll have to make our own tree view from scratch.)

Another Issue: Currently, when Anima starts up it opens 4 windows: The
image thumnail window, the drawing window, the sequence arrangement
window, and the color selector window. Unfortunately, KDE seems to have
relatively sparse support for multi-window apps (more precisely apps
with multiple heterogenous windows - it supports multi-document apps
just fine.) Unfortunately, I really can't think of a logical and
intuitive way to combine all of these functions into a single window.

There are lots of other issues which I haven't mentioned, but these are
some of the ones that have to be dealt with next.

-- 
Talin (Ta...@AC...)       "I am life's flame. Respect my name.
www.sylvantech.com/~talin    My fire is red, my heart is gold.
www.hackertourist.com/talin  Thy dreams can be...believe in me,
                             If you will let my wings unfold..."
                               -- Heather Alexander