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

Author Topic: Thor 2.0 released!  (Read 341824 times)

0 Members and 2 Guests are viewing this topic.

vgambit

  • Newbie
  • *
  • Posts: 5
    • View Profile
Re: Thor 2.0
« Reply #225 on: July 24, 2013, 04:25:28 am »
Does Thor 2 work with SFML 2.0.0 or do I have to use the latest version from Git?

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10801
    • View Profile
    • development blog
    • Email
Re: Thor 2.0
« Reply #226 on: July 24, 2013, 12:10:27 pm »
Since there are only bug-fixes and certainly not API change between SFML 2.0 and the latest Git version, Thor 2.0 does work with SFML 2 itself.
If you're on Windows you could also take a look at my Nightly Builds. ;)
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: Thor 2.0
« Reply #227 on: July 24, 2013, 01:31:34 pm »
Thanks for the feedback, it's really appreciated!

It's nice that the functionality of several callback systems is there, it could get useful in a real app, like letting different menus, game modes, etc. have different callback systems but using same action map
That's a good example. Even if the callback systems are not used concurrently, one can switch between them.

A few years back, I used boost::program_options and I liked the way you can set it up [...] Maybe something similar could be done (for the connect part) ?
Interesting idea, but I'm not sure if the flexibility the operator() provides is needed for callback registrations -- these are all (key, function) pairs. I had such an API for the old color gradients, where you could specify an arbitrary amount of colors, but now I replaced it with something more expressive...
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

FRex

  • Hero Member
  • *****
  • Posts: 1845
  • Back to C++ gamedev with SFML in May 2023
    • View Profile
    • Email
Re: Thor 2.0
« Reply #228 on: July 24, 2013, 02:55:22 pm »
Boost API is sometimes quite WTF-inducing, chaining operator () or % for doing something very different than usual meaning of them.
Back to C++ gamedev with SFML in May 2023

Sonkun

  • Full Member
  • ***
  • Posts: 241
    • View Profile
Re: Thor 2.0
« Reply #229 on: August 10, 2013, 05:10:05 am »
That's not a big deal but I noticed an unnecessary line in the StopWatch implementation. Line 74, it should work without the clock restart.

mClock.restart();
Interested in using SFML with Python ? Try out its Python binding!

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: Thor 2.0
« Reply #230 on: August 10, 2013, 11:55:44 am »
Indeed, thank you! :)
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
[Thor] Vector projection + example
« Reply #231 on: August 11, 2013, 03:42:03 pm »
I added the function thor::projectedVector() which returns the projection of a vector onto an other.

Additionally I wrote an example for the Vectors module, which shows some of the vector algebra functions in action: length(), signedAngle(), unitVector(), perpendicularVector(), rotatedVector() and projectedVector(). The class thor::Arrow is used to visualize the vectors.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Silvah

  • Guest
Re: Thor 2.0
« Reply #232 on: August 17, 2013, 07:20:19 pm »
I found a while to rewrite it to make use of makepkg git support, so the AUR package is maintained again.

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: Thor 2.0
« Reply #233 on: August 17, 2013, 09:03:06 pm »
Okay, good to know! Thanks!
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

FRex

  • Hero Member
  • *****
  • Posts: 1845
  • Back to C++ gamedev with SFML in May 2023
    • View Profile
    • Email
Re: Thor 2.0
« Reply #234 on: August 21, 2013, 11:54:38 pm »
I just noticed that stop watch reset and restart don't return elapsed time like clock does. Is that on purpose or oversight from time when clock didn't return time on restart too?
Back to C++ gamedev with SFML in May 2023

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: Thor 2.0
« Reply #235 on: August 22, 2013, 12:56:00 am »
It's not only restart() and reset(); the member functions start() and stop() would have to return the elapsed time for consistency, too. In contrast to sf::Clock, the classes thor::StopWatch, thor::Timer and thor::CallbackTimer have many attributes (not just the time), so it is not immediately clear what the return type represents. Especially for timers, it may not be obvious that the returned value would be the remaining and not the elapsed time. That's why I prefer the explicit getters -- in most classes, modifiers and getters are separated anyway.

This might change in the future, but by keeping void for the moment, I'm not going to break any code, in case I should once find a more appropriate return type than the elapsed time.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Kojay

  • Full Member
  • ***
  • Posts: 104
    • View Profile
Re: Thor 2.0
« Reply #236 on: August 31, 2013, 07:01:19 pm »
Is it necessary that thor::ParticleSystem be initialized with a sf::Texture, which in turn must have already been loaded? I find it impossible to have a system as member of a class without allocating it on the heap.

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: Thor 2.0
« Reply #237 on: September 01, 2013, 01:27:01 am »
It's not strictly necessary -- I did it for the sake of class invariants.

However, as soon as I allow multiple textures or texture rects in a particle system, it will be possible to specify the texture later. I have planned to implement this feature, in order to allow variations of particles with a clear shape, such as debris.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Lee R

  • Jr. Member
  • **
  • Posts: 86
    • View Profile
Re: [Thor] Vector projection + example
« Reply #238 on: September 01, 2013, 10:30:40 pm »
I added the function thor::projectedVector() which returns the projection of a vector onto an other

You can get rid of the normalization step using the following definition (where a1 is the projection of a onto b):


template <typename T>
sf::Vector2<T> projectedVector(const sf::Vector2<T>& vector, const sf::Vector2<T>& axis)
{
    assert(axis != sf::Vector2<T>());
    return dotProduct(vector, axis) / squaredLength(axis) * axis;
}

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
[Thor] Multiple particle variants
« Reply #239 on: September 02, 2013, 11:39:13 am »
However, as soon as I allow multiple textures or texture rects in a particle system, it will be possible to specify the texture later.
Done. It is now possible specify different variants of a particle by using multiple texture rects:
thor::ParticleSystem system;
system.setTexture(texture);
system.addTextureRect(rect1);
system.addTextureRect(rect2);

As you see, the texture is specified later. If addTextureRect() is not called, the whole texture will be used. The particle class has a new member variable textureIndex that specifies which texture rect is used:
thor::Particle particle(...);
particle.textureIndex = 1; // use rect2

I also optimized the particle system a bit, such that it's not necessary to completely recompute 4 vertices from the texture rect for every particle every time.


You can get rid of the normalization step using the following definition (where a1 is the projection of a onto b)
Done. Thank you very much for the hint! :)
« Last Edit: September 02, 2013, 11:41:06 am by Nexus »
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

 

anything