Discussion :

[Gregoire31]

Bonjour à tous,
Suite aux conseils de certains sur ce forum j'ai commencé à utiliser la bibliothèque SFML (très intuitive ...) pour afficher notamment un cercle et l'animer en temps réel.
Ce que je souhaite faire maintenant c'est pouvoir animer justement ce cercle en fonction d'évènements exterieurs. (hors clavier / souris etc)
Est-ce que quelqu'un à déjà eu à faire ce genre de chose? Je n'arrive pas trop à savoir comment m'y prendre, tout conseil est le bienvenue ...
Merci d'avance!

[r0d]

Bonjour,

j'ai beaucoup sué et usé* de claviers sur cette question. Et sur la SFML entre autres.
En fait, le principal problème est le séquenceur. Pour faire simple, le séquenceur est l'objet (ou le processus, selon comment on considère le problème) qui va stocker et exécuter les évènements. L'évenement en lui-même n'a rien de compliqué: un événement doit comporter un delai (quand doit-il être exécuté) et une fonction Execute() (D.P.command).

Selon mon propre cheminement sur la question, et en ce qui concerne des applications graphiques sans énormes contraintes de rapidité, je suis aujourd'hui partisan d'un simple multiset:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
struct MyEventType
{
   MyEventType( int delay ) : delay_(delay) {}
   virtual ~MyEventType() {}
 
   inline const int & Delay() const { return delay_; }
   virtual void Execute() = 0;
 
private:
   unsigned int delay_;
};
 
struct MyEventComp
{
   bool operator () ( const MyEventType * left, const MyEventType * right )
   {
      return ( left->Delay() < right->Delay() );
   }
};
 
//! type definition for the event queue
typedef std::multiset<MyEventType*, MyEventComp> MyEventSet;
// Argh! Ce sont des pointeurs qui sont stockés!! Les pointeurs c'est le mal toussa... 
// oui mais là je n'ai pas le choix puisque ce qui sera stocké seront des objets qui héritent de MyEventType (polymorphisme toussa...)
// et non, pas de smart pointer non plus, c'est fait exprès

L'idée du code ci-dessus est:
. pour chaque type d'événement, on va créer une nouvelle classe/struct qui héritera de MyEventType.
. le séquenceur possèdera une queue d'événements (MyEventSet), lesquels seront automatiquement triés lors de leur insertion grâce au foncteur MyEventComp.

Ensuite, la façon dont les événements sont consommés par le séquenceur dépend de ton programme. Une façon classique de faire est, dans la boucle principale de l'application:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
Sequencer the_sequencer; // le séquenceur
Render the_renderer; // la classe qui s'occupe du rendu graphique
while( !close_application )
{
   the_sequencer.TreatEvents();
   renderer.DisplayFrame();
}

Le TreatEvents du séquenceur ressemblerait alors à quelque chose comme ça:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
void Sequencer::TreatEvents()
{
   // event_set_ est notre queue d'événements
   // 1. exécution des événements (ici c'estla fonction Execute de l'événement qui gère le délai (si delay_ == 0 alors execute, sinon delay_--;)
   std::for_each( event_set_.begin(), event_set_.end(), std::mem_fun( &SgrEvent::Execute) );
 
   // on élimine de la queue les évéments déjà exécutés
   MyEventSet::iterator it = event_set_.begin();
   while ( it != event_set_.end() )
   {
      if ( (*it)->Delay() <= 0 )
      {
         event_set_.erase( it );
         it = event_set_.begin();
      }
      else
         ++it;
   }
}

Bon, ce que je raconte là c'est en vrac, pour donner une idée de la solution que je propose. Si cela t'intéresse, tu pourras trouver une implémentation de cette solution ici. C'est une implémentation un peu ancienne, mais ça peut donner une idée. Aujourd'hui par exemple, je pense qu'il faut passer le contexte (le Renderer ici) à la fonction Execute() des événements.

Cordialement.


* l'anagramme est involontaire :^)

[Gregoire31]

Ecoutes, merci pour cette réponse tout à fait claire!
J'ai bien compris ta démarche.
Par contre j'ai une remarque, quand tu dis "sans contraintes de rapidité", qu'est ce que tu entends? Est-ce que SFML n'est pas un bon choix technique pour des contraintes temps réel?
Pour être plus clair dans ce que j'essaye de faire, je réalise un prototype qui a partir de coordonnées issues d'un moteur de reconnaissance de forme affiche cette information sous forme de cercle dans un casque à réalité virtuelle. Donc je cherche à être plus ou moins temps réel, tout en restant "prototype" dans le sens ou je n'ai pas besoin de créer l'application parfaite.
Dans mon cas, chaque nouvelle coordonnées (mon évènement) impact l'affichage ...
Merci encore!

[Emmanuel Deloget]

Est-ce que SFML n'est pas un bon choix technique pour des contraintes temps réel?

Ma foi, non, parce que Temps Réel n'a pas de sens dans ce cas. Un programme temps réel contraint, c'est un programme qui doit effectuer une opération spécifique dans un temps donné. Il lui est interdit de dépasser ce temps. Ceci dit, le temps en question peut être de l'ordre de l'heure.

L'expression "rendu en temps réel" est galvaudée. Il faudrait dire "rendu en temps interractif" (c'est à dire à 12 Hz et plus).

Par contre j'ai une remarque, quand tu dis "sans contraintes de rapidité", qu'est ce que tu entends?

Ce que veut dire rOd dans ce cas précis, c'est que la solution qu'il te propose est peut-être sous-optimale, mais que sa simplicité de mise en oeuvre la rend intéressante dès lors que les contrainte sur la fréquence de rendu ne sont pas trop élevée. Il ne discute pas des qualité de SFML, qui, après tout, ne reste qu'une porte d'entrée de l'affichage.

