Exult Forum

You know i've noticed that the guardian in the BG intro doesn't mouth out the words properly he just loops the same animation over and over. He does mouth them out properly when not using exult.

Yes, we know. The lip-synch information for both BG and SI is hardcoded within the executable, and therefore we have to implement it from scratch. As you can guess, it is very difficult to match the correct mouth frame with the spoken text...
If someone volunteered to do this...

Well, i was thinking about it, but it really doesnt look easy. If i judge it right, there are about a 1000 frames to time and place!
For the mouth its currently done by cycling roughly 76 times through the same 13.

So, if no one minds, id like to give it a try, but its been a while since ive done some coding and i would like to fiddle around with the MS Visual Studio (I hope theres no big flame war turning towards me!). I havent used it for C++, so in this aspect i dont know it too good yet. But in general, would there be any problem with that? Any tips how to set up the environment?

Don't do anything.... not yet.

I'm currently doing work to change the way the cinematics are done. Improving the cinematics in there current state isn't the easiest thing to do. Plus if you aren't familiar with Exult's internals, understanding how they are done may be somewhat difficult.

-Colourless Dragon

Ah Colourless Dragon,
I dont quite get get what you mean with internals, but ive looked at the code and i think currently this change in particulary is just a lot of work, but easily done. You dont need to much understanding of the object-structure and can simply (more or less) take whats there and do a little different timing.

Anyway, no problem with me, i dont really want to mess around with other peoples code. I just found the thought interesting, sort of to see, if i still can do it.

Just a secondary idea i had about the movie: Wouldnt it be possible to record the original scene and simply replay it? Maybe you thought of that, but what stands against that approach?

Maybe you thought of that, but what stands against that approach?

Copyright issues

You could always be a lazy bastard:

Take a second computer with a video capture board, and the first one
with some sort of TV-out, and go play the original BG, and capture the
intro into an AVI or MPG, and just play that. Problem solved.

I'll take my chances speaking without really knowing what I'm talking about

To me it sounds like a sound animation system would need to be able to:

- Ask for the current frame number in the currently playing animation
- Split the animation into "blocks" - that is a bunch of sets of (startframe, endframe)
- Match each block of text to one "block" of the animation.
- The last text should match a block which is the last part of the animation
- For each block of text displayed on the screen hold it there until the corresponding block of animation frames has been played.

As the animation should run at a fixed framerate to make it run equally fast on every machine you would in effect put a framerate limit on the text display too by using this approach and the text speed wouldn't depend on the CPU speed (I think it does this now).

I realise that the intro is probably not one long animation but rather a bunch of frames you repeat over and over again (in a sense doing your own animation) but I believe an approach like the one outlined above will still work fine.

- Telemachos

Hmm, it seems to me your talking about synchronzing the written Text with an animation. This seems to be solved already. But the synchronizing consist of 3 parts:

1. several indepent 'frames' for mouth and eyes.
2. the sound for the speech.
3. the text.

So 2 and 3 are running well together, but now you have synchronize 1 and 2, which is quite a problem. Theoretically you have about 1000 frames for the mouth alone, for each you can choose from 13 different states. Although you can find ways to block them, there is still a huge amount of finetuning necessary.

This is assuming the animation is hardcoded to that specific line of text.
Specific pieces of the animation could be keyed to phoenems so that it
would have been easier to program.

i.e. a small file saying

"Avatar!"
"short a, length of xx milliseconds, V, length of xx milliseconds,"

etc, with a corresponding animation to each phoenem, set to the same
duration that the audio has.

(ahh caffeine, the killer of many coherencies)

As far as ive seen in the code, there are 13 different animation states for the mouth, starting with closed, going over open to closed again.
These are played over and over again at constant speed.

I thought of simply splitting the circle in half, leaving 2 sub animations: closed -> open, open -> closed. No need to care about the timing during this animations (the way it is, could just be kept). Instead, do some timing after each of these halfcircles, leaving the mouth open longer and more consistent closed. That seems good enough for me?

To make it proper your idea is an interesting one, but sounds like an effort youd make when you want to use it for future needs. I think there are also some timing problems when adapting the phoenems to each other.

But thats just guessing, im not so acquainted to english.