Les threads dans les jeux vidéos

**Davidbrcz** · 22/08/2007, 15h21

Bonjour à tous.

Je suis en train de concevoir un petit jeu vidéo.
D'après la conception que j'ai concue, je ne vais pas avoir besoin de thread dans mon jeu.
Or d'apres mes idées recues , tout les 'grands' JV utilsent des threads.
La question qui se pose est donc "où ca ?"

Une partie de la réponse est sans doute dans les serveurs multi-joueurs.
Mais dans mon cas , je m'en fout , mon jeu étant jouable seulement en solo.

Alors une idée ?

Merci.

**Laurent Gomila** · 22/08/2007, 15h38

Or d'apres mes idées recues , tout les 'grands' JV utilsent des threads.

C'est justement une idée reçue. La vérité c'est que tu ne dois utiliser les threads que lorsque tu en as réellement besoin. Les threads servent à solutionner des problèmes bien précis, pas juste à "faire bien". Car crois-moi, l'utilisation de threads introduit beaucoup de nouveaux problèmes, et il vaut mieux y être préparé pour gérer ça correctement.

**Davidbrcz** · 22/08/2007, 15h46

Car crois-moi, l'utilisation de threads introduit beaucoup de nouveaux problèmes, et il vaut mieux y être préparé pour gérer ça correctement.

J'ai une idée des problèmes occasionés :
syncronisation de données entre les threads, sémaphore/mutex, communication inter-thread , rendre les fonctions thread-safe ...

**Laurent Gomila** · 22/08/2007, 15h51

C'est ça. En gros, à chaque fois que deux threads doivent communiquer ou partager une donnée, tu as potentiellement un gros problème. Sans compter que debugger une appli qui fait tourner plusieurs threads devient un casse-tête. Et également, mais dans une moindre mesure, que chaque nouveau thread ajoute une petite perte de performances. J'avais croisé un article pas mal sur le sujet, qui racontait comment un jeu tournait catastrophiquement grâce à l'idée géniale de son concepteur de faire tourner un thread pour chaque sprite à afficher.

**Ti-R** · 22/08/2007, 15h58

Dans certain cas, gestion de la musique et des sons via un thread.
On peu imaginer d'autres cas.

Mais, moins il y en a, mieux on se porte

Par contre si tu veux tirer le potentiel maximum d'un quad core, faire de la physique dans un thread à part, plus de l'IA dans un autre thread, pourquoi pas

Mais c'est sur, cela demande beaucoup plus de contraintes.

**Davidbrcz** · 22/08/2007, 15h58

Envoyé par Laurent Gomila

Et également, mais dans une moindre mesure, que chaque nouveau thread ajoute une petite perte de performances.

Je ne savais pas.

Envoyé par Laurent Gomila

J'avais croisé un article pas mal sur le sujet, qui racontait comment un jeu tournait catastrophiquement grâce à l'idée géniale de son concepteur de faire tourner un thread pour chaque sprite à afficher.

Ca me rapelle moi il y a de cela, allez, 1 an et démi.
J'avais voulu faire un jeu codé 'à l'arrache' .Non disons plutôt au feeling.
Et j'avais eu la bonne idée de lancer un thread par algo de pathfinding par unité.
Ca marchais avec 2-3 segfaults ici et la , car ya des pointeurs de partous.

Edit :

Par contre si tu veux tirer le potentiel maximum d'un quad core, faire de la physique dans un thread à part, plus de l'IA dans un autre thread, pourquoi pas

J'en ai pas la possibilité avec mon sempron 2600+

**bafman** · 22/08/2007, 15h58

Envoyé par Laurent Gomila

C'est justement une idée reçue. La vérité c'est que tu ne dois utiliser les threads que lorsque tu en as réellement besoin. Les threads servent à solutionner des problèmes bien précis, pas juste à "faire bien". Car crois-moi, l'utilisation de threads introduit beaucoup de nouveaux problèmes, et il vaut mieux y être préparé pour gérer ça correctement.

