1) Il faut optimiser le code du jeu avant de le multithreader
Oui tout à fait.
2) Le moteur de jeu est vieux et date d'avant les multicores. La séparation des tâches dans plusieurs threads est possible, mais elle ne sera jamais parfaite.
Exploiter parfaitement une machine est déjà quasi-impossible, surtout avec un code ciblant des architectures diverses. Et le faire avec du code parallèle est forcément encore plus dur.
Pourtant je trouve que ce que tu dis est triste. Oui il est tout à fait possible que le moteur n'exploite jamais très efficacement les multicores ; parce que le développement, uniquement porté par des bénévoles, est lent, et que du coup le projet pourrait en effet être moribond bien avant ça. Mais dans l'absolu, le fait de voir un jeu sans cesse amélioré (plutôt que sorti une fois pour toutes, et abandonné par son studio, passé à un autre projet) est plutôt enthousiasmant, aussi je préfère ne pas dire "jamais" tant que le projet vit.
Il y a en gros 2 axes pour multithreader un jeu:
Mettre les différentes parties (rendu graphique, moteur physique, IA,...) dans des threads différents. L'avantages c'est que c'est assez "facile" de porter un vieux moteur monothreadé. Un des soucis est que les différentes parties ne sont pas aussi gourmandes les unes que les autres, aussi on exploite pas forcément très efficacement la machine.
Dispatcher les différentes "entités" du jeu dans les différents threads, chacun s'occupant de la physique/IA/... des entités dont il s'occupe. Évidemment c'est très complexe (les entités d'un thread doivent pouvoir interagir avec celles d'un autre efficacement—en plus des souci classique de race condition ; mais il faut quand même dispatcher de manière à ce que ça arrive le moins possible), mais si c'est bien fait c'est plus efficace que la technique précédente.
J'ai instinctivement tendance à penser que pour un RTS la 2ème technique est plus facile à implémenter que pour d'autres genre ; du fait par exemple qu'on pas mal d'entités statiques (les bâtiments) qui, si suffisamment éloignées ne vont pas interagir ensemble (évidemment ça dépend des règles) ; après lorsqu'on a plein d'unités au même endroit qui se tapent dessus ça devient peut-être assez infernal à faire efficacement, alors je ne m'avancerai pas trop non plus, il est clair que c'est complexe. Ça ferait sûrement un passionnant GSoC :)
[^] # Re: gz
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Entretien avec Nicolas Auvray, contributeur du projet 0 A.D.. Évalué à 2.
Oui tout à fait.
Exploiter parfaitement une machine est déjà quasi-impossible, surtout avec un code ciblant des architectures diverses. Et le faire avec du code parallèle est forcément encore plus dur.
Pourtant je trouve que ce que tu dis est triste. Oui il est tout à fait possible que le moteur n'exploite jamais très efficacement les multicores ; parce que le développement, uniquement porté par des bénévoles, est lent, et que du coup le projet pourrait en effet être moribond bien avant ça. Mais dans l'absolu, le fait de voir un jeu sans cesse amélioré (plutôt que sorti une fois pour toutes, et abandonné par son studio, passé à un autre projet) est plutôt enthousiasmant, aussi je préfère ne pas dire "jamais" tant que le projet vit.
Il y a en gros 2 axes pour multithreader un jeu:
J'ai instinctivement tendance à penser que pour un RTS la 2ème technique est plus facile à implémenter que pour d'autres genre ; du fait par exemple qu'on pas mal d'entités statiques (les bâtiments) qui, si suffisamment éloignées ne vont pas interagir ensemble (évidemment ça dépend des règles) ; après lorsqu'on a plein d'unités au même endroit qui se tapent dessus ça devient peut-être assez infernal à faire efficacement, alors je ne m'avancerai pas trop non plus, il est clair que c'est complexe. Ça ferait sûrement un passionnant GSoC :)