Topic: idle animation

SirVer, once we have multithreading in place i expect it will be fairly easy to launch a dummy thread at startup that just prefetches all data. might not work on systems with low ram but should work miracles on more powerful systems

Top

Quote

It's true that the characteristics of 0A.D. are somewhat different, but they still have to deal with many small files that affect seeking. So it's even possible that we might get a larger speedup from using their techniques.

(I've worked with Jan for a short while on 0A.D., but we've never met in person. I wrote an e-mail to him, let's wait and see.)

Top

Quote

I had a quick look at the thesis. The proposed techniques are packings things up into zip archives in which files are ordered by access, so that they can be read sequentially. The compression reduces file size and the archive reduces seeks and stats(). The loss would be that the files are readily available and viewable without unpacking. We already have this implemented in a way via our ZipFile system; i think it is likely that zipping the tribes and worlds directory up would already improve performance. The loss is too big though.

The idea to order these zip archives by access is appealing, but without archives, this won't work.

I guess the thesis has not too much for us.

Top

Quote

Well, 0ad obviously also work on the individual files for development. The point is that the zipping up is done automatically and transparently, based on some profiling information (though it's not clear how much the profiling actually helps). So you have the benefits of the zip file speedups without any of the development-related drawbacks.

Of course, if the artists find MNG easy to work with, there's nothing to say against it (considering that it might have benefits like more intelligent compression across frames), and just adopting MNG might be somewhat easier. My point is that there are ways to do this that don't mess with the artists' workflow. If the artists are happy with MNG, then of course MNG should be used (though the two things are of course not mutually exclusive, considering we'd still load a significant number of MNGs given all those different walking animations).

Idle animations: I like the idea of having idle animations for the carriers. I would implement them slightly differently though; I believe that we should just define a program called "idle", and then this program determines whatever the carrier does. Usually it should just have an animate command, or some randomized selection of animate commands. I don't think savegame compatibility is going to be a problem in that case, unless you want to remove an existing idle animation. But a) I don't think we want to do that, and b) even in that case, savegame compatibility shouldn't be a problem.

Top

Quote

Questions

Regarding the size (i.e. # of frames) of the individual animations:

1) Does it make any great difference in memory usage (and/or performance) if an animation is portrayed, for example, in one 150-frame segment versus 3 50-frame segments that were always run contiguously in the same order? Which approach would be preferred?

2) Would that change if using mng format?

Regarding animation control:

Pardon my ignorance of the entire potentials of the conf files as they now stand.

1) Is there currently the capability to define an arbitrary animation sequence in the conf file without deeper coding changes given the appropriate trigger(s) and graphics are in place?

2) What are the drawbacks of providing the ability to spawn new animation cycles solely via the conf file?

3) Could the rate of travel in walk cycles be controlled via conf file parameter(s)?

4) Could a sequence of multiple animations be "scripted" either in the conf or some other vehicle? And the execution of those scripts be controlled from the conf file?

I see little people.

Top

Quote