Messages

1

SFML projects / Thor C++ Library – An SFML extension

« on: July 06, 2011, 02:24:16 am »

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.

2

SFML projects / Thor C++ Library – An SFML extension

« 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.

3

SFML projects / Thor C++ Library – An SFML extension

« on: July 05, 2011, 08:48:03 pm »

I never really looked at the code for it, and I may have confused it with another library which I took a closer look at. But yes, the idea is that you can set a starting and end position and it will give you an interpolation between 0 and 1. The simplest example is linear, where 0 equals the starting position and 1 equals the ending position, and anything in between is just an even subdivision. More useful are the other types though, which allow you to have movement that starts out fast and slows down as it gets closer to its target. Then you have ease in and ease out, which allow you to start slowly and speed up or start fast and slow down, or start and end slowly.

Basically it's useful when you don't want to snap directly to a target but move there smoothly. It's a bit hard for me to describe properly, but maybe this video makes more sense:

If you look at the time I've linked to, when the desktop is zooming out it speeds up near the middle and slows down right before it reaches its target. It would look bad if it was just a linear scaling effect, but since it uses tweening it looks 'smooth'.

Anyway, that's an example of how you can apply an effect to a sprite, but it's also useful for fading text and moving views, and things like that. That's why I suggested making it more generic to accept any sort of variable.

Again, if you don't think it's something that would fit into Thor, don't worry about it--I'll probably try to make my own version. I most likely release it, too.

4

SFML projects / Thor C++ Library – An SFML extension

« on: July 05, 2011, 01:48:07 am »

Yes, you're right. The container's progress should be measured in a float between 0 and 1, so that you don't have to deal with time at all. I think having the two methods "Update" and "SetStep" are good though, as that way some people can set the value manually, and others can attach it to existing timers.

It gets rid of having to scale the timestep within the class as well, instead it can be handled by the user like this: Update((float)dt * 0.25f) or whatever.

5

SFML projects / Thor C++ Library – An SFML extension

« on: July 05, 2011, 01:21:35 am »

Sounds good. cpptweener's method, which basically involves references to variables, seems somehow unsafe. Also, it uncouples the variable from the tweener, which is nice if you need to tween multiple things with one tweener, but not so good for making quick tweens as it involves at least two variables to juggle. However, it's likely a great source for the math behind nonlinear tweens--it can get a little heady at times, at least for me.

I think having a wrapper with an operator() or somesuch to get the contained type would be a neater way to do it properly. Calling it "Range<contained>" might work nicely. I imagine something like this:

Code: [Select]

template <typename T>
class Range
{
    public:
        const T& operator()() // could also be GetValue() or somesuch
        {
            return mType;
        }

        void Update(float percentage);
        void SetStep(float step);

    private:
        T mType;
        float mStep;
};

I imagine you can derive different types of tweens from that, like LinearRange, CubicRange etc. Alternatively you can have an enum for range types, but I think this way is better.

EDIT: Changed to floats for timestep

6

SFML projects / Thor C++ Library – An SFML extension

« on: July 05, 2011, 12:33:58 am »

I was thinking about this very recently, and how it might be useful to me. Basically, what would be great to have is a tweener system, that interpolates any float variables. I'm not sure exactly how this could be done, but perhaps if you wrap a small struct around a variable such as a float or Vector2f (sort of like a smart pointer does) and then use that, it might work very well. This would support animations that involve movement, fading, zooming, and really anything you can think of, since it's generic enough to apply to anything.

Where this sort of thing gets very powerful is in interpolation types--adding in support for linear, cubic, 'bouncy' (overshooting), and other stuff. This would be useful for a huge amount of purposes--title screen animations, fading sprites in and out, particle affectors, even cameras (zoomy cameras look nicer--I'm using a homemade one myself but it's a lot of messiness to manage)

There are tweening libraries out there, for example http://code.google.com/p/cpptweener/ . If you think making a tweener is out of the scope of Thor, I'll probably end up using that instead--but having it integrated into particles and things would be very nice indeed.

7

SFML projects / Thor C++ Library – An SFML extension

« on: July 04, 2011, 03:22:37 am »

Scale affector is really trivial (Nexus, please excuse me for not obeying your naming style):

Header

Code: [Select]

#include <Thor/Particles.hpp>

class ScaleAffector : public thor::Affector
{
  public:
    typedef std::tr1::shared_ptr<ScaleAffector> Ptr;

  public:
    static Ptr Create(sf::Vector2f scaleFactor);

  public:
    explicit ScaleAffector(sf::Vector2f scaleFactor);

    virtual void Affect(thor::Particle& particle, float dt);

    void SetScaleFactor(sf::Vector2f scaleFactor);

    sf::Vector2f GetScaleFactor() const;

  private:
    sf::Vector2f m_scale_factor;
};


Source

Code: [Select]

#include "affectors.hpp"

ScaleAffector::Ptr ScaleAffector::Create(sf::Vector2f scaleFactor)
{
  return Ptr( new ScaleAffector(scaleFactor) );
}

