Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Animation Class Improvements #32

Open
stefanbeller opened this issue Sep 24, 2012 · 0 comments
Open

Animation Class Improvements #32

stefanbeller opened this issue Sep 24, 2012 · 0 comments
Labels

Comments

@stefanbeller
Copy link
Collaborator

Migrated from clintbellanger/flare#576
Originally opened by @clintbellanger

Few classes should have to handle frame counting and resetting, image loading, etc. explicitly. Instead the Animation class should handle these cases.

Right now it's mainly geared towards different Entity animations. We should decouple that a bit.

  • Use an init() function instead of passing that ton of stuff in the constructor
  • Allow init() from parent, or loadAnimation() from file (especially for animations with single states)
  • Allow animations to load its own image, or allow the parent class to pass it in via ::setImage() (e.g. image shared between multiple Animations). Have a bool image_cleanup set in Animation::loadImage() so that the class knows whether to delete the SDL_Image memory later (otherwise leave it to the parent class).

Examples where we want to use it:

  • When the player levels up, put an animated icon over the Character and Powers menu to remind players of their new points.
  • On the Cut Scene game play state we could use simple animations for story frames.
  • Perhaps convert the TileSet class to use this for animated tiles.
  • Perhaps convert the Powers class to use these (could be nice to refer to an existing animation instead of having all the animation data inside the actual power definition)

Also, ideally, the class should support Starting and Ending frames, particularly for looped animations. The animation definition could specify which frames are the startup, then the middle is the loop, then the end frames. That way we could easily do many nice things:

  • When the hero starts running they can have a short (~4 frame) section where the take off to begin and slow down to end.
  • Missile spells could have a flash startup and an explosion on impact, without hacking in after-effect "powers".
@stefanbeller stefanbeller added this to the Post-1.0 milestone Jun 20, 2014
@dorkster dorkster removed this from the Post-1.0 milestone Mar 12, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants