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

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

0 Members and 1 Guest are viewing this topic.

devilswin

  • Newbie
  • *
  • Posts: 38
    • View Profile
    • Email
Re: Thor 2.0
« Reply #390 on: March 03, 2015, 09:54:12 pm »
So i compiled the SFML 2.2, now i tried compiling the Thor files, however only debug was made and i cannot seem to  be able to use it on QT project, as that is my preferred IDE...

Jesper Juhl

  • Hero Member
  • *****
  • Posts: 1405
    • View Profile
    • Email
Re: Thor 2.0
« Reply #391 on: March 03, 2015, 10:54:11 pm »
Thor can be build as both debug and release (optimized) - I know that for a fact since I do it regularly myself.

This does the trick for me :
mkdir build && cd build && cmake -DCMAKE_BUILD_TYPE=Release .. && sudo make -j8 install

devilswin

  • Newbie
  • *
  • Posts: 38
    • View Profile
    • Email
Re: Thor 2.0
« Reply #392 on: March 04, 2015, 02:21:22 pm »
Well, it still has yet to work, so i think i will wait until i boot camp my macbook to begin using thor(the nightly builds make it SO much easiar)

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
[Thor] Resources revisited
« Reply #393 on: March 25, 2015, 08:45:17 pm »
Resources revisited

thor::ResourceCache is a very sophisticated resource manager: it detects when the user wants to load a resource twice and tracks lifetime of all resources as well as itself using shared_ptr and weak_ptr. It allows for different strategies regarding error handling (null pointer or exception) as well as resource release (automatic or explicit).

On the other side, this comes with certain complexity. Due to the lack of an alternative resource system in Thor, many people have seen ResourceCache as a general-purpose resource manager, which it is definitely not. A very common use case in games consists of loading resources initially and using them while the game is running. For these cases, not a lot of functionality is needed. A simple class like the one discussed in our book already does the job pretty well.

Over the years, I have spent considerable thought into resource managing systems, and it's something I find rather difficult to get right, especially when you want to cover lots of different needs. I have also not come across many generic solutions so far (as it is often the case with game-related functionality: most people write code specific to their own needs). I originally planned to add another class in addition to the existing ResourceCache -- this was mainly due to my assumption that because of apparently very different semantics, it would be very hard to combine both. Yesterday, I recognized that the main difference is the ownership, other than that there are many commonalities. Therefore, ResourceCache will cease to exist in its current form and make room for a better approach.

The class template ResourceHolder is an attempt to provide a more flexible and simpler way of handling resources. Resources can be addressed by user-defined IDs. The basic use case looks as follows:
namespace res = thor::Resources;
enum struct TextureType { Grass, Rock };

// Loading
thor::ResourceHolder<sf::Texture, TextureType> textures;
textures.acquire(TextureType::Grass, res::fromFile<sf::Texture>("grass.png"));
textures.acquire(TextureType::Rock, res::fromFile<sf::Texture>("rock.png"));

// Usage
sf::Sprite sprite;
sprite.setTexture(textures[TextureType::Grass]);

Easy, eh? In the basic case, we just have centralized ownership semantics: the ResourceHolder object stores everything, and people can get references to the resources using operator[]. Now to the flexibility part: it is also possible to have shared-ownership semantics as before with ResourceCache. In this case, a reference counter makes sure that the last user cleans up. This implies that there is at least one shared pointer referring to the resource at any time. A third template argument specifies the ownership model, in this case RefCounted.
// Loading and storing in shared pointers
thor::ResourceHolder<sf::Texture, TextureType, res::RefCounted> textures;
std::shared_ptr<sf::Texture> grass = textures.acquire(TextureType::Grass, ...);
std::shared_ptr<sf::Texture> rock = textures.acquire(TextureType::Rock, ...);

// Later, get another shared pointer, either by copying existing one or directly from holder
std::shared_ptr<sf::Texture> rock2 = rock;
std::shared_ptr<sf::Texture> rock3 = textures[TextureType::Rock];

// Now rock, rock2 and rock3 point to the same resource.
// As soon as all of them go out of scope, the resource is released.

// Keep shared pointer alive while in use
sprite.setTexture(*rock2);

The basic functionality is there, I need to perform some further tests and design some special cases. There are also some interesting features one could still add:
  • If user provides no ID, infer it from the way resources are loaded
  • Store loader initially, load only on first access
  • More ownership models
  • ...
« Last Edit: March 25, 2015, 08:47:56 pm by Nexus »
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Jesper Juhl

  • Hero Member
  • *****
  • Posts: 1405
    • View Profile
    • Email
Re: Thor 2.0
« Reply #394 on: March 25, 2015, 10:53:45 pm »
@Nexus : cool stuff.  Thor is my favorite SFML add-on library and it just keeps getting better.
Keep up the fantastic work you are doing - it's really excellent!

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: Thor 2.0
« Reply #395 on: March 26, 2015, 05:30:36 pm »
Thank you for the nice feedback! :)

A first version has now been pushed, the documentation and the new tutorial are meanwhile also online. The latter should give you a good overview about the API's capabilities, feel free to have a look!

