Quelques optimisations pour les jeux vidéo

**Fabien Henon** · 23/05/2011, 18h20

Bonjour à tous,

Je connais bien le C++, je sais utiliser la STL, j'apprends à me servir d'OpenGL que je commence à savoir utilisé, mais il y a toujours en moi une question existentielle: l'optimisation.

Par rapport à la STL, est-ce qu'elle est plus optimisée que la lib C standard? Est-ce qu'elle est assez fiable? Pour la réalisation d'un jeu AAA est-ce qu'il est bien d'utiliser la STL? ou vaut il mieux utiliser la lib C standard ou encore tout recoder? Et s'il faut tout recoder est-ce qu'il vaut mieux le faire en assembleur ou bien le C++ reste suffisant?

Je me doute bien sûr que recoder tout directement en assembleur sera surement ce qu'il y a de plus rapide mais ce que je me demande réellement c'est jusqu'à quel point faut il aller pour réussir à avoir un jeu très rapide comme les jeux AAA actuels?

Par exemple je faisais un jeu en 2D assez simple utilisant la SFML mais déjà avec ce jeu utilisant quelques shaders, des centaines de sprites, et la STL dont beaucoup vector et map j'avais sur une bonne machine des FPS entre 60 et 80, or quand je fais tourner un jeu comme Assassin's creed 2 ou HL2 ou d'autres gros jeux il m'arrive d'avoir ce même genre de FPS alors qu'ils affichent beaucoup plus de polygones que moi.
Alors je me demandais comment c'était possible, qu'est-ce qui prend tant de ressources et qui a besoin d'être optimisé réellement.

D'un autre côté je me pose aussi quelques questions par rapport à l'optimisation avec OpenGL, quelles sont les fonctions qui prennent en général le plus de temps à s'exécuter et qu'il faut faire attention d'appeler le moins de fois possible.
Aussi, est-il préférable quand on veut afficher un objet de faire des glVertex avec la position que l'on veut ou bien vaut-il mieux faire d'abord un glTranslate?
Et en allant même plus loin que ça: est-ce que les calculs de matrices fais par openGL sont assez optimisés ou bien vaut-il mieux les faire sois-même avec des techniques d'optimisation?

Voilà en gros les questions que je me pose actuellement et pour lesquelles j'aimerais y voir plus clair.

Pour ceux qui peuvent m'en dire plus sur tout ça vos réponses sont les bienvenues.

Merci d'avance

**NevilClavain** · 23/05/2011, 18h41

Avec les processeurs dont on dispose aujourd'hui + les compilateurs qui mettent en place d'eux mêmes des optimisations relativement puissantes, l'aspect 'optimisation faite par le développeur' tombe lentement mais surement en désuétude, et c encore plus vrai avec les JV, où le travail le plus lourd (le rendu) est confié au GPU dont "c'est le métier". L'optimisation par ajout de portions en assembleur (très en vogue fin des années 90) n'apporterait pas de différence notables sur les perfs; donc tant qu'à faire, autant rester en C++ et utiliser les outils genre STL qui simplifient considérablement la vie

**LLB** · 23/05/2011, 18h50

Envoyé par The BasheR

Je connais bien le C++, je sais utiliser la STL, j'apprends à me servir d'OpenGL que je commence à savoir utilisé, mais il y a toujours en moi une question existentielle: l'optimisation.

