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

Author Topic: SFML and Sprites  (Read 9699 times)

0 Members and 1 Guest are viewing this topic.

masskiller

  • Sr. Member
  • ****
  • Posts: 284
  • Pointers to Functions rock!
    • MSN Messenger - kyogre_jb@hotmail.com
    • View Profile
    • Email
Re: SFML and Sprites
« Reply #15 on: December 26, 2012, 03:02:49 am »
Quote
That's why. Now, he animates very fast, is there a solution to solve that?

If your animation is too fast just increase the delay time. Delay time depends on what kind of effect you want to give, how many sprites are you animating and so on, it's perfectly tweekable as you may wish it to be.

Quote
I am guessing that T is causing the delay I am looking for in this place.

It is indeed what causes it, notice that the getElapsedTime() function returns an sf::Time value that can be compared to other sf::Time values, take a look at this code, which is the SFML source of Time.cpp

bool operator <=(Time left, Time right)
{
    return left.asMicroseconds() <= right.asMicroseconds();
}

bool operator >=(Time left, Time right)
{
    return left.asMicroseconds() >= right.asMicroseconds();
}

Instead of manually converting times and ridding of the T parameter you can just compare times as needed, it has even more precision than the seconds comparison.

I just noticed that in my code I left a mistaken "asSeconds()" call. That was a mistake I overlooked since you should be comparing sf::time with another sf::time and not with a float. asSeconds() returns a float and it doesn't know how to compare itself with time, which is the reason your compiler whines.

It should look something like this:

if(clock.getElapsedTime() >= T)

My bad for overlooking this when I was refactoring your code. With that change and leaving the parameter T as I set it should work well and with no compiling errors.

Edit: As a side-note, you can perfectly use variables instead of the plain numbers, it makes your code more controllable over-time, mainly when you forget what that number meant. Not to mention that it can also may make your code work in more than one situation.

All you need to do is set the width and height variable before your loop using the texture's getSize function:

unsigned width = (texture name).getSize().x;
unsigned heigth = (texture name).getSize().y;

///further settings of the particular sprite sheet.

///Game loop and fancy stuff.
 

And the code can work for any sprite sheet that be organized in a horizontal way. You should always aim for making your solution broader unless you require something extremely specific you'll never use for anything else. It's always better to write one semi-universal animator than an animator for each sprite sheet you use.
« Last Edit: December 26, 2012, 03:15:46 am by masskiller »
Programmer, Artist, Composer and Storyline/Script Writer of "Origin of Magic". If all goes well this could turn into a commercial project!

Finally back into the programming world!

synok

  • Newbie
  • *
  • Posts: 18
    • View Profile
Re: SFML and Sprites
« Reply #16 on: December 26, 2012, 03:31:20 am »
All I did now was changing the typo you made and it worked, although the animation didnt loop so all I added was
Code: [Select]
clock.restart(); when the frame reaches 6.

While were at it, I do not understand why the text kind of "blinks". I added
Code: [Select]
window.draw(text); in the event of where the mouse button is pressed. This should render the text only, I guess.

masskiller

  • Sr. Member
  • ****
  • Posts: 284
  • Pointers to Functions rock!
    • MSN Messenger - kyogre_jb@hotmail.com
    • View Profile
    • Email
Re: SFML and Sprites
« Reply #17 on: December 26, 2012, 04:00:04 am »
Quote
While were at it, I do not understand why the text kind of "blinks". I added
Code: [Select]

window.draw(text);

in the event of where the mouse button is pressed. This should render the text only, I guess.

If I understand well, what you want to do is to render only the text when you click and nothing else. In that case you need to make the draw calls as a response of when the mouse isn't being clicked, in other words, the false part of the mouse event polling.

///The event loop.

 /**The conditional of your mouse and all it does. Draws only the text*/
  else
{ /*draws everything.*/  }
 

So in this particular case all your draw calls should be based on events (or lack of them) and no draw call should be outside of your event polling I guess.
Programmer, Artist, Composer and Storyline/Script Writer of "Origin of Magic". If all goes well this could turn into a commercial project!

Finally back into the programming world!