Simplifying animation frame wml

[Coffee]

Yet another change of idea (I think this one's worth it though)

From testing I have found another possible work-around for the sound thing -- making the sound frame have no duration and putting it just before the frame you want the attack. e.g.

Code: Select all

        [frame]
            image="units/nagas/fighter-melee-1.png:130"
        [/frame]
        [if]
            hits=yes
            [frame]
                sound={SOUND_LIST:SWORD_SWISH}
            [/frame]
        [/if]
        [else]
            hits=no
            [frame]
                sound={SOUND_LIST:MISS}
            [/frame]
        [/else]
        [frame]
            image="units/nagas/fighter-melee-[2~6].png:[100*2,90,80,70]"
        [/frame]

I think this might solve the problem of doubling up everywhere of images and durations for frames with sound in them with minimal extra effort. What do you think (Boucman et. al.)?

[Boucman]

I am not sure what I see here...

what you wrote is perfectly valid with the current syntax because IIRC duration=1 if nothing is specified but if nothing is specified image= will default to the base image for the unit which is not what you want.

if you set image= to the image that was just before then this works fine, but there is no change to the current syntax... or did I miss something ?

[Coffee]

I am not sure what I see here...

what you wrote is perfectly valid with the current syntax because IIRC duration=1 if nothing is specified but if nothing is specified image= will default to the base image for the unit which is not what you want.

if you set image= to the image that was just before then this works fine, but there is no change to the current syntax... or did I miss something ?

From my testing, both yes and no. Currently 'duration' defaults to '1' AND if not specified, the image will be the last seen image*. I don't see a 1 frame duration changing the way an animation is seen on screen from testing.

*EDIT: actually it seems to be only the first image in a list if not specified unfortunately. Might take some work to hunt down where to fix this.

[Boucman]

hmm

be very carefull with your testing here. I'm pretty sure image defaults to the base fame and i'm almost certain it doesn't use the last seen image since that would imply complicated code I didn't put in.


however I know from years of falling into the same traps in the animation engine that duration 1 frames are invisible on my (rather fast) computer but do appear on slower devices like handhelds. my advice is to test that hypothesis with a much longer duration

if it repeats the last image, that's weird but it makes sense that it's the first image that is shown in a list. the list of image= is a progressive parameter which will display an image based on the time in the current frame. since your frame is of duration 1, it's logical that the first image is returned

[Coffee]

be very carefull with your testing here. I'm pretty sure image defaults to the base fame and i'm almost certain it doesn't use the last seen image since that would imply complicated code I didn't put in.


however I know from years of falling into the same traps in the animation engine that duration 1 frames are invisible on my (rather fast) computer but do appear on slower devices like handhelds. my advice is to test that hypothesis with a much longer duration

if it repeats the last image, that's weird but it makes sense that it's the first image that is shown in a list. the list of image= is a progressive parameter which will display an image based on the time in the current frame. since your frame is of duration 1, it's logical that the first image is returned

You are right.

Hmm, can we maybe do it a different way by introducing a new "sound_frame" with start time where the regular frames leave off? In this way we could make it relative to the appropriate frame more easily:

i.e.

Code: Select all

start_time=-1000
sound_start_time=current_time+100
[frame]
    image=attack[1~6].png:100
[/frame]
[sound_frame]
    sound=hits.ogg
[/sound_frame]

So, "current_time" would mean current frame time, "missile_current_time" would mean for current "missile_frame", etc.

What do you think?

[AI]

You can invent any type of frame you want, the only special ones are frame and missile_frame. The former is the unit itself, while the presence of the latter removes the former's standard combat offsets.
As for start times, I believe that if you want the sound_frame to start at 0, you have to specify sound_start_time=0.

[Coffee]

You can invent any type of frame you want, the only special ones are frame and missile_frame. The former is the unit itself, while the presence of the latter removes the former's standard combat offsets.
As for start times, I believe that if you want the sound_frame to start at 0, you have to specify sound_start_time=0.

I know what there currently is The point is to make it more human readable and let the computer figure out the absolute timings.

Perhaps I wasn't clear exactly. For the naga the attack animation could become:

Code: Select all

        start_time=-250
        sound_start_time=current_time+130
        [frame]
            image="units/nagas/fighter-melee-[1~6].png:[130,100*2,90,80,70]"
        [/frame]
        [if]
            hits=yes
            [sound_frame]
                sound={SOUND_LIST:SWORD_SWISH}
            [/sound_frame]
        [/if]
        [else]
            hits=no
            [sound_frame]
                sound={SOUND_LIST:MISS}
            [/sound_frame]
        [/else]

which could be simplified to:

Code: Select all

        start_time=-250
        sound_start_time=current_time+130
        [frame]
            image="units/nagas/fighter-melee-[1~6].png:[130,100*2,90,80,70]"
        [/frame]
        {HITS_SOUND_FRAME ({SOUND_LIST:SWORD_SWISH}) ({SOUND_LIST:MISS})}

with a macro or something.

This way the sound could be put in relative to the current animation time and at the appropriate point without having to know the absolute time. Same would go for missile sounds, replacing "current_time" with "missile_current_time+{NUMBER}". In this way you could have frames before the attack leading up and change the duration without having to change the sound time. I think this would be easy to code with what we already have (would require the addition of relative start times to WML capabilty).

An extra advantage is that this would be gender neutral for the units with multiple genders.

[Coffee]

Sorry to double post, but from playing around some with the unit animation files I have found that they all have attack sounds, etc. nearly around the same time and there is already a macro called SOUND:HIT_AND_MISS to be used.

I'll post a patch with changes where it makes it easier to read the unit files. For example the naga attack could become (without any c++ modifications):

Code: Select all

        [filter_attack]
            name=sword
        [/filter_attack]
        offset=0.0~0.3,0.3~0.5,0.5~0.60,0.60~0.3,0.3~0.0
        start_time=-250
        [frame]
            image="units/nagas/fighter-melee-[1~6].png:[130,100*2,90,80,70]"
        [/frame]
        {SOUND:HIT_AND_MISS ({SOUND_LIST:SWORD_SWISH}) ({SOUND_LIST:MISS}) -120}

Seeing it on slow motion indicates that the sound probably comes in a little too early. But that is probably for the artists to determine or fix.

[Boucman]

not sure I understand the meaning of current_time would it be a frame_start_time or something ?

[Coffee]

not sure I understand the meaning of current_time would it be a frame_start_time or something ?

Ok. I'm probably getting ahead of myself. Maybe one thing at a time hey

Currently there is a core macro under macros/sound-utils.cfg called SOUND:HIT_AND_MISS. This would allow more simplification of animation WML where a hit and miss sound is played for the same animation in a group of related frames (most units). Unfortunately, as per https://gna.org/bugs/?20581 it doesn't work as claimed.

If we can fix this, then I have already converted many of the units across to use the SOUND:HIT_AND_MISS and could finish this for a patch without changing any C++ code.

After this patch, I would assume that it would be clearer if the start time for the sound frame could be relative to one or the other "frame" blocks, rather than by specifying an absolute start time (here is where the "current_time" thing could come in).

[Boucman]

ok, it's a bit more clear, I understand why you need a new C++ side feature (to ease writing macro) so let's get all the patches floating around in and then we'll see your idea.

Btw, are you on IRC from time to time ? i'd be interested in discussing a bit with you...

[Coffee]

Btw, are you on IRC from time to time ? i'd be interested in discussing a bit with you...

I've got on IRC. Had to remember how to do it. Looks like my unimaginative nickname was already taken, though