ScaleAffector::ScaleAffector(sf::Vector2f scaleFactor)
: m_scale_factor(scaleFactor)
{
}

void ScaleAffector::Affect(thor::Particle& particle, float dt)
{
  particle.Scale += dt * m_scale_factor;
}

void ScaleAffector::SetScaleFactor(sf::Vector2f scaleFactor)
{
  m_scale_factor = scaleFactor;
}

sf::Vector2f ScaleAffector::GetScaleFactor() const
{
  return m_scale_factor;
}

No, there's no way to iterate through all the particles. I think a better way for you to do what you want would be to make a physics affector that checks the particle's position in Affect and does any physics calculations there. It should be very simple with a format similar to the code above. You can see the properties of a particle that you can modify here

8

SFML projects / Thor C++ Library – An SFML extension

« on: July 04, 2011, 02:04:14 am »

I'd like to mention that the particle system is really great for me. I wrote a new affector that just scales the image every step (I'd like to suggest that's included in thor by default actually, as it's sort of the only obvious thing missing from the particles package). Here's an example of it in action with a nice particle texture I made:

9

SFML projects / Thor C++ Library – An SFML extension

« on: July 01, 2011, 06:59:45 am »

Did you clean the entire project and rebuild? If it helps you, Nexus, particles are working properly for me with somewhat similar code. I know I had a crashing problem earlier where a rebuild solved it.

10

SFML projects / Thor C++ Library – An SFML extension

« on: June 30, 2011, 12:17:38 am »

Right... now that it's integrated with SFML that works! Excellent.

11

SFML projects / Thor C++ Library – An SFML extension

« on: June 29, 2011, 10:52:02 pm »

Yep, it works nicely for me. The use of pointers is also good as it removes the burden of declaring a const reference and removes the possibility of making an accidental copy.

It's great. One last question: Is there a way to integrate mouse movement? Right now the only thing left in my onEvent function deals with MouseMove events. I may have missed something but I don't see a way to create an action that only involves mouse movement (mousebuttonpressed hooked with realtime would work for when a button is pressed, but not without a press).

I really can't thank you enough for the work you've done so far. This is far easier than trying to set up sigc++ or boost::signals to work with the engine (they work but don't integrate so well with SFML obviously). It also lets me have signals without an implementation that is too complex for what I need, and without having to include yet another library.

12

SFML projects / Thor C++ Library – An SFML extension

« on: June 29, 2011, 08:45:09 pm »

Probably transform the sf::Event vector to a single event. I think it is easier for the user if the callback is invoked multiple times (once for every sf::Event), so there is no need for a loop in every listener. Mostly, there is only one event per frame anyway.

This sounds good. Having a vector of events seemed a bit clunky to me as well, given that one big reason for using events is to remove loop-like behavior.

13

SFML projects / Thor C++ Library – An SFML extension

« on: June 29, 2011, 06:19:02 pm »

Action::Once sounds like a good solution.

Mixing PressOnce with Realtime could be slightly useful in that it would allow me to initialize a state and then poll it (so PressOnce would call the function once, to set up initial values like the first mouse position in a drag, then Realtime would call every frame to update something, and then perhaps ReleaseOnce would call to clean up or finalize a value).

However, this probably is better done in separate functions anyway, so mixing the two is not a big issue for me.

One thing I'd like to add is that it wasn't immediately obvious to me at least that using a Realtime event would not produce an event in the context.Events vector. So I was polling the event and it was segfaulting. Perhaps mentioning this in the documentation would be helpful to some people who are trying to understand the system.

Thanks!

14

SFML projects / Thor C++ Library – An SFML extension

« on: June 29, 2011, 04:40:35 am »

So far it's been a great help (and I imagine it'll get better once I use events that involve special data such as text input and mouse position).

One request I would make is an ActionIdentifier that works for both Presses and Releases (shouldn't it be relatively easy to do with an old-style bitwise filtering system?). That way I can set up a connection that will call on both press and release (for example for setting movement). Then inside the callback I can check if it's a press or release in a switch statement.

For now I can do:

Code: [Select]

Action(sf::Key::A, Action::PressOnce) || Action(sf::Key::A, Action::ReleaseOnce)
 in the Connect statement, which is perhaps good enough, but a little clunky. Ideally I'd be able to do something like

Code: [Select]

Action(sf::Key::A, Action::PressOnce | Action::ReleaseOnce)

Thanks again for the work you've been doing on this--it's proven invaluable for this project.

15

SFML projects / Thor C++ Library – An SFML extension

« on: June 27, 2011, 12:47:23 pm »

You're right, a reference to sf::Input should simplify that scenario a bit.

Thanks for the quick response, and I certainly understand the difficulty in getting ActionSystem to pass events properly.

For now though, it's very nice to be able to set up all the callbacks and actions in one place with ActionMap. I think this will make control preferences much easier as well, since I can probably pass some config file's values to the ActionMap (no more fiddling with switch statements!)