Attention à me pas t'embêter avec ça trop tôt. Avant d'optimiser dans le bas niveau, assure-toi que tes algorithmes sont performants et que tu utilises correctement OpenGL (tu n'iras pas loin avec le mode immédiat par exemple). Je fais des applications C++/OpenGL, et c'est généralement le GPU qui est à la traine. Ce n'est pas toujours le cas, mais demande-toi (lire utilise un "profiler") ce qui ralentit ton application.

Envoyé par The BasheR

Par rapport à la STL, est-ce qu'elle est plus optimisée que la lib C standard? Est-ce qu'elle est assez fiable? Pour la réalisation d'un jeu AAA est-ce qu'il est bien d'utiliser la STL? ou vaut il mieux utiliser la lib C standard ou encore tout recoder?

La STL apporte surtout des fonctionnalités supplémentaires. Utilise la libc plus la STL. Dans un jeu AAA, la STL peut poser des soucis (certains studios la réécrivent pour optimiser des cas spécifiques ; je crois qu'il y a même des implémentations distribuées sur Internet) car elle répond à des besoins génériques. Dans la plupart des cas toutefois, la STL fait l'affaire.

Envoyé par The BasheR

Je me doute bien sûr que recoder tout directement en assembleur sera surement ce qu'il y a de plus rapide

À moins d'être un génie et d'y passer des années, ce n'est pas sûr. Les compilos sont très efficaces au niveau de la génération de code et des optimisations bas-niveau. Si tu maitrises le bas-niveau et que tu as des reproches à faire à ton compilo (après avoir analysé la sortie), tu peux recoder une partie en assembleur et faire un benchmark.

Envoyé par The BasheR

Alors je me demandais comment c'était possible, qu'est-ce qui prend tant de ressources et qui a besoin d'être optimisé réellement.

Utilise un profiler. Pour OpenGL, il me semble que gDEBugger est pas mal et gratuit.

Envoyé par The BasheR

Aussi, est-il préférable quand on veut afficher un objet de faire des glVertex avec la position que l'on veut ou bien vaut-il mieux faire d'abord un glTranslate?

Utilise les VBO. Si tu fais ton code à base de glBegin, glVertex, glEnd, ça ne m'étonne pas qu'il soit lent. Optimise ton code OpenGL avant de songer à réécrire la STL.

**Fabien Henon** · 23/05/2011, 19h39

Merci de vos réponses.

Par contre je dois préciser une chose que je n'avais pas précisée dans mon topic: ma question sur l'optimisation du jeu que j'avais fait et sur OpenGL ne sont en fait pas liés.

Pour mon jeu j'utilise directement la SFML dans son intégralité ainsi que la STL, je ne fais pas d'appels OpenGL moi même et donc quand je me demande ce qui ne va pas dans mon programme pour qu'il paraisse si lent je me demande si ça vient de la SFML (mais ça m'étonnerait car d'après ce que j'ai pu voir partout elle est quand même très rapide, bien que je me dis que c'est possible car elle est assez générique pour la 2D), de la STL ou tout simplement de mes algorithmes qui ne sont pourtant pas bien compliqués.

Mais c'est vrai que je devrais utiliser un profiler ce que je n'ai encore jamais fait, ça me donnera certainement plus d'informations.

Sinon par rapport à OpenGL c'est vrai qu'il y a les VBO, donc ma question est à oublier, par contre de manière générale il faut faire attention à quoi quand on utilise OpenGL pour éviter d'avoir des pertes de performances? Quels sont les appels les plus lourds d'OpenGL et qu'il nous arrive d'utiliser souvent?

Encore merci de vos réponse ainsi que des prochaines que vous pourrez me fournir

**NevilClavain** · 23/05/2011, 20h14

J'ai peu d'expérience en OpenGL, je me concentre davantage sur D3D, mais je connais quand même un truc de base qui je pense, est vrai avec les deux frameworks, c'est que les GPU sont faits pour "cracher" du triangle, mais par contre ont horreur des changements; aussi les opérations suivantes sont toujours source de ralentissement:

- changement de texture
- changement de "renderstate" (culling, alphablending, filtrage texture)
- changement de shader
- changement de VB

Et là vous me direz : "oui mais ces opérations sont inévitables" -> certes, aussi le but du jeu est de penser ses algos pour minimiser ces changements de contextes ; par exemple il est plus efficace de demander le rendu d'un seulVB de 10000 triangles plutôt que de 10000 VB de 1 triangle (c du vécu !)
Par ailleurs on peut faire en sorte que le scenegraph regroupe les operation de rendu des objets ayant les même textures et/ou shaders et/ou renderstates .

**LeGreg** · 23/05/2011, 20h56

Envoyé par NevilClavain

Avec les processeurs dont on dispose aujourd'hui + les compilateurs qui mettent en place d'eux mêmes des optimisations relativement puissantes, l'aspect 'optimisation faite par le développeur' tombe lentement mais surement en désuétude, et c encore plus vrai avec les JV, où le travail le plus lourd (le rendu) est confié au GPU dont "c'est le métier". L'optimisation par ajout de portions en assembleur (très en vogue fin des années 90) n'apporterait pas de différence notables sur les perfs; donc tant qu'à faire, autant rester en C++ et utiliser les outils genre STL qui simplifient considérablement la vie

Malheureusement c'est plutôt faux. Avec les jeux (AAA, mais aussi parfois Indie) qui deviennent de plus en plus lourds, qui affichent de plus en plus de choses à l'écran, qui doivent faire de l'IA, de la physique, du chargement de ressources dynamiques, et l'écart très important entre les plateformes bas de gamme et les plateformes haut de gamme (sur PC mais aussi en incluant les consoles) l'optimisation a encore de beaux jours devant elle (et on ne mets pas de côté l'optimisation GPU avec l'optimisation CPU, ce sont deux faces d'une même pièce qui va déterminer la rapidité globale d'affichage de ton jeu). Si tu joues à des jeux récents sur une machine un peu ancienne (2/3 ans), tu as sans doute pu expérimenter qu'il n'est pas possible de jouer "tout à fond" avec une fluidité exemplaire (60fps étant le graal sur PC, sur console ça descend rapidement à 30fps voire moins avec des résolutions toutes baveuses malgré le fait que ce soient des consoles "HD"). Cela montre bien que la performance est encore importante et que donc l'optimisation a encore de beaux jours devant elle.

Pour le choix de la STL, cela peut marcher pour toi comme cela ne pourrait pas marcher. Tout dépend comment tu l'utilises..

D'un autre côté je me pose aussi quelques questions par rapport à l'optimisation avec OpenGL, quelles sont les fonctions qui prennent en général le plus de temps à s'exécuter et qu'il faut faire attention d'appeler le moins de fois possible.
Aussi, est-il préférable quand on veut afficher un objet de faire des glVertex avec la position que l'on veut ou bien vaut-il mieux faire d'abord un glTranslate?
Et en allant même plus loin que ça: est-ce que les calculs de matrices fais par openGL sont assez optimisés ou bien vaut-il mieux les faire sois-même avec des techniques d'optimisation?

Il n'y a pas "Une fonction" qui va prendre plus de temps qu'une autre, un rendu OpenGL c'est un tout. Il faut minimiser le nombre d'états que tu changes par frame (image de ton rendu). Si tu changes beaucoup trop d'états (textures, shaders, constantes, etc) alors le coût CPU sera le facteur limitant. Et d'un autre côté si tu as trop de textures hautes def non compressées, des shaders complexes, si tu montes en résolution ou tu traces tout de l'arrière vers l'avant sans culling alors il y aura des chances que le GPU devienne le facteur limitant.
Pour identifier le facteur limitant dans ton jeu, il y a des méthodes systématiques, par exemple (un peu vieux, mais les techniques sont toujours un peu les mêmes à adapter suivant ton jeu) :
http://developer.download.nvidia.com...ay=style-table

LeGreg

**LeGreg** · 23/05/2011, 21h04

Envoyé par LLB

À moins d'être un génie et d'y passer des années, ce n'est pas sûr. Les compilos sont très efficaces au niveau de la génération de code et des optimisations bas-niveau.

Les compilos ne sont pas forcément super efficaces, mais ils font un "relativement bon boulot en moyenne". Le fait est que l'assembleur d'aujourd'hui (x86) est tellement complexe que tout faire à la main en assembleur est souvent contre productif (à l'epoque du Z80 ou 68000 sur Amiga par ex, l'assembleur était plus fréquent parce qu'il n'y avait pas tant d'instructions que ça, que les jeux étaient beaucoup plus simples et que l'on pouvait évaluer les perfs en comptant les instructions utilisées par une routine. Ceci dit à la même époque certains jeux étaient programmés en BASIC.).
Par contre il n'est pas interdit d'aller voir le boulot du compilateur de temps à autre, pour mettre en évidence une inefficacité...de son propre code C++. Retravailler le code C++ pour permettre au compilateur de générer le bon code est une bonne partie du boulot.

LeGreg

**NevilClavain** · 23/05/2011, 21h39

Envoyé par LeGreg

Malheureusement c'est plutôt faux. Avec les jeux (AAA, mais aussi parfois Indie) qui deviennent de plus en plus lourds, qui affichent de plus en plus de choses à l'écran, qui doivent faire de l'IA, de la physique, du chargement de ressources dynamiques, et l'écart très important entre les plateformes bas de gamme et les plateformes haut de gamme (sur PC mais aussi en incluant les consoles) l'optimisation a encore de beaux jours devant elle (et on ne mets pas de côté l'optimisation GPU avec l'optimisation CPU, ce sont deux faces d'une même pièce qui va déterminer la rapidité globale d'affichage de ton jeu). Si tu joues à des jeux récents sur une machine un peu ancienne (2/3 ans), tu as sans doute pu expérimenter qu'il n'est pas possible de jouer "tout à fond" avec une fluidité exemplaire (60fps étant le graal sur PC, sur console ça descend rapidement à 30fps voire moins avec des résolutions toutes baveuses malgré le fait que ce soient des consoles "HD"). Cela montre bien que la performance est encore importante et que donc l'optimisation a encore de beaux jours devant elle.

LeGreg

Ca reste vrai, pour le point sur lequel je répondais, à savoir l'inclusion d'assembleur dans le projet, pour les optimisations "bas niveaux" ; hormis quelques cas exceptionnels, plus personne n'utilise d'optimisations à base d'ASM; les options d'optimisations fournies avec les compilos suffisent dans 99% des cas. Ca n'exclut pas évidemment pas les optimisations de plus haut niveau, cad dans la façon dont sont pensés les algos, le moteur de jeu, l'architecture, etc , mais à ce niveau là le langage utilisé (C++ ou ASM) n'a pas d'impact.

**r0ots** · 24/05/2011, 09h48

Pour de l'optimisation C++, j'était tombé sur ce site : http://www.agner.org/optimize/

J'avais déja quelques notions d'optimisations, mais cette personne la va loin, beaucoup trop loin pour moi en tout cas.

Je conseil tout de même la lecture du 1er de ses 5 manuels : http://www.agner.org/optimize/optimizing_cpp.pdf qui présente des optimisations "haut niveau" (entendre par la : "pas assembleur"). Les 4 autres étant pas mal concentrés sur l'assembleur.

Y'a aussi ce papier la que j'avais bien aimé : Design For Performance

C'est un cours d'optimisation mis en ligne par la personne de ce site : http://c0de517e.blogspot.com/
Il est développeur de jeux pour console, donc son cours est assez pertinent je pense. Ca parle de multithread, cache miss, SIMD...

Mais comme on l'as dit plus haut, la chose la plus importante : PROFILER

Ca sert à rien de commencer à optimiser du code si tu sais pas où optimiser. Et surtout, ça sert a rien de commencer à optimiser du code si tu n'as pas moyen de voir l'impact de ces optimisations.

**Fabien Henon** · 24/05/2011, 11h19

Merci de vos réponses c'est très instructif.

Ce que j'en retiens surtout c'est qu'il me faut un profiler avant tout.

Si vous avez encore des choses à partager concernant ce sujet je serais très content de les entendre.

Encore merci

**r0ots** · 24/05/2011, 15h57

Y'a ça qui vient de tomber dans mes flux RSS, si ça peut t'aider :

http://www.lighthouse3d.com/2011/05/...ofile-library/

Jamais essayé, donc je ne sais pas ce que ça vaut, mais vu la source je dirait que ça ne doit pas être inutile.