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

Author Topic: Thor C++ Library – An SFML extension  (Read 137929 times)

0 Members and 2 Guests are viewing this topic.

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6287
  • Thor Developer
    • View Profile
    • Bromeon
Thor C++ Library – An SFML extension
« Reply #105 on: July 06, 2011, 01:01:44 am »
gavintlgold, thanks for the explanation.

gsaurus, I don't know whether a [0,1] float would be easier on user side. Currently, the user just has to pass the frame time, and the animations are automatically updated according to the time passed. The animations themselves work with absolute times. Maybe I could change their (thor::Animation) time handling to normalized floats and leave thor::Animator's absolute. But since an animation has often the same duration, it would be necessary to specify the absolute time duration multiple times (once for each animator).

Concerning the scale function: They would be quite customizable with std::tr1::function. But I am probably going to implement the basic animation system first...
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

gavintlgold

  • Newbie
  • *
  • Posts: 21
    • View Profile
Thor C++ Library – An SFML extension
« Reply #106 on: July 06, 2011, 01:15:43 am »
Ah, very nice. Using a tr1::function for scaling sounds like a great idea. I suppose it would work very much like an affector does with particles now? That's an excellent way to accomplish the same thing. Maybe there's a way to have animation affectors work directly with particles too (for fading in and out for example)--but that might be too complicated.

If you'd like, I'll make (and donate) a few stock animation affectors (whatever you'll plan on calling them) that will accomplish the math of what cpptweener does, for cubic or bouncy or other interpolations. So for now you can just get the basic system working for a linear animation.

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6287
  • Thor Developer
    • View Profile
    • Bromeon
Thor C++ Library – An SFML extension
« Reply #107 on: July 06, 2011, 01:24:58 am »
Quote from: "gavintlgold"
Maybe there's a way to have animation affectors work directly with particles too (for fading in and out for example)--but that might be too complicated.
The idea is basically a good one, however I would have to find an abstract way to cover both sf::Sprite and thor::Particle, but their interfaces are completely different. The user code is likely to become more complicated with such an enforced commonality, so I rather risk to duplicate a few things. Maybe I can still reuse code internally.

Quote from: "gavintlgold"
If you'd like, I'll make (and donate) a few stock animation affectors (whatever you'll plan on calling them) that will accomplish the math of what cpptweener does, for cubic or bouncy or other interpolations. So for now you can just get the basic system working for a linear animation.
Thanks a lot for the offer! But don't implement something specific for Thor yet. I still don't know whether and how I will provide this functionality, and I don't want you to rewrite everything ;)
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

gsaurus

  • Sr. Member
  • ****
  • Posts: 262
    • View Profile
    • Evolution Engine
Thor C++ Library – An SFML extension
« Reply #108 on: July 06, 2011, 02:14:01 am »
Well I was moved by gavintlgold suggestion about interpolations. Both update ways would be good.

Is there any advantage on using floats (time in seconds) instead of integers (game frames)? I don't see why one would want to play an animation for one game frame and half.

I didn't look at the source code neither tried the library yet, so pardon me to ask: is the dt passed on the Update of the Animator the time passed since the last game frame?

Are you planning to remove the duration getter from the Animation class? (why?)
Pluma - Plug-in Management Framework

gavintlgold

  • Newbie
  • *
  • Posts: 21
    • View Profile
Thor C++ Library – An SFML extension
« Reply #109 on: July 06, 2011, 02:24:16 am »
Quote from: "gsaurus"
I don't see why one would want to play an animation for one game frame and half.


In my game engine, at least, I calculate the time since the last frame and use that for physics calculations and any sort of time-based animation. I like this method because it allows players of the game to have as fast an FPS as their computer allows. It also opens the opportunity for those with slower PCs to play the game properly at 25 FPS if the need arises, since everything is based on the delta.

The game frame system that you're using is an alternative to this, in which all frames are equally spaced. It works as well, but is less flexible as it requires all gamers to be playing at the same FPS. While it doesn't really matter for most 2d games where the graphics and physics aren't likely to get very complex, I figure it allows room for complexity if I use the delta-based system.

So the DT stands for milliseconds per frame--in your engine you could pass it a constant value, but in mine it's not so simple.

gsaurus

  • Sr. Member
  • ****
  • Posts: 262
    • View Profile
    • Evolution Engine
Thor C++ Library – An SFML extension
« Reply #110 on: July 06, 2011, 03:27:27 am »
Quote from: "gavintlgold"

The game frame system that you're using is an alternative to this, in which all frames are equally spaced. It works as well, but is less flexible as it requires all gamers to be playing at the same FPS

While game logics are updated at a fixed rate, display is updated whenever possible. So slower machines may experience frameskip (different FPS).

I think this is particularly good for networking games that need to run on all machines the same way and keep state correct from frame to frame. I think that calculations with the elapsed time for game logics would result in small errors, leading to higher synchronization problems.

I think game logics should always play at a fixed rate.
For instance, if one fix game logics to 30fps, the game loop can still be 60fps, updating animations whenever possible (so benefiting from better machines), while game logics are updated every 2 frames.
Though I don't see a reason to update it more often than 60fps, so considering 60fps the time unit, an integer fits well and isn't susceptible to small errors.
Pluma - Plug-in Management Framework

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6287
  • Thor Developer
    • View Profile
    • Bromeon
Thor C++ Library – An SFML extension
« Reply #111 on: July 06, 2011, 12:00:59 pm »
Quote from: "gsaurus"
Is there any advantage on using floats (time in seconds) instead of integers (game frames)?
I think floats are more flexible. With integers, the user is forced to manually compute the correct frame or to keep a fixed framerate.

Quote from: "gsaurus"
I didn't look at the source code neither tried the library yet, so pardon me to ask: is the dt passed on the Update of the Animator the time passed since the last game frame?
Yes.

Quote from: "gsaurus"
Are you planning to remove the duration getter from the Animation class? (why?)
It depends on the choice of the float range. If I use the absolute time like now, I will keep thor::Animation::GetDuration() because thor::Animator needs it. But for a scalable [0,1] (scaled inside thor::Animator), a method to return the animation duration is pointless.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

gsaurus

  • Sr. Member
  • ****
  • Posts: 262
    • View Profile
    • Evolution Engine
Thor C++ Library – An SFML extension
« Reply #112 on: July 06, 2011, 12:37:22 pm »
What if one want to play an animation in backwards?
Pluma - Plug-in Management Framework

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6287
  • Thor Developer
    • View Profile
    • Bromeon
Thor C++ Library – An SFML extension
« Reply #113 on: July 06, 2011, 01:09:58 pm »
Good point. This behavior can be implemented with a class derived from thor::Animation that wraps another animation and forwards the difference between the total and the passed time. Similar to the above class for parallel animations.

This may seem complicated, but note that thor::Animator just provides an easy interface to play animations. It takes care of details like progress computation, choice of the right animation, recognition of the animation's end, etc. You can also directly access thor::Animation, its method Apply() takes an absolute progress time (unlike thor::Animator::Apply() which takes a time difference).
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

gsaurus

  • Sr. Member
  • ****
  • Posts: 262
    • View Profile
    • Evolution Engine
Thor C++ Library – An SFML extension
« Reply #114 on: July 06, 2011, 01:26:41 pm »
I see.
Quote from: "Nexus"
You can also directly access thor::Animation, its method Apply() takes an absolute progress time (unlike thor::Animator::Apply() which takes a time difference).

Well then I don't need the Animator. But yeah I know what you mean, the interface provided by the Animator should be enough for most situations.
Pluma - Plug-in Management Framework

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6287
  • Thor Developer
    • View Profile
    • Bromeon
Thor C++ Library – An SFML extension
« Reply #115 on: July 06, 2011, 05:37:27 pm »
I finally committed the new Animation class hierarchy. There is now a separate module for animations in Thor.

Up to now, I have still used absolute times in thor::Animation. Maybe this will change to a [0.f, 1.f] progress scale in the future. The thing I don't like with that approach:

Code: [Select]
thor::FrameAnimation::Ptr anim(new thor::FrameAnimation);
anim->AddFrame(1.f, sf::IntRect(...));
anim->AddFrame(4.f, sf::IntRect(...));
// Durations are relative to each other:
// First frame takes 1/5, second 4/5 of the time

thor::Animator animator1, animator2;
animator1.AddAnimation("id", anim, 2.5f);
animator2.AddAnimation("id", anim, 2.5f);

The duration is no more part of the animation, one has to specify it at the animator. So, if multiple animators refer to a single animation, the duration has to be specified every time, although an animation mostly has the same duration for all sf::Sprites it is applied to...

On the other side, a [0,1] scale makes many things simpler and seems like a good approach as already proven by thor::Affector.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6287
  • Thor Developer
    • View Profile
    • Bromeon
Thor C++ Library – An SFML extension
« Reply #116 on: July 10, 2011, 02:38:06 pm »
Good news for the people who use the dynamic dispatchers: They have become much more powerful, they support now implicit derived-to-base conversions. If the argument types don't match exactly, the dispatcher tries to find functions taking base class pointers/references. Here is a complete example:
Code: [Select]
// For this code, you needn't compile or link Thor, the dispatchers are a header-only feature
#define THOR_STATIC

#include <Thor/Tools/DoubleDispatcher.hpp>
#include <iostream>

// Example class hierarchy
class Object { public: virtual ~Object() {} };
class Asteroid : public Object {};
class Ship     : public Object {};
class Missile  : public Object {};

// Functions for collision with different argument types
void Collision(Asteroid*, Asteroid*)    { std::cout << "Asteroid-Asteroid\n"; }
void Collision(Asteroid*, Ship*)        { std::cout << "Asteroid-Ship\n";     }
void Collision(Ship*,     Ship*)        { std::cout << "Ship-Ship\n";         }
void Collision(Object*,   Object*)      { std::cout << "Other objects\n";     }

int main()
{
    // Register class hierarchy (required to know derived-base relations at runtime)
    THOR_RTTI_BASE(Object)
        THOR_RTTI_DERIVED(Asteroid)
        THOR_RTTI_DERIVED(Ship)
        THOR_RTTI_DERIVED(Missile);

    // Create dispatcher and register functions
    thor::DoubleDispatcher<Object*> dispatcher(true, true);
    dispatcher.Register<Asteroid, Asteroid>(&Collision);
    dispatcher.Register<Asteroid, Ship>    (&Collision);
    dispatcher.Register<Ship,     Ship>    (&Collision);
    dispatcher.Register<Object,   Object>  (&Collision);

    // Base class pointers (no static type information about derived classes)
    Object* a = new Asteroid;
    Object* s = new Ship;
    Object* m = new Missile;

    // Invoke functions, let dispatcher choose the correct overload
    dispatcher.Call(a, s); // Output: "Asteroid-Ship"
    dispatcher.Call(a, a); // Output: "Asteroid-Asteroid"
    dispatcher.Call(s, s); // Output: "Ship-Ship"
    dispatcher.Call(a, m); // Output: "Other objects"
   
    delete m;
    delete s;
    delete a;
}

I have also updated the Events module according to SFML's new input system. Next, I am probably going to set Animation progresses to [0,1], and maybe to use std::tr1::shared_ptr for resources.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Haikarainen

  • Guest
Thor C++ Library – An SFML extension
« Reply #117 on: July 11, 2011, 08:23:54 pm »
Hey nexus, im currently rewriting an old lost animationsystem,  and i wonder can your timers be used to accurately check how many ms has past since last timer reset?  It's for frames playtime, and im wondering if a playtime at 10ms per frame would get choppy orsomething?

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6287
  • Thor Developer
    • View Profile
    • Bromeon
Thor C++ Library – An SFML extension
« Reply #118 on: July 11, 2011, 09:40:41 pm »
The classes in the Time module provide the same precision as the underlying sf::Clock, so milliseconds should work.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Haikarainen

  • Guest
Thor C++ Library – An SFML extension
« Reply #119 on: July 11, 2011, 11:00:52 pm »
Quote from: "Nexus"
The classes in the Time module provide the same precision as the underlying sf::Clock, so milliseconds should work.


Yep, they work perfectly :) Thanks alot! the Thor-lib is totally awesome :D