This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Animation events

Animation events
by on (#148546)
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?
Re: Animation events
by on (#148558)
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.
Re: Animation events
by on (#148581)
I use control codes with variable length arguments:

FF=hold on last frame
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]
Re: Animation events
by on (#148593)
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.)
Re: Animation events
by on (#148641)
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.