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 ?