Recent changes:
  • I implemented tracking for RefCounted again, so a resource removes itself automatically from the ResourceHolder when it's destroyed. The corresponding implementation is rather complicated, but fortunately transparent to the user.
  • I added thor::ResourceAccessException which will be thrown when an invalid ID is accessed.
  • The enum thor::Resources::KnownIdStrategy can be used to determine what happens if an ID is already known.
« Last Edit: March 27, 2015, 12:19:39 am by Nexus »
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

DJuego

  • Jr. Member
  • **
  • Posts: 50
    • View Profile
Re: Thor 2.0
« Reply #396 on: March 29, 2015, 05:24:43 pm »
Hi! Nexus. Yes! Thank you for your amazing add-on for SFML.  :-*

Today i have tried to build the library with Mingw-Builds(i686-4.9.2-release-win32-sjlj-rt_v4-rev2.7z) from github(last commit: cf93e235233d3cf583babf7939f84f187d4ab546), and...

I get warnings...



and errors...



However There are no problems with Visual Studio 2013 ;D

PS: I am using SFML from github too (last commit: 20f213bfac713c5d98abf6afb6f893c318bc9fdd)

DJuego

« Last Edit: March 29, 2015, 11:59:32 pm by DJuego »

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10817
    • View Profile
    • development blog
    • Email
Re: Thor 2.0
« Reply #397 on: March 30, 2015, 11:48:29 am »
Doesn't work with SFML master since GLEW was removed. :D

Quote
SFML found but some of its dependencies are missing ( GLEW)
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 #398 on: March 30, 2015, 11:58:24 am »
I just asked myself! SFML is progressing too quickly :D
I'll fix the issues shortly, thanks for the reports :)

And I need to adapt the new FindSFML.cmake module, too...

[Edit] Fixed. There was a typename problem, and apparently only the most recent g++ versions support std::map::emplace(), which is pretty annoying. Now I used std::map::insert() instead, so some people with older compilers are still able to use Thor.
« Last Edit: March 30, 2015, 01:34:17 pm by Nexus »
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

DJuego

  • Jr. Member
  • **
  • Posts: 50
    • View Profile
Re: Thor 2.0
« Reply #399 on: March 30, 2015, 03:38:34 pm »
Yes!!  :D I confirm that Thor builds correctly now. Thank you for your very swift reaction, Nexus. (!)

Old gcc compiler? Well...

bash-3.1$ gcc --version
gcc.exe (i686-win32-sjlj-rev2, Built by MinGW-W64 project) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


It will be probably a specific problem with MinGW.  ::)

DJuego

« Last Edit: March 30, 2015, 06:00:07 pm by DJuego »

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10817
    • View Profile
    • development blog
    • Email
Re: Thor 2.0
« Reply #400 on: April 15, 2015, 11:54:41 pm »
While playing around with Thor I noticed that you always pass sf::Time as non-const value.
What exactly is the reasoning behind this? :)
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 #401 on: April 16, 2015, 12:05:41 am »
It wraps a sf::Uint64 value -- and I pass basic types by value, too ;)

I do the same with sf::Vector2f, by the way. Code is more readable, and performance is the same as pass-by-reference -- or even better, if the reference is not optimized away 8)
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10817
    • View Profile
    • development blog
    • Email
Re: Thor 2.0
« Reply #402 on: April 16, 2015, 12:51:58 am »
Right. Guess that makes sense then. Thanks for the explanation. :)
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 #403 on: May 12, 2015, 10:06:04 pm »
My plan is to release Thor 2.0 soon, the idea is that it will be compatible with SFML 2.3. For people not willing to build things on their own, this simplifies the process (rather than "use commit xy with commit yz").

There are still a few APIs I consider changing in the near future.
  • Split thor::Animator into a part that stores the raw animation data (as a kind of resource) and a part that animates entities using them. I don't really like the current design, which duplicates animations for every entity being animated. A new design however makes things a bit more complicated to use, I really have to find a good trade-off here.
  • Make thor::Particle more flexible. In particular, I wanted to allow the addition of custom attributes. I have already some ideas, but they'll require a few adaptions in the particle system's implementation.
  • I need to decide on an Aurora version. Aurora is still not in a stable version, and there are modules like Range whose existence I have questioned for some time. Ideal would have been a finished Aurora 1.0, but yes... ;)
I originally wanted to do all that before Thor 2.0, but that would take quite some time until it's ready. Considering that Thor has already undergone loads of changes (version 2.0 has now been in development for 3 years, and Thor in total almost half a decade!), I think it's reasonable to release a first version, even if the API will change a bit for 2.1.

In general, Thor 2 won't follow an extreme policy regarding backwards compatibility. During development, I have regularly encountered situations where something became just too unflexible, and instead of fixing things up with duct tape, I came up with new, better designs. Notable examples are particle emitters/affectors, resource handling or animation storage. From the feedback I've got, Thor users liked those changes, even though it meant adjusting a few lines of code in their applications :)

Any comments?
Are there things you deem important before Thor 2.0? Severe bugs or bad APIs?
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Jesper Juhl

  • Hero Member
  • *****
  • Posts: 1405
    • View Profile
    • Email
Re: Thor 2.0
« Reply #404 on: May 13, 2015, 07:15:15 pm »
For what its worth; I really like Thor 2.0 in the shape it is currently in.
I'm sure I could find some minor nits to complain about if I really went looking for them, but for the stuff I use the current state of things are just fine and work really well.

 

anything