About combo's animation and cycling

[Sludge]

I think there are still a lot of things to sort out when we're talking about animated combo's and cycled combo's.

The first problem is that combo cycling only works on the base layer, and not on other layers (this one is the easiest to solve in comparison with the other problems).

The second problem (which is more complicated), is that the timing is off. So when you appear on a screen, the animated combo has already gone through a few frames, and the 2nd combo in the cycle will never appear on the screen. This means that you have to calculate not only animated combo's, but cycled combo's as well to build the screen layout when first entering the screen. For example: if you have an up/down moving spike combo (a damage/non-damage cycled combo) the combo that appears when first entering the screen is always the damage combo, and never the non-damage combo. This is something that shouldn't happen.

The third problem is the most complicated and has to do with timing as well. To see this problem for yourself you can make 3 animated combo's:
- A timer that counts from 0-10
- A timer that counts from 5-0
- A timer that counts from 2-0
Let the 5-0 timer and the 2-0 timer point to the 0-10 timer when the animation is completed and set all animation speeds to 60 frames.
If you see this in action you'll notice that when the 5-0 and 2-0 timers have ended and switched to the 0-10 timer, the timer animations are the same. This can also be a thing that you don't want to happen.

I think the only solution for this timer problems are 2 things:
- Make a check box for each combo: "reset animation timer": this will set the animation frame to 0 when the combo appears (either when entering the screen, or when a secret is triggered).
- Store the animation frame of each seperate combo on the screen for each layer. This can take up some memory, but you'll only have to store these values for 1 screen (and calculate them when entering the screen).

[C-Dawg]

Borrowing some terminology from http://www.armageddongames.net/showthread.php?s=&threadid=65900 (a good thread discussing animated combos)...

The reason I suggest using the term "cell" in the manner it is defined in the cited thread ( A "cell" being a set of combos all of which animate in sequence ) is that when you start talking about animating combos and animating tiles without a distinct name for sets of combos animating, things get confusing. I'm not sure I understand what you're trying to say with your first timing bug for exactly this reason.

The second timing problem you're getting at it something DN is already aware of. The issue is that any individual combo is always animating through it's tiles, whether or not it is visible to the player. (I think DN has some sort of game clock that just incriments everything at the same time.) So when a cell changes combos, the new combo will begin it's animation wherever it happened to be while it was happily animating in the background.

This makes doing things like animated doors opening and rubble from bomb blasts difficult because depending on when Link triggers them, the animation may be cut short. It could be repaired if a combo always began it's animation sequence anew when revealed in a cell.

-C

[StarFox]

Originally posted by C-Dawg
This makes doing things like animated doors opening and rubble from bomb blasts difficult because depending on when Link triggers them, the animation may be cut short. It could be repaired if a combo always began it's animation sequence anew when revealed in a cell.

This is the problem I am most concerned about. For now, I'm animating the cell in question by letting each frame have its own combo, therefore eliminating the threat of the animation being cut short. This isn't the best solution, however, and I'd like to see ways to reset the combo animation. The "reset animation timer" idea that Sludge mentioned sounds like a good idea to me.