Discussion :

[Rewpparo]

Bonjour,
Je fais un jeu complexe et multithread�. J'ai d�cid� de faire communiquer les diff�rents threads de mani�re asynchrone et g�n�rique par un syst�me d'events. Mais j'ai l'impression d'avoir construit une usine a gaz, et j'ai peur que la performance finale ne soit tr�s affect�e par ce syst�me.

Les particularit�s de mes besoins sont qu'un m�me event doit pouvoir �tre multicast� sur plusieurs threads diff�rents, et doit �tre effac� proprement quand tout le monde l'a trait�.

Je suis donc parti sur une classe Event qui ressemble a cela :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
class Event
{
private:
   unsigned m_refCount;
protected:
   Event();
   virtual ~Event();
public:
   void grab();
   void release();
   unsigned getCount();
};

je d�rive ensuite event autant que n�cessaire :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
class InputEvent : public Event;
class KeyboardEvent : public InputEvent;
class KeyboardKeyEvent : public KeyboardEvent;
class GameEvent : public Event;
...

Je cr�� ensuite des classes EventReceiver et EventSender afin de g�rer le routage et le stockage des events, ainsi que le comptage des r�f�rence. Elles seront templat�es afin que la file puisse ne traiter qu'une cat�gorie d'events plus ou moins pr�cise.

Quand je recois un event, j'utilise typeid et dynamic_cast pour r�cup�rer les informations.


Ce design est id�al en terme de fonctionnalit�s, je sais que ce syst�me d'events s'adaptera � tout ce que je vais lui balancer. par contre, entre le RTTI (dynamic_cast, destructeur virtuel) et le comptage de r�f�rences, j'ai bien peur que ca ne soit beaucoup trop intensif. Il y a aussi le probl�me de la fragmentation m�moire, car j'aurais beaucoup d'events cr��s et d�truits. Je pensais utiliser un allocateur pour limiter les d�g�ts.

D'une mani�re g�n�rale, mon approche est elle r�aliste ? Existe t il des optimisations afin d�all�ger la charge ? Qu'utilisez vous pour transmettre des informations entre threads dans des programmes complexes ?

[Neckara]

Bonjour,

Pour les �v�nements j'ai l'habitude de voir dans les biblioth�ques un union avec un discriminant :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
struct
{
      enum TypeEvent{CLAVIER, SOURIS};
      union
      {
                struct Clavier{}clavier;
                struct Souris{}souris;
       };
       TypeEvent typeEvent;
};

Pourquoi chaque �vent doit-il �tre trait� par chaque thread? N'est-ce pas plut�t un probl�me de conception?
Si tes threads partages trop de ressources, ils vont se bloquer les uns les autres constamment et ils ne seront au final presque aussi performant qu'un seul thread.

[Rewpparo]

Pour les �v�nements j'ai l'habitude de voir dans les biblioth�ques un union avec un discriminant :

C'est le syst�me que j'avais mis en place au d�but. Le probl�me de ce syst�me, c'est que pour ajouter un nouveau type d'event, il faut modifier une classe centrale, et tout recompiler. J'aimerais que des syst�mes puissent cr�er de nouveaux types d'events selon leurs besoins sans avoir besoin de changer le code du coeur du moteur, mais en utilisant des "canaux" g�n�riques.
L'approche avec les structs est d'une mani�re g�n�rale tr�s 'C' et j'essaie justement de trouver mieux. C'est un bon fallback si ce que j'aimerais ne marche pas.

Pourquoi chaque �vent doit-il �tre trait� par chaque thread? N'est-ce pas plut�t un probl�me de conception?
Si tes threads partages trop de ressources, ils vont se bloquer les uns les autres constamment et ils ne seront au final presque aussi performant qu'un seul thread.

Tous les events ne sont pas trait�s par chaque thread, mais peut �tre trait� dans plusieurs, juste ceux qui en ont besoin.
Dans un jeu vid�o, il y a beaucoup de ressources partag�es. Faire toutes les communications sous forme d'events permet justement d'�viter qu'ils ne partagent un �tat. L'id�e est que chacun garde les infos dont il a besoin sous la forme la plus pratique pour sa tache, et ils se tiennent au courant des changements. Et ce de mani�re asynchrone, justement pour ne pas bloquer.

[Neckara]

Serait-il possible d'avoir un diagramme ou une pr�sentation expliquant le r�le de chaque thread, ainsi qu'un exemple de fonctionnalit� entra�nant des �changes entre thread (exemple : gestion des collisions?) afin de mieux comprendre ce que tu fais ?

[Rewpparo]

Heu j'ai ca sur un paquet de papier, mais �a reste partiel. Il y a des syst�mes o� j'ai une vague id�e, mais sans avoir mis �a sur papier car je ne les d�velopperais pas avant un bail.
Cot� mod�le, le concept g�n�ral est d'avoir chaque unit� du jeu potentiellement dans un thread diff�rent. En fait j'utilise un scheduler simple, on lui donne un nombre de threads, on lui balance les unit�s et il les r�partit la charge entre les threads disponibles.
Cot� vue, Il y aura un thread graphique, chaque unit� le tient au courant de ses changements par l'envoi d'un event contenant la position, les infos d'apparence, etc...
Cot� contr�leur, le clavier/souris seront dans le thread graphique, le joystick et autres inputs louches dans leur thread a eux. Ils envoient des events (appui de touche, etc..) a un contr�leur qui transformera �a en commande (avancer, tourner a droite, tirer...) qui sera envoy�e � l'unit� contr�l�e.

C'est simplifi�, mais c'est l'esprit.

[screetch]

il y a quand meme pas mal d'optimisations possibles, ca depend de tes contraintes

deja, si tu elimines le dynamic_cast et que tu appelles seulement une methode virtuelle, ca sera ca de gagne (les dynamic_cast sont tres tres chers, surtout ceux qui echouent) (enfin ils l'etaient en 2007 quand j'ai ete confronte au probleme)

pourquoi un dynamic_cast? pourquoi pas un

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
class IEvent
{
  virtual void execute() = 0;
};
 
class MouseEvent : public IEvent
{
  virtual void execute() /*override*/;
};

sinon, est-ce que le premier evenement traite est toujours le premier envoye (une FIFO) ou bien est-ce que les evenements peuvent etre traites dans un ordre aleatoire?

j'ai deja realise un scheduler, qui demarre N threads (N le nombre de processeurs). Les "evenements" dont tu parles sont chez moi des taches, chaque tache a une methode virtuelle. Le resultat n'est pas horrible dans la mesure ou chaque tache a un peu de boulot a faire, cela compense l'appel de methode virtuelle.

selon tes contraintes (ordre aleatoire, ou bien certains evenements sont assignes a certains threads particuliers) il y a des optimisations possibles, mais commencer avec une methode virtuelle n'est pas mauvais.

[Bousk]

Cot� mod�le, le concept g�n�ral est d'avoir chaque unit� du jeu potentiellement dans un thread diff�rent. En fait j'utilise un scheduler simple, on lui donne un nombre de threads, on lui balance les unit�s et il les r�partit la charge entre les threads disponibles.
Cot� vue, Il y aura un thread graphique, chaque unit� le tient au courant de ses changements par l'envoi d'un event contenant la position, les infos d'apparence, etc...
Cot� contr�leur, le clavier/souris seront dans le thread graphique, le joystick et autres inputs louches dans leur thread a eux. Ils envoient des events (appui de touche, etc..) a un contr�leur qui transformera �a en commande (avancer, tourner a droite, tirer...) qui sera envoy�e � l'unit� contr�l�e.

Je trouve que �a fait beaucoup de thread, et surtout beaucoup trop.

Lors de mon passage dans le jeu-vid�o, on utilisait au total 4 threads il me semble
- le thread principal
- le thread de rendu
- un thread pour le chargement et streaming des ressources
- un thread audio

Multiplier les thread ne fera qu'alourdir la logistique du logiciel, et surtout : quel int�r�t ?
Que chaque unit� ait son propre thread �a semble sexy, mais va synchroniser le tout, c'est la gal�re.
Alors que faire un update du dt sur chaque unit� � chaque fois que n�cessaire est enfantin. Et toutes tes unit�s �voluent du m�me dt.
Idem pour les entr�es clavier/joystick etc... quel int�r�t r�el ?! Le mieux �tant de traiter la pile d'�v�nements � chaque �volution du dt.