[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Adonthell-devel] Animation question

From: Kai Sterker
Subject: Re: [Adonthell-devel] Animation question
Date: Thu, 28 Sep 2006 20:36:09 -0700

On 9/28/06, Tyler Nielsen <address@hidden> wrote:

In the class I wrote, the
movement is carried around with the animation.  In the road_to_0.4, it is
handled externally.  I can see advantages to both.  With it carried around
with the animation data, you can specify variable pixel movement per frame.
With it outside it is more abstracted, and more compatible with road_to_0.4
code.  Anyone have any opinions on this?  I'd rather make any fixes now than

Maybe Alex should comment on this, but I believe that road_to_0.4
allowed to keep the movement seperate from the animation. That seems
to make sense for 2 reasons:
- not all animations will actually move.
- the same animation could move with different velocity (one NPC might
walk faster than the other)

Also, for animations that are actually moving, you can specify the
movement per frame indirectly through the delay before switching to
the next frame.

Hope that makes sense ... ;-)

Also, in regards to actually doing the animation load/save.  I assume it
should use either diskwriter_xml.h or diskwrite_base.h, I'm just not sure

I guess you should use diskwriter_xml ... however, it's not meant to
be used directly. Instead you'd read or write stuff from base::flat
and then use base::diskio(XML_WRITER) to write or read an
XML-formatted file. That's the theory at least.
In truth, the xml writer needs still some debugging and the parser is
only halfway done.

If you want to go ahead anyway, you could use base::diskio(GZ_WRITER),
which means your data will have to come in binary format. Once
somebody fixes the xml stuff (I might have time on the weekend), you
can easily switch to the XML_WRITER, run to get your
binary animation data into xml format and you are done.

See test/ for an example of how all that I/O stuff is
supposed to work. Basically, you have one internal data format and
different ways to serialize it.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]