[Gregoire31]

Ok merci, effectivement je n'utilise pas forcément les bons mots ...
La question plus précise est donc si ma contrainte de rafraîchissement est de l'ordre de 30Hz à 50Hz, est-ce que cette solution reste "viable"?

[screetch]

quelques remarques sur les evenements de r0d:
- le stockage du timer devrait etre externe, pas dans la classe evenement. Plus une question de design que de performance.
- au lieu d'un temps relatif que tu decrementes, ce devrait etre un temps absolu (pas besoin de le mettre a jour chaque frame), et tu devrais le comparer au temps absolu au lieu de le decrementer et le comparer a 0
- si le multimap est trié selon le temps, alors seuls les n premiers événements (ceux dont le timer absolu est "dans le passé" doivent être executés. dés que tu trouves un événement s'effectuant dans le futur tu peux t'arrêter, et ce sera le premier événement a éxécuter la frame suivante.

ca sera beaucoup plus performant

[Emmanuel Deloget]

Ok merci, effectivement je n'utilise pas forcément les bons mots ...
La question plus précise est donc si ma contrainte de rafraîchissement est de l'ordre de 30Hz à 50Hz, est-ce que cette solution reste "viable"?

La réponse à la question est : mesure !

Avant de savoir si une solution est viable, il faut l'implémenter, la tester, et mesurer ses performances. Sans mesure, comment répondre à la question ?

[Gregoire31]

Ok je reviendrai poster un message après implémentation
Mon problème est d'ailleurs peut être plus "simple" que je ne le pense dans le sens ou mon programme lorsqu'il se rafraichit ne doit pas exécuter l'ensemble des tâches accumulées dans le sequenceur mais seulement la dernière ...

[r0d]

quelques remarques sur les evenements de r0d:
- le stockage du timer devrait etre externe, pas dans la classe evenement. Plus une question de design que de performance.

Que veux-tu dire par "stockage du timer"? La queue d'événements?

- au lieu d'un temps relatif que tu decrementes, ce devrait etre un temps absolu (pas besoin de le mettre a jour chaque frame), et tu devrais le comparer au temps absolu au lieu de le decrementer et le comparer a 0

- si le multimap est trié selon le temps, alors seuls les n premiers événements (ceux dont le timer absolu est "dans le passé" doivent être executés. dés que tu trouves un événement s'effectuant dans le futur tu peux t'arrêter, et ce sera le premier événement a éxécuter la frame suivante.

J'avais essayé cette solution, mais j'ai trébuché sur ma paresse pendant un détail d'implémentation

Mais en fait, ça peut dépendre aussi. Par exemple, s'il s'agit d'une petite application pas trop gourmande en événements (un jeu de dames par exemple), alors la queue d'événements sera quasiment toujours vide. Il est donc moins coûteux de décrémenter un compteur sur des événements que sur un compteur statique (car en plus il faut un système pour vérifier qu'on ne dépasse pas la valeur max du type du compteur, et une addition supplémentaire lors d'une insertion... bon, s'il y a très peu d'événements à insérer c'est pas vraiment un coût).

M'enfin bon, c'est aussi pour ça que je disais que ma proposition n'est pas conçue pour fonctionner sur des applications qui ont de grosses exigences de framerate, comme un FPS style Counter Strike ou un RTS style Starcraft par exemple, ou il est primordial que le fps ne déscende jamais en dessous de 120, dans laquelle la gestion des événements est le noyau du logiciel.

Mais sinon oui, mes doutes portaient sur mon code, non sur la SFML. Elle est vraiment très très rapide.

[screetch]

par stockage du timer je veux dire que le temps avant execution ne fait pas partie de la commande elle-même; la preuve en est que ta methode execute fait deux choses, soit elle decrémente le compteur soit elle execute. Dans ce sens je pense plutot que tu devrais avoir un multimap au lieu d'un multiset; la clé est le temps a attendre (plutot en absolu, comme ca pas besoin de la bidouiller) et ton événement n'a pas a gérer le temps lui même, cette responsabilité est reportée a ton EventManager
Event ne sait faire que "execute", et execute ne fait qu'executer.

[r0d]

- si le multimap est trié selon le temps, alors seuls les n premiers événements (ceux dont le timer absolu est "dans le passé" doivent être executés. dés que tu trouves un événement s'effectuant dans le futur tu peux t'arrêter, et ce sera le premier événement a éxécuter la frame suivante.

Effectivement c'est mieux comme ça. Cependant un doute subsiste: la façon dont tu présente la chose laisse à penser que tu ne libères pas les évenements qui ont été exécutés. Ce n'est pas dangereux? Si jamais on a des événements avec un peu des donénes dedans, et si on a beaucoup d'événements, on risque de faire péter la mémoire non?

[screetch]

je n'y ai pas pensé; pour moi c'était très clair dans ma tête mais je ne l'ai pas ecrit du tout

je dirai que le plus effiface serait de faire une boucle

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
m_currentTime += dT; // mise a jour de l'horaire absolu
 
std::multimap::iterator it = m_events.begin();
while(it != end() && it->first <= m_currentTime)
  it->Execute(); // execution de toute les tâches prévues pour maintenant
m_events.erase(begin(), it); // retire tous les événements executés; ne pas oublier le delete non plus =)

et voila, a priori on a degagé tous les événements du passé après les avoir executés

[r0d]

Okay merci.
Et vois-tu un inconvénient à libérer l'événement dans la boucle:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
while(it != end() && it->first <= m_currentTime)
{
  it->second->Execute(); // execution de toute les tâches prévues pour maintenant
  delete( it->second );
}
m_events.erase(begin(), it); /

[screetch]

nope, au contraire