Analyse du code source de CryEngine V

En mai 2016, la com­pag­nie alle­mande Cry­tek a décidé de pub­li­er le code source de son moteur phare, le CryEngine V, en open source sur Github.

Le moteur a été écrit en C++ et il a tout de suite attiré l’attention de plusieurs développeurs de la com­mu­nauté open-source qui scan­nent régulière­ment les nou­veaux pro­jets afin d’analyser la qual­ité du code. L’outil util­isé pour analyser CryEngine V a été PVS-Stu­dio Analyser (v6.05). Si vous n’êtes pas fam­i­li­er de l’analyse sta­tique, voici un arti­cle pour vous présen­ter le con­cept.

pvs

PVS-Stu­dio est un analy­seur sta­tique qui détecte des erreurs dans le  code source d’applications C/C++ avec l’appui de tous les dis­posi­tifs C++11 mod­ernes et pro­longe­ments Microsoft-spé­ci­fiques. Il y a 4 caté­gories prin­ci­pales d’erreurs qui sont détec­tées: erreurs de pro­gram­ma­tion génériques, prob­lèmes de porta­bil­ité 64-bit, opti­mi­sa­tions pos­si­bles d’exécution et erreurs de pro­gram­ma­tion par­al­lèle (la bib­lio­thèque d’OpenMP est soutenue). Le code source de l’application et toutes les tiers bib­lio­thèques util­isées sont véri­fiés.

Bon, si on prend les plus gros pro­jets Open-source, on va retrou­ver fatale­ment un assez grand nom­bre d’erreurs.  Qu’en est-il spé­ci­fique­ment de CryEngine V ? Est-ce que c’est un moteur qui tient la route tech­nique­ment  ? Quand on voit les la liste des jeux dévelop­pés, et les fea­tures présen­tés, on ne peut pas imag­in­er que cela soit une usine à gaz bour­rée d’erreurs…

L’analyse date d’Aout 2016, vous retrou­verez le rap­port com­plet ici. D’ailleurs, d’autres analy­ses sont disponibles à cette adresse, dont l’analyse d’Unreal Engine (Juin 2015). Nous revien­drons sur cette dernière dès qu’une plus récente sera disponible. Vous pou­vez toute­fois con­sul­ter ce post sur le blog de l’éditeur.  Il y a aus­si Godot Engine, Seri­ous Engine, X-Ray Engine et Xenko Engine.

7wfxfa3z3mv25ktuk68dw68pezfwv3w3-1

Que retenir de cette analyse (je vous évite de bouf­fer tout le rap­port) ?

Tout d’abord, quelques chiffres — en terme de warn­ing, il a eu 576 classés “High”, 874 classés “Medi­um” et 2942 classés “Low”.

Alors, voici quelques élé­ments qui pour­rait être opti­misés comme:

  • lancer une fonc­tion fabs_tpl(q2.v.z — q2.v.z) au lieu de fabs_tpl(0) (entitynode.cpp 93).
  • Tester 2 fois si la même con­di­tion est vraie (texturestreaming.cpp 919)
  • Tester 2 fois une même con­di­tion dans une même branche: ‘if (A) {…} else if (A) {…}’  (d3dhwshader.cpp 266)
  • Ou de façon encore plus incon­grue ‘if (A) {…} else if (A)’  (environmentalweapon.cpp 970)
  • Ini­tialis­er deux fois une vari­able avec des valeurs dif­férentes sans l’utiliser entre deux (ccrydxgldevicecontext.cpp 1266)
  • Ou avec les mêmes valeurs car­ré­ment ! (ccrydxgldevicecontext.cpp 905)
  • Faire le même traite­ment dans un bloc if et else (d3dshadows.cpp 1410)
  • Ini­tialis­er une classe avec elle-même (particleparams.h 1013)

Bon, on pour­rait lis­ter toutes les erreurs de ce type — elles ne sont pas blo­quantes et ne provo­quent pas de bogue, mais c’est un code qui pour­rait facile­ment être opti­misé. Si vous le souhaitez, je vous engage à lire le rap­port com­plet et exam­in­er le code au fur et à mesure — vous pour­riez même appren­dre quelques trucs en C++. Mais ce sont mal­heureuse­ment des erreurs que nous com­met­tons égale­ment, soit parce qu’on a mod­i­fié trop vite le code en voulant l’optimiser par exem­ple, soit parce qu’on a pro­gram­mé comme un gros porc entre deux pris­es de café… Bref, peu importe — c ‘est tout l’intérêt d’utiliser ce genre d’outils.

Voilà, non le code source du CryEngine est très bien écrit -en même temps, ce n’est pas une analyse sta­tique qui per­met de répon­dre à cette ques­tion. Mais il est bien mod­u­laire, bien doc­u­men­té et rel­a­tive­ment opti­misé — une sim­ple analyse macro per­met de don­ner déjà ce con­stat. Il s’appuie d’ailleurs sur des librairies tierces très robustes.

newinv-csharp

il aurait été appré­cia­ble d’utiliser un out­il d’analyse avant la mise en open source, mais bon… main­tenant tout est cor­rigé (enfin, je l’espère). C’est aus­si l’avantage de pass­er un code source dans le monde de l’open — béné­fici­er de l’expertise d’une com­mu­nauté gran­dis­sante, pour avoir un code plus robuste, et surtout une grande réac­tiv­ité con­cer­nant la cor­rec­tion de bogues et les développe­ment de nou­velles fea­tures.

Donc, même à votre niveau, peu importe quel out­il d’analyse vous utilis­erez — il me sem­ble essen­tiel de vous rap­pel­er qu’on gagne beau­coup à utilis­er ces automa­tismes qui per­me­t­tent de détecter des boulettes qui peu­vent par­fois couter cher… très cher. Et c’est d’autant plus vrai si vous pass­er votre code au 64 bits… ou si vous utilis­er des librairies pour le par­al­lélisme. J’essaierai de vous lis­ter plusieurs out­ils en fonc­tion des lan­gages util­isés dans ma sec­tion “Librairies, Lan­gages & Out­ils pra­tiques” qui n’est pas encore bien étof­fée. Mais bon, pro­gres­sive­ment j’ajoute une struc­ture “fixe” en mode wiki à ce blog pour lui don­ner une véri­ta­ble valeur ajoutée en terme d’expertise, et pas seule­ment un blog qui liste des news au fur et à mesure. Et ça prend du temps…

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.