I call "animation event" an event that is triggered on a certain animation frame. Such feature could be useful e.g. to activate a hitbox or a sound effect of a weapon in a specific animation frame without having to explicitly time the animation in code.
First idea that came to mind would be to have special animation frames embedded within the animation, that instead of changing the displayed animation frame would call an event function, or return a special event code from the animation update routine.
Has anybody implemented something like this in NES/SNES projects? If so, how did you go about it?
In Alisha, when you kick twice in a row, it waits for the key frame before going into the other animation. If it already past the key frame, it just starts the second animation abruptly.
I use control codes with variable length arguments:
FF=hold on last frame
FE=loop
FD=reverse animation
FCxx=play soundfx #xx
FBxx=execute event #xx
FAxxxx=jump to code at $xxxx
My animations look like this:
FrameID, Time
FrameID, Time
Ctrl, [Args]
Not SNES/NES, but if I remember how QuakeC did it correctly, enemies used per-animation-frame-defined functions to define/select what frame came next, and on appropriate frames, do things like produce their shots.
I'd probably do something like a tracker setup where every frame of an animation had a "do something?" variable byte, with 0 being "no" and other values being indices into a function table (for that object or globally, not sure.)
never-obsolete wrote:
I use control codes with variable length arguments:
...
Yeah, that looks kind of similar to what I was thinking. I guess I'll go with just the subroutine call command though, because I'd like to keep my animation code as agnostic to the types of events as possible. My animations are currently a linked list of the animation frames, so this should be easy to throw in there. The cost of one or two extra bytes in ROM per event (as opposed to specialized event types) doesn't seem too high to me. Or I may build a list of all the possible animation event handlers and use a single byte to reference them (as suggested), although not sure if that's really necessary.