100% d'accord...
et d'ailleurs, bien au contraire, les gros JV n'utilise que très peut de thread.
dans tout les moteur "previous gen" (moi aussi j'invente des terme marketing bidon

), l'utilisation de threads se limitait souvent au réseau. Le reste était fait dans un seul processus.
On trouvait parfois du chargement de données du monde à la volé, mais c'était une utilisation relativement limité des threads.
maintenant, par contre, si on souhaite profiter des proc multi core, ça peut devenir intéressant d'avoir des threads.

**nicØB** · 22/08/2007, 16h01

Avec les processeurs multicores, ça reste quand même plus avantageux de faire un jeu avec plusieurs thread je pense. Il y a une perte de perfs du à la gestion de la concurrence & cie, mais elle doit être plus que compensée, non ?

En tout cas pour un serveur on est gagnant.
Le tout c'est de ne pas avoir trop de thread par rapport aux nombres de cores. D'ailleurs l'idéal ça serait quoi ? Un thread par core ? Ou alors c'est assez spécifique selon l'application ?

**Ti-R** · 22/08/2007, 16h21

Il y a une perte de perfs du à la gestion de la concurrence & cie, mais elle doit être plus que compensée, non ?

Oui en principe c'est largement compensée.

Le but étant de créer un certain nombre de thread, et ne pas tomber dans l'excessif, 1 thread, 1 core serait sûrement l'idéal si chaque thread avait besoin de la même puissance de calcul, ce qui n'ait généralement pas le cas.

Le plus facile étant de découper par grosse partie son application. (son, réseau, IA, physique, génération de textures, de landscapes etc...)

Par contre sur les futurs processeurs avec 50 cores, il faudra sûrement programmer autrement, ou les outils ne seront pas les mêmes....

**Mat.M** · 22/08/2007, 16h22

Envoyé par Davidbrcz

Une partie de la réponse est sans doute dans les serveurs multi-joueurs.
Mais dans mon cas , je m'en fout , mon jeu étant jouable seulement en solo.
Merci.

Il y a eu des discussions houleuses là-dessus et curieusement Laurent a changé d'opinion

.
L'intérêt d'utiliser des threads pour l'affichage ou autre est assez limité voire nul.Rien ne t'empêche de faire l'essai...
Maintenant pour une architecture jeu client serveur multijoueur c'est quasi indispensable pour la synchro des taches

**bafman** · 22/08/2007, 16h28

Envoyé par Ti-R

Oui en principe c'est largement compensée.

en principe...
car dans les faits, le problème n'est pas le nombre de threads, mais le nombre de besoin de synchro entre ces threads, et malheureusement, dans le JV, les communication entre threads sont très nombreuses (l'IA a toujours besoin d'avoir accès à des données du moteur 3D, pareil pour la physique etc...)
Une solution peut être de dupliquer les données pour travailler localement dessus au sein d'un thread, mais même ça, ça présente de nombreux problèmes (occupation memoire explosé, et les temps de synchro entre thread sont eux aussi beaucoup plus important (car plus de copie))
bref, c'est pas tout rose le multi core

**Davidbrcz** · 22/08/2007, 16h34

Rien ne t'empêche de faire l'essai...

Si deux choses:

vos remarques
le manque d'envie d'implémenter des threads juste pour du test.

screetch · 22/08/2007, 16h50

Desormais les "grand" jeux sont effectivement tous multithread! la raison ? la XBOX360 a 3 coeurs hyperthreadés, la Playstation 3 a une architecture a 8 coeurs (1 "MAIN UNIT" et 7 "SPE") se partageant les requetes memoire en token ring. Les PC vendus aujourd'hui sont a 80% multi core (mais ca ne represente pas plus de 5% du parc des utilisateurs)

Donc oui les boites de jeux font du multithread. Plus ou moins bien.

Si tu t'en sens le courage tu peux t'y mettre, mais si tu ne developpes pas sur XBOX ou PS3 oublie, tu vas plus te creer de probleme qu'en resoudre ^^

neanmoins si l'aventure te tente ...

