Re: [Adonthell-devel] Map implementation ...

[Kai Sterker]

On 5/21/07, Tyler Nielsen <address@hidden> wrote:

> Well, I am interested in helping out still.  I know I go through long
> periods of inactivity.  Either way, I'm happy to help you in your tiny demo
> goal.  If there are specific things you want done to finish the animation
> class, aside from the delay stuff you talked about already, then let me
> know.

If you could do that, that would be nice. I think that has really the
highest priority as far as the animation class is concerned.

Other than that there are the placeable_model and placeable_model_gfx
classes that implement sprites as far as I understand. Since that is
now part of the animation class, there seem to be some changes
required. I haven't looked at it in detail yet, so no idea what to do
with it.


> As far as the delay/animation e-mail.  I'm think that will work, but I have
> a small concern.  The timer stuff didn't seem that efficient when I looked
> at it (but I could be wrong, or it could be fixed).  I'm happy to go down
> the path of implementing this.

That is my concern a little bit as well. Can't really judge that. As
Ingo said it probably doesn't matter as rendering is the bottleneck
anyway.

There is some experience with that that stuff from v0.3: back then we
had implemented delay in character schedules by incrementing counters
and were calling update() on characters every game cycle. When Alex
ported v0.3 to his Zaurus handheld, he had to disable all character
schedules to get it running at a decent speed. That's when I
implemented the time event stuff to speed things up. It should be
noted however, that each update() call resulted in Python code to
execute, so the saving was quite big. In case of the animations, the
counter would sit on C++ side, so there are no costly calls involved.

The reason why I still would use the timer are:

* time events are available to use. I kind of like the idea of
utilising existing code. Have to make sure that it really fits the
purpose though.

* time events are synchronized to actual time, so it should be simple
to specify delays between frames in milliseconds. Although with
updates each game cycle, you could do the same as we know the cycle
length (see below).

* there is an advantage for "animations" with only one frame. Since
all graphics on the map are animations with the current code, that is
probably a significant amount. With the update() method, we try to
change them each game cycle even though it is useless. With the timer,
those animations will never be registered at the time_event_manager,
so they sit static and consume no CPU at all.


The things that concerns me a little are

* How to enable variable delays between different frames (should work,
but might force to remove, then register at time_event_manager again)

* In general the overhead of registering at the time_event_manager.
But I guess it could be limited with some clever code.


> I'm also not sure what the connection
> between the update/delay, and the draw to the screen will be.

I think the idea is that the two are completely disconnected. The
update/delay needs to set the current frame of the animation. That's
why the timer might make sense as you very rarely need to switch
between frames. Once every 0.5 or 0.25 seconds for your average
animation or something like that.

Drawing OTOH will happen every game cycle and will simply render what
happens to be the current frame. A game cycle is defined as 50ms by
default, giving us a constant 20 cycles per second (Guess the value
should be lower, in v0.3 it was set to 20ms, resulting in 50 cycles
per second, which sounds like a decent frame rate).

Anyway, the idea is to limit CPU use and make sure that stuff runs at
constant speed, no matter how fast the machine.


> FWIW... The main thing keeping me from getting involved (aside from time) is
> that I don't have an idea of the road map.  I'm a little concerned about
> going down a path, and then having it not do at all what is needed.  Both
> the audio and animation stuff I would put at the 70% done mark.  I wrote
> some common code (stuff that even if the entire interface needs to change is
> still usable).  I think getting a small demo working will help with this
> though.  Because once we have something then it can say we want to add
> feature X, Y, and Z.  And how they fit in should be a little clearer.

That's a good point. I know we had lots of discussion about the road
map in the early days, but not recently. So if going down that path
helps, lets do it then :-).


> The last thing is, my understanding is that we lost the media from Alex's
> demo.  Any thoughts?

No offense meant, Alex, but that isn't a big loss ;-). The whole thing
was small enough to fit into 640x480 and contained only a few objects.
A ground texture, some trees (the one from the Redwyne Inn yard scaled
to the new resolution), some platforms on pillars to jump on or walk
beneath  , a couple stairs to walk up and the naked guy as the
character model. I guess I could recreate something like this fairly
fast. Since loading/saving now produces XML files, hand creating the
few objects we would need for that demo isn't really a big deal.

Also, once stuff is wrapped to be accessible from python, it should be
fairly easy to get some prototypes going.

Kai