-
[Ouvert de nouveau a cause de l'échange de forum]
Thor 2.0
Entretemps, j'ai fini d'adapter la convention de nommage et de changer quelques autres choses (liste détaillé (http://www.bromeon.ch)). En deux mots, j'utilise maintenant GitHub a j'ai délocalisé une partie de Thor dans une bibliothèque autonome (http://fr.sfml-dev.org/forums/index.php?topic=7372.0).
Maintenant je peux commencer à améliorer des parties différentes de la bibliothèque Thor. Pour séparer mieux du development de Thor 1, j'ai ouvert un nouveau thread. Ici, je vous informe régulièrement des nouvelles. Si vous avez des suggestions, discutez les ici s'il vous plaît :)
Links
Page web du projet Thor (http://www.bromeon.ch/libraries/thor/index.html)
GitHub (https://github.com/Bromeon/Thor)
-
Recémment, j'ai changé l'API des modules Particles et Resources un peu.
Particles
Il y a maintenant thor::UniversalEmitter qui remplace les autres emitters. Il est capable de definir les valeurs initiales d'une particule par un constant ou une fonction.
thor::UniversalEmitter::Ptr emitter = thor::UniversalEmitter::create();
emitter->setEmissionRate( 20 );
emitter->setColor( sf::Color::Red );
emitter->setLifetime( sf::seconds(4) );
// Positionner les particules dans un cercle
emitter->setPosition( thor::Distributions::circle(center, radius) );
// Tourner avec un angle aléatoire
emitter->setRotation( thor::Distributions::uniform(0.f, 360) );
Resources
J'ai implementé des nouvelles clés de resource et remplacé thor::ResourcePtr par std::shared_ptr.
thor::ResourceManager<sf::Texture> mgr;
thor::ResourceKey<sf::Texture> key = thor::Resources::fromFile<sf::Texture>("image.png");
std::shared_ptr<sf::Texture> ptr = mgr.acquire(key);
// ou directement
std::shared_ptr<sf::Texture> ptr =
mgr.acquire( thor::Resources::fromFile<sf::Texture>("image.png") );
En outre, j'utilise maintenant C++11 pour Thor.
-
En outre, j'utilise maintenant C++11 pour Thor.
Donc, faut mettre à jour le compilateur??? Ou une vielle version de GCC suffit???
Il peut être plus simple et naturelle de faire :
thor::ResourceManager::aquire(std::string &str)
Cela simplifie le thor::Resources::fromFile.
-
Donc, faut mettre à jour le compilateur??? Ou une vielle version de GCC suffit???
Oui, je pense qu'il faut avoir g++ 4.6. Maintenant, une plus vieille version suffit, mais quand j'introduis nullptr, les versions avant 4.6 ne sont plus compatibles.
Il peut être plus simple et naturelle de faire :
thor::ResourceManager::aquire(std::string &str)
Oui, mais je veux sèparer l'API de ResourceManager et des fonctions qui chargent la resource. En plus, c'est pas évident ce qu'un std::string veut dire, car sf::Shader par exemple utilise aussi des strings pour être construit, mais pas d'un fichier.
Mais si c'est trop compliqué, on peut écrire une fonction libre:
template <typename T>
std::shared_ptr<T> acquireFromFile(
thor::ResourceManager<T>& mgr, const std::string& filename)
{
return mgr.acquire( thor::Resources::fromFile<T>(filename) );
}
-
Salut
je regarde le tuto sur les actions:
thor::Action both = a && b;Pourquoi tu overload les && et les || au lieu de & et de | ? J'aurais plutot pensé faire :
thor::Action both = a & b;
-
Parce que les operateurs de thor::Action se comportent comme les operateurs logiques, pas comme les operateurs des bits.
L'action a && b est active quand a est active et b est active
L'action a || b est active quand a est active ou b est active
-
Ben euh c'est pareil avec les operateurs sur les bits non?
En fait je suis habitué à avoir && et || qui "renvoient" un booléen, et & et | qui renvoient un objet du même type que les arguments. Vu que toi ça fait le 2eme cas, je pensais que c'était plus logique d'utiliser les opérateurs de bits.
Enfin bon c'est pas important
-
Des nouvelles:
Il y a thor::MultiResourceCache qui peut s'occuper de plusieures types de resource. Cela veut dire qu'il ne faut plus avoir des différentes managers, un pour chaque resource (mais c'est encore possible avec thor::ResourceCache):
thor::MultiResourceCache cache;
cache.acquire( thor::Resources::fromFile<sf::Image>(...) );
cache.acquire( thor::Resources::fromFile<sf::SoundBuffer>(...) );
J'ai implementé la nouvelle API des animations. Au lieu de l'héritage et des std::shared_ptr, il y a maintenant des functors. thor::Animator est devenu un template pour permettre des IDs et des objets animés definis par l'utilisateur. Par exemple, on peut animer sf::Text et utiliser des enums au lieu des strings:
thor::Animator<sf::Text, MyEnum> animator;
La classe thor::Animation a été enlevé, maintenant tout ce qui a un operator() avec une telle signature est considéré comme animation:
void operator() (Animated& animated, float progress) const;
Cela inclut les fonctions normales et les expressions lambda, par exemple c'est possible de definir une animation reverse qui renverse une autre animation anim en utilisant une seule ligne:
auto reverse = [anim] (sf::Sprite& s, float pr) { return anim(s, 1.f - pr); };
Et l'ancien code
thor::FrameAnimation::Ptr explosion = thor::FrameAnimation::create();
explosion.addFrame(1.f, sf::IntRect(...));
explosion.addFrame(1.5f, sf::IntRect(...));
thor::Animator animator;
animator.addAnimation("expl", explosion, sf::seconds(3));
est changé à
thor::FrameAnimation explosion;
explosion.addFrame(1.f, sf::IntRect(...));
explosion.addFrame(1.5f, sf::IntRect(...));
thor::Animator<sf::Sprite, std::string> animator;
animator.addAnimation("expl", explosion, sf::seconds(3));
Le module est encore assez petit, je projètte d'implementer plus des animations (e.g. des gradients de couleur) et des primitives (renverser, concaténer).
-
Salut !
Je me permets un très léger apport pour ton projet^^
En cherchant à améliorer mon implémentation de FOR_EACH, je suis tombé sur ta version qui m'a aiguillé sur un truc plus simple que ma première version, ce qui m'a amené à une nouvelle version encore plus robuste. Du coup, juste retour des choses, voici mon résultat (vu qu'il me semble que Thor utilise c++11) :
#define FOR_EACH(CONTAINER, ITERATOR) \
for (auto ITERATOR = CONTAINER.begin(); ITERATOR != CONTAINER.end(); ++ITERATOR)
#define FOR_EACH_CONST(CONTAINER, ITERATOR) \
for (auto ITERATOR = CONTAINER.cbegin(); ITERATOR != CONTAINER.cend(); ++ITERATOR)
L’intérêt par rapport à ta version est de virer un paramètre (le type de conteneur), ainsi que d'éviter un crash si le contenu de la boucle erase des elements (en ne stockant pas le end()).
genre :
std::vector<std::string> vecTest;
vecTest.push_back("A");
vecTest.push_back("B");
vecTest.push_back("C");
FOR_EACH(vecTest, iteCurrent)
{
if ("B" == *iteCurrent)
iteCurrent = vecTest.erase(iteCurrent);
}
En attendant le "vrai" ForEach de C++11 ;D
-
Du coup, juste retour des choses, voici mon résultat (vu qu'il me semble que Thor utilise c++11) :
#define FOR_EACH(CONTAINER, ITERATOR) \
for (auto ITERATOR = CONTAINER.begin(); ITERATOR != CONTAINER.end(); ++ITERATOR)
#define FOR_EACH_CONST(CONTAINER, ITERATOR) \
for (auto ITERATOR = CONTAINER.cbegin(); ITERATOR != CONTAINER.cend(); ++ITERATOR)
Merci beaucoup. J'en ai déjà pensé, mais je l'ai oublié parce que je me concentrais toujours sur Thor (pas Aurora). Une fois j'ai même réfléchi si j'offre un AURORA_FOREACH comme BOOST_FOREACH (avec C++11, c'est plus simple à implémenter). Ca veut dire :
std::vector<int> v;
AURORA_FOREACH(int& i, v)
++i;
C'était aussi la raison pourquoi les deux autres macros contiennent "_ITR". Mais l'execution de AURORA_FOREACH est toujours un peu plus lent que AURORA_ITR_FOREACH (particulièrement si on traite break et continue), à cause de ça je veux garder le dernier.
Je projète de modifier ton code un peu: Sauvegarder le resultat de end(), parce que c'est possible que CONTAINER est une expression chère à évaluer. Peut-être même sauvegarder CONTAINER (sinon il y a toujours deux evaluations).
À propos, car ça concerne plutôt Aurora, il y a aussi un autre thread (http://fr.sfml-dev.org/forums/index.php?topic=7372.0) ;)
-
Je projète de modifier ton code un peu: Sauvegarder le resultat de end(), parce que c'est possible que CONTAINER est une expression chère à évaluer. Peut-être même sauvegarder CONTAINER (sinon il y a toujours deux evaluations).
Le soucis si tu fais ça, comme j'essayais de l'expliquer, c'est que si tu modifies le contenu de ton CONTAINER à l'interieur de la boucle, t'auras des soucis (le end() que t'as stocké se retrouve invalidé). Solution possible : split FOR_EACH_SAFE + FOR_EACH_FAST :D
Par contre je comprends pas trop le but de stocker CONTAINER qqpart, c'est pas comme si c’était un pointeur vers qqchose (vu que c'est le container lui même).
À propos, car ça concerne plutôt Aurora, il y a aussi un autre thread (http://fr.sfml-dev.org/forums/index.php?topic=7372.0) ;)
J'y penserais pour les prochaines fois :p
-
Le soucis si tu fais ça, comme j'essayais de l'expliquer, c'est que si tu modifies le contenu de ton CONTAINER à l'interieur de la boucle, t'auras des soucis (le end() que t'as stocké se retrouve invalidé).
Excuse-moi, je l'ai pas vu. Oui, c'est vrai, mais en utilisant la sémantique "for each", on veut normalement juste faire quelque chose pour chaque élément.
Quand on efface des éléments, on a plutot une boucle comme celle-là:
for (auto itr = container.begin(); itr != container.end(); /* fais rien */)
{
if (/* besoin d'effacer */)
itr = container.erase(itr);
else
++itr;
}
-
Effectivement.
Bah, au final j'essayais de trouver un compromis qui marche pour toutes les utilisations possibles, justement pour ne plus avoir à retaper les déclarations de boucle, mais c'est peut être un peu illusoire de ma part^^
A moins de faire encore plus de sous-versions du même define... :P
-
Les modifications les plus importantes au mois de juillet:
- Ajouté un module FindThor pour CMake (grace à nokurn).
- Enlevé Animator::setDefaultAnimation(). L'interface devient plus simple sans perte de fonctionnalité.
- Partagé le module Multimedia en deux nouveaux modules Graphics et Shapes.
- Dessiné une meilleure texture pour l'exemple Animation et utilisé une animation plus complexe.
Pour la fête nationale de Suisse, j'ai développé un nouvel exemple des feux d'artifices aujourd'hui. Il montre comment à écrire des emitters et des affectors spécifiques, et les combine avec des autres parties comme thor::CallbackTimer ou thor::PolarVector2f.
-
Salut!
Je viens de découvrir Thor et donc j'ai voulu tester la version 2.0.
Cependant lorsque je lance mingw32-make install j'obtiens des erreurs, j'ai fais plusieurs recherches mais impossible de trouver une solution :
http://nsa29.casimages.com/img/2012/08/03/120803125608296808.png (http://nsa29.casimages.com/img/2012/08/03/120803125608296808.png)
Merci pour l'aide !
-
Tu dois utiliser (compiler) les dernières sources de SFML, il y a eu quelques modifications depuis la release candidate.
-
D'accord, je prenais les binaires de la rc. Je vais tester avec la version git.
Edit: Merci Laurent, tout fonctionne, reste plus qu'a compiler un petit programme ;)
-
Bonjour :)
Je suis en train de créer mes actions Thor, mais je ne vois pas comment faire pour créer une action qui se déclenche quand la molette de la souris tourne vers le haut uniquement (ou vers le bas).
// Action de zoomIn
mActionMap["zoomIn"] = thor::Action(sf::Event::MouseWheelMoved) && ???;
J'utilise actuellement Thor 176bef9 (https://github.com/Bromeon/Thor/commit/176bef9444feb8e281a71bce6a2b5a933af2d039) avec la SFML bdfc2dc (https://github.com/SFML/SFML/commit/bdfc2dc3f538605d5e9d7a09a04f87b2a02d2b3f), mais ça n'a pas d'importance je crois.
PS: Pour ce que j'en ai vu jusqu'ici, Thor est génial !!
EDIT :
Aussi, ce qui pourrait être cool c'est d'avoir thor::Action::None. Exemple :
// Clic gauche mais pas la touche C
mActionMap["fire"] = thor::Action(sf::Mouse::Left, thor::Action::Hold)
&& thor::Action(sf::Keyboard::C, thor::Action::None);
-
Salut :)
Je suis en train de créer mes actions Thor, mais je ne vois pas comment faire pour créer une action qui se déclenche quand la molette de la souris tourne vers le haut uniquement (ou vers le bas).
Maintenant, il n'y a pas d'action directe pour tourner la molette, il faut enregistrer sf::Event::MouseWheelMoved et regarder le delta dans la fonction callback:
void OnWheelMove(thor::ActionContext<X> context)
{
int d = context.event->mouseWheel.delta;
// ..
}
Mais peut-être c'est mieux de permettre cela directement. En tout cas, je dois encore penser du système des événements (aussi si les callbacks peuvent être simplifiés).
Aussi, ce qui pourrait être cool c'est d'avoir thor::Action::None.
Cette fonctionnalité est déjà projetée (http://www.bromeon.ch/libraries/thor/progress.html), mais je vais implementer operator! qui est consistent avec les opérateurs logiques && et ||.
-
Des nouvelles: J'ai combiné les affecteurs particule avec les animations. Les modifications:
- Ajouté les classes FadeAnimation et ColorAnimation.
- Ajouté la classe AnimationAffector qui prend une animation pour animer des particules.
- Enlevé les classes FadeInAffector, FadeOutAffector et ColorAffector.
Maintenant c'est possible d'écrire une animation une seule fois pour thor::Particle, sf::Sprite, sf::Text, sf::Shape ou même des autres classes.
-
Thor intègre t'il un gestionnaire de maps ?
-
Tu parles des tilemaps? Non, il n'y en a rien au moment.