- la physique peut etre sur un trhead mais il va falloir locker les donnees physiques... tu ne peux pas deplacer une unite alors que les calculs physiques se font
- de meme pour le rendu
- le serveur en cas de jeu en ligne (pas ton cas)
- les animations des personnages.
- le chargement de ressources; peut etre fait dans le fond, et par exemple tant que ta texture n'est pas chargee tu affiche du banc. Ou alors tu charges une texture moche de petite taille qui va vite en attendant la grande plus detaillee qui charge dans le fond
- l'IA, c'est tres specifique, a voir donc

Mais pense bien aux consequences ^^

**HanLee** · 22/08/2007, 16h53

Envoyé par Davidbrcz

Ca me rapelle moi il y a de cela, allez, 1 an et démi.
J'avais voulu faire un jeu codé 'à l'arrache' .Non disons plutôt au feeling.
Et j'avais eu la bonne idée de lancer un thread par algo de pathfinding par unité.
Ca marchais avec 2-3 segfaults ici et la , car ya des pointeurs de partous.

En même temps pour du pathfinding, les threads t'es un peu obligé

Cf Supreme Commander...

**Davidbrcz** · 22/08/2007, 16h56

Envoyé par screetch

Desormais les "grand" jeux sont effectivement tous multithread! la raison ? la XBOX360 a 3 coeurs hyperthreadés, la Playstation 3 a une architecture a 8 coeurs (1 "MAIN UNIT" et 7 "SPE") se partageant les requetes memoire en token ring. Les PC vendus aujourd'hui sont a 80% multi core (mais ca ne represente pas plus de 5% du parc des utilisateurs)

Donc oui les boites de jeux font du multithread. Plus ou moins bien.

Si tu t'en sens le courage tu peux t'y mettre, mais si tu ne developpes pas sur XBOX ou PS3 oublie, tu vas plus te creer de probleme qu'en resoudre ^^

neanmoins si l'aventure te tente ...

- la physique peut etre sur un trhead mais il va falloir locker les donnees physiques... tu ne peux pas deplacer une unite alors que les calculs physiques se font
- de meme pour le rendu
- le serveur en cas de jeu en ligne (pas ton cas)
- les animations des personnages.
- le chargement de ressources; peut etre fait dans le fond, et par exemple tant que ta texture n'est pas chargee tu affiche du banc. Ou alors tu charges une texture moche de petite taille qui va vite en attendant la grande plus detaillee qui charge dans le fond
- l'IA, c'est tres specifique, a voir donc

Mais pense bien aux consequences ^^

Tu semble t'emballer.
Mon jeux , c'est un petit jeu en 2D sans réel IA, avec des animations des personnages réduite a une rotation de sprites(qui ne sont pas plus de 15) le tout sans physique(du moins pour le moment).

(Pour info , je souhaite reproduire ce jeux: http://www.handdrawngames.com/DesktopTD/game.asp)

**bafman** · 22/08/2007, 17h01

Envoyé par HanLee

En même temps pour du pathfinding, les threads t'es un peu obligé

Cf Supreme Commander...

non.
on peut très bien mettre en place un système de pathfinding hiérarchique qui n'oblige pas du tout à utiliser des threads pour avoir un pathfinding efficace.

screetch · 22/08/2007, 17h11

Dans ce cas tu a peu a gagner a faire du multithread. Et beaucoup a perdre (je veux dire surtout du temps, quelques neurones, ta copine, etc etc

)

**HanLee** · 22/08/2007, 17h50

Envoyé par bafman

non.
on peut très bien mettre en place un système de pathfinding hiérarchique qui n'oblige pas du tout à utiliser des threads pour avoir un pathfinding efficace.

Tu parles du pathfinding qui cherche petit bout par petit bout ?

**bogoss91** · 22/08/2007, 17h54

Envoyé par Davidbrcz

Tu semble t'emballer.
Mon jeux , c'est un petit jeu en 2D sans réel IA, avec des animations des personnages réduite a une rotation de sprites(qui ne sont pas plus de 15) le tout sans physique(du moins pour le moment).

(Pour info , je souhaite reproduire ce jeux: http://www.handdrawngames.com/DesktopTD/game.asp)

Les tower defence, ça me rappelle tellement des bons moments sur Warcraft 3