Discussion :

[Aladore]

Bonsoir tout le monde ! (:

Je n'ai jamais vraiment utilisé les Threads, mais j'ai lu quelques articles où ils en parlent. Je me demandais, est-ce que par exemple on devrait ouvrir un thread par manager ?
Par exemple si j'ai un ContentManager qui doit charger des modèles, heightmap ou autre, est-ce que je dois créer un thread pour le chargement d'une donnée ?
Parce que pour le moment, quand je charge un modèle, bah l'écran est bloqué jusqu'à ce que mon modèle soit chargé.

Merci d'avance!

[GR3lh442kR]

tu peux peut etre afficher un écran de chargement, non?

[Mat.M]

Rien ne t'empêche, au chargement des données de lancer un thread pour cela ce qui évite de bloquer le programme et permet de laisser libre l'interaction avec l'utilisateur.
Mais ce sera vraiment le seul intérêt..
ou alors tu découpes chaque étape du chargement des données dans un thread distinct cela peut accélérer les choses.
Par exemple un thread pour les textures, un autre pour les objets 3d...

A noter que Visual Studio 2010 permettra la programmation parallèle

[Rémi Coquet]

L'utilisation de thread(s) n'est intéressant que si tu leur permets de gérer des mécanismes non-bloquants:
Que ce soit au niveau de la complétion réseaux, complétion disques etc. des décompressions effectuées par le GPU ou tous travaux effectués par des (co)processeur tiers.

Dans tous les autres cas, le multitâche est toujours plus lent car il t'oblige à changer de contexte souvent, ce qui est très chronovore, et d'interrompre les tâches courantes, ce qui est tout aussi dommageable...
Le mieux étant de te fabriquer ton propre ordonnateur et ses séquences déclenchées en veillant à ce que tous les mécanismes lancés n'aient pas besoin de se synchroniser, sinon, là encore, le multitâche est plus lent la plupart du temps.

Soit dit en passant -> Synchroniser du multitâche, c'est ne rien
comprendre au principe même du multitâche…

Tu peux le réaliser (ton automate multitâche) avec des WaitOnSingleEvent à l'intérieur de tes threads qui ne tourneront qu'en cas de besoin et seront plus facilement détruites en fin d'application.

Cela reproduit un peu le principe des interruptions pour rendre la "visualisation" plus aisée. Cela peut être très puissant si c'est utilisé avec le papier et le crayon au sein d'une architecture très rigoureuse:
Un seul objet (thread) disque, un seul objet décompression, un seul objet personnage… chacun possédant et gérant sa propre file d'attente de traitements, de manière à ne pas (re)devenir bloquant pour les copains !!!


Une autre méthode, plus simple à synthétiser par notre pauvre cerveau: Si tu utilises (aussi) de l'audio, par exemple, tu peux encore optimiser la gestion des events en les limitant à un seul: L'appel de la CallBack par la carte audio -> selon la longueur de buffer que tu as déterminé pour cette dernière (3ms / 10 ms etc.)
Tu n'auras plus de gestion d'events concurrentiels, ce qui peut toujours produire un hoquètement hiératique de temps en temps si ton architecture n'est pas une horloge suisse, mais une seule boucle de (lancement de)traitement qui tiendra dans la "longueur" du buffer audio:
Exemple:

Tu travailles à 25 Fps -> 0.04 s -> 40 ms (25Fps / 40 / 50 Fps 80 Fps (pour un jeu plus fluide par exemple))

40 ms peuvent se découper en 10 séquences de traitements de 4 ms chacune (même une carte audio intégrée sur une carte mère descend à 3ms sans problème).
Si tu n'as pas besoin d'autan de séquences (disques durs, décompression, saisie clavier, souris, moteur du jeu…) tu peux évidemment tourner avec 4 séquences de 10 ms.

A la fin, tu poireautes en attendant que la carte veuille bien te rappeler .

Si un de tes process est toujours en cours (déborde au niveau temporel donc) ce n'est pas dramatique, à condition que sa durée totale de validation ne soit pas supérieure aux 4 ms dans l'exemple ou qu'il possède une file d'attente suffisamment longue pour se récupérer en N cycles).
Tu peux aussi t'appuyer sur les files d'attentes individuelles pour travailler plus quand tu as plus de temps ; Tu obtiens ainsi un automate à charge de travail dynamique qui devrait assurer l'anticipation de tous les cas de figures, si ton scénario est prévu pour cela évidement. Il peut y avoir des attentes FIFO ou LIFO, contextuelles, à durée de vie… un scénario d'automate quoi.

Sachant que tu utilises en parallèle les temps de tes divers mécanismes, tu peux faire du direct to disk pour les images ou textures, gérer un réseau en temps réel, travailler tes algos SSE pour les automations, utiliser les cœurs du µp pour le scénario et le saisies e/s des divers périphériques…

4 ms c'est extrêmement long dans ses cas là… surtout si ton application se ballade sur un réseau d'applications du même type !

A noter que Visual Studio 2010 permettra la programmation parallèle

Disons que le µP et ses divers copains permettent, depuis une bonne double décennie, déjà de le faire... Je ne pense pas que la nouvelle mouture de béquilles aident qui que ce soit à mieux coder une stratégie inconsistante... mais bon, je ne voudrais pas casser la bonne ambiance non-plus et empêcher quiconque de cliquer sur les options +++ magiques

[yamashi]

Si je ne m'abuse il est impossible de charger et de faire un rendu en meme temps pour le moment...
Il faut attendre Directx11 pour ce genre de chose.

source : http://www.tomshardware.com/reviews/...tx,2019-6.html

Pour le moment il faut tout faire a la suite donc a toi de trouver comment faire.
Pour le reste je pense que Remi Coquet a couvert le sujet.

Bonne chance.

[oxyde356]

Quand est-il des animations pendant les chargements, sur certains jeux elles sont très fluides ? Pourtant l'application doit bien charger tous les modèles en mémoire derrière non ?

[Rémi Coquet]

Si je ne m'abuse il est impossible de charger et de faire un rendu en meme temps pour le moment...
Il faut attendre Directx11 pour ce genre de chose.

et

Quand est-il des animations pendant les chargements, sur certains jeux elles sont très fluides ? Pourtant l'application doit bien charger tous les modèles en mémoire derrière non ?

oxyde356, yamashi fait référence aux mécanismes internes de "chargements" des coprocesseurs graphiques et non aux chargements de type disques, qui eux, font appel à une électronique différente et indépendante.
Nous sommes là dans les threads physiques et réelles, par opposition aux vues de l'esprits auxquelles je fais allusion ici: http://www.developpez.net/forums/d60...oppement-jeux/ il est donc normal que l'accès à celles-ci soit sujet à évolution, à la fois au point de vue électronique et software via les mécanismes de DirectX et leur implémentation dans les drivers