Possible improvement over Sprite/Action/Frame

Brian Chin
  • Brian Chin

    Brian Chin - 2002-08-13

    Didn't know whether to put this idea in the feature requests, or in discussion, but here we are.

    In the current implementation of sprites, we have two abstraction layers on top of actual frames of animation. I don't think this is necessary, and suggest this improvement to the system:

    A given sprite has a set of frames. At our option, we are able to give a name to a frame, similar to the action name. Each frame has essentially a "next" pointer to the next frame in this sequence. This allows for nearly the same behavior as Actions with a few benifets

    First, it allows for a simpler representation of sprites within the resource files. Instead of two layers of data to store (action/frame), you only have one, with an extra field.

    Second, it allows for more complex behaviors of "actions". Say you have a walking animation, but you want to start it off on either the right or the left foot. With this system, you can have two separate keyframes within the same "action" for the appropriate starting points in the walk animation.

    Furthermore, you can create animations which have a "fade in" series of frames to bring the sprite into the apropriate action loop. The last frame of the fade in points to the appropriate location in the animation loop to start at.

    Also, for one time animations, you can just have the last frame point to nothing, which would signal the end of the loop.

    The syntax would actually be quite simple. As with the action code, you'd have something like:


    But instead of having to increment a frame number, you'd just call


    This would automatically take it to (obviously) the next frame. If there is no next frame, it could return false or something to signal that we're at the end of an animation.

    To take this idea further, detatch actual animation "cels" from "frames", so that several frames can use the exact same graphical cel in the animation. This Sprite/Frame/Cel system wouldn't be much more complex than the Sprite/Action/Frame setup, and be potentially more flexible.

    Again, any further comments are welcome.

    • Lee Thomason

      Lee Thomason - 2002-08-14

      Looking at the high level, you could either

      1) Look at at a numbered series of frames, bound to a certained named sprite. No abstraction would be provided by the engine.

      2) Look at the cells as a pool, that can arbitrarily be assigned action/frame#/frame number meta-information.

      Kyra sits more or less in the middle, and you're exploring moving it in the latter direction.

      As always, its a tradeoff in API simplicity to flexibility. You can leave all your actions to NONE and essentially degenerate to the only frame case (which many people do) or you have needs that fit with the action/frame model. (The 50% case, perhaps.) Adding to the action/frame model in the engine code isn't perhaps too hard, but tool chain support would be tricky. The model is deep in the tool chain metaphor.

      I appreciate the problem you're trying to solve with more indirection. I've wrestled with it myself. On the other hand, it does get to be complex in an API. One thought would be to add it as "extra" functionality. Sub-class KrSprite & KrSpriteResource to provide more complex and flexible funcitonality for people who need that. I'm not sure I've thought through the whole thing well enough to know if that makes sense, but it seems reasonable. The font/text class does essentially that: spoof the sprite resource interface to look like a font.

      DoStep() by the way is the "nextFrame()" call.




Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks