Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Animation  (Read 4467 times)

0 Members and 1 Guest are viewing this topic.

Metaby

  • Newbie
  • *
  • Posts: 23
    • View Profile
Animation
« on: May 10, 2008, 10:30:32 pm »
Hello, I have 3 Pictures (.tga)
KnightWalk1
KnightStand
and
KnightWalk2

I would to make an animation,
while pressing a key, and the knight walks forward,
it should draw this animation
first draw KnightWalk1
second draw KnightStand
and last draw KnightWalk2

i haven't any idea to realize this, i have tried it with clock and integers, but nothing worked, a function to do this isn't availalbe too, have anyone an idea to realize this?
sorry for my bad english, mfg max
I hacked 127.0.0.1 *g*

eleinvisible

  • Newbie
  • *
  • Posts: 47
    • View Profile
Animation
« Reply #1 on: May 12, 2008, 02:16:15 pm »
I would store all three images in some form of container, such as a STL vector. Then when the user presses a key, you just change the texture and re-render that object.

Pseudo-Code:
Code: [Select]

image frame[2];
//assign images to frame[0,1,2]
if (key == Left)
{
    x++;
    if(x>2){x=0;}
    display_image = frame[x];
}


Of course you would probably want to only allow one change per frame.

quasius

  • Full Member
  • ***
  • Posts: 166
    • View Profile
Animation
« Reply #2 on: May 12, 2008, 07:07:11 pm »
To do it correctly, you should derive an AnimatedSprite class off of sf::Sprite.  Then you can track which cell of a sprite sheet you are using and adjust the subrect of the sprite as necessary.  I found the best place to put these checks was in an overrided render function, since that should be called every frame anyway.  But this required stripping the const-ness out of the base class render functions, since you need to modify the subrect.  (That or declaring the subrect and whatever else you need mutable.  Either way, you need to change a bit of stuff in SFML.)  If you don't want to touch SFML, you can add some kind of update function to your AnimatedSprite class to call each frame, but I didn't like the idea of having to always check if a sprite was animated and call Update() if it was.

eleinvisible

  • Newbie
  • *
  • Posts: 47
    • View Profile
Animation
« Reply #3 on: May 13, 2008, 02:05:10 am »
To above: You could just have made all of your sprites animated with just one frame for non-animated sprites then you could still call the update function on all of them. I would suppose it would have a small overhead (considering you have an integer to keep track of current frame position).

quasius

  • Full Member
  • ***
  • Posts: 166
    • View Profile
Animation
« Reply #4 on: May 13, 2008, 05:45:29 am »
Quote from: "eleinvisible"
To above: You could just have made all of your sprites animated with just one frame for non-animated sprites then you could still call the update function on all of them. I would suppose it would have a small overhead (considering you have an integer to keep track of current frame position).


I could have, but it would be a bad idea.  Treating static sprites as 1-frame animated sprites would add tons of needless overhead, especially in memory.  There are several variables needed to track the state of the animated sprite including frame number, descriptors of the layout of the sprite sheet, etc.
I'm pretty happy with my implementation.  It would have been nice to avoid modding SFML, but all the dancing around would have been a much bigger deal then just changing a couple of things in the library.  This is why using open source libraries is nice.  Might as well take advantage of it when it's useful.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Animation
« Reply #5 on: May 13, 2008, 06:26:44 am »
The constness in Draw / Render may be removed soon, it starts to bother me too ;)

I think it was a bad design, as it didn't allow any kind of change on the window (setting a mask, changing the view, ...) while rendering a drawable. Not so sure about the drawable itself (an update function separated from the rendering is usually a good idea), but anyway I'm going to remove these consts as well.
Laurent Gomila - SFML developer

zarka

  • Jr. Member
  • **
  • Posts: 81
    • View Profile
Animation
« Reply #6 on: May 13, 2008, 09:53:44 am »
i agree the constness of the render function is not that much fun ...

my current workaround consist of a const_cast on the this pointer .. which isn't very pretty :)
//Zzzarka

Metaby

  • Newbie
  • *
  • Posts: 23
    • View Profile
Animation
« Reply #7 on: May 13, 2008, 03:13:00 pm »
Ok, thanks for your replay @ all :D
I hacked 127.0.0.1 *g*

workmad3

  • Jr. Member
  • **
  • Posts: 71
    • View Profile
Animation
« Reply #8 on: May 13, 2008, 04:17:27 pm »
as a suggestion to Laurent:
would it be possible to add a non-const overload to the draw function? It seems like you should be able to draw const sprites, which you would prohibit by making the draw function non-const completely, but providing both a const and a non-const version of the same function should work.

 

anything