Analyse du code source de CryEngine V

En mai 2016, la compagnie allemande Crytek a décidé de publier 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 communauté open-source qui scannent régulièrement les nouveaux projets afin d’analyser la qualité du code. L’outil utilisé pour analyser CryEngine V a été PVS-Studio Analyser (v6.05). Si vous n’êtes pas familier de l’analyse statique, voici un article pour vous présenter le concept.

pvs

PVS-Studio est un analyseur statique qui détecte des erreurs dans le  code source d’applications C/C++ avec l’appui de tous les dispositifs C++11 modernes et prolongements Microsoft-spécifiques. Il y a 4 catégories principales d’erreurs qui sont détectées: erreurs de programmation génériques, problèmes de portabilité 64-bit, optimisations possibles d’exécution et erreurs de programmation parallèle (la bibliothèque d’OpenMP est soutenue). Le code source de l’application et toutes les tiers bibliothèques utilisées sont vérifiés.

Bon, si on prend les plus gros projets Open-source, on va retrouver fatalement un assez grand nombre d’erreurs.  Qu’en est-il spécifiquement de CryEngine V ? Est-ce que c’est un moteur qui tient la route techniquement  ? Quand on voit les la liste des jeux développés, et les features présentés, on ne peut pas imaginer que cela soit une usine à gaz bourrée d’erreurs…

L’analyse date d’Aout 2016, vous retrouverez le rapport complet ici. D’ailleurs, d’autres analyses sont disponibles à cette adresse, dont l’analyse d’Unreal Engine (Juin 2015). Nous reviendrons sur cette dernière dès qu’une plus récente sera disponible. Vous pouvez toutefois consulter ce post sur le blog de l’éditeur.  Il y a aussi Godot Engine, Serious Engine, X-Ray Engine et Xenko Engine.

7wfxfa3z3mv25ktuk68dw68pezfwv3w3-1

Que retenir de cette analyse (je vous évite de bouffer tout le rapport) ?

Tout d’abord, quelques chiffres – en terme de warning, il a eu 576 classés “High”, 874 classés “Medium” et 2942 classés “Low”.

Alors, voici quelques éléments qui pourrait être optimisés comme:

  • lancer une fonction fabs_tpl(q2.v.z – q2.v.z) au lieu de fabs_tpl(0) (entitynode.cpp 93).
  • Tester 2 fois si la même condition est vraie (texturestreaming.cpp 919)
  • Tester 2 fois une même condition dans une même branche: ‘if (A) {…} else if (A) {…}’  (d3dhwshader.cpp 266)
  • Ou de façon encore plus incongrue ‘if (A) {…} else if (A)’  (environmentalweapon.cpp 970)
  • Initialiser deux fois une variable avec des valeurs différentes sans l’utiliser entre deux (ccrydxgldevicecontext.cpp 1266)
  • Ou avec les mêmes valeurs carrément ! (ccrydxgldevicecontext.cpp 905)
  • Faire le même traitement dans un bloc if et else (d3dshadows.cpp 1410)
  • Initialiser une classe avec elle-même (particleparams.h 1013)

Bon, on pourrait lister toutes les erreurs de ce type – elles ne sont pas bloquantes et ne provoquent pas de bogue, mais c’est un code qui pourrait facilement être optimisé. Si vous le souhaitez, je vous engage à lire le rapport complet et examiner le code au fur et à mesure – vous pourriez même apprendre quelques trucs en C++. Mais ce sont malheureusement des erreurs que nous commettons également, soit parce qu’on a modifié trop vite le code en voulant l’optimiser par exemple, soit parce qu’on a programmé comme un gros porc entre deux prises 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 statique qui permet de répondre à cette question. Mais il est bien modulaire, bien documenté et relativement optimisé – une simple analyse macro permet de donner déjà ce constat. Il s’appuie d’ailleurs sur des librairies tierces très robustes.

newinv-csharp

il aurait été appréciable d’utiliser un outil d’analyse avant la mise en open source, mais bon… maintenant tout est corrigé (enfin, je l’espère). C’est aussi l’avantage de passer un code source dans le monde de l’open – bénéficier de l’expertise d’une communauté grandissante, pour avoir un code plus robuste, et surtout une grande réactivité concernant la correction de bogues et les développement de nouvelles features.

Donc, même à votre niveau, peu importe quel outil d’analyse vous utiliserez – il me semble essentiel de vous rappeler qu’on gagne beaucoup à utiliser ces automatismes qui permettent de détecter des boulettes qui peuvent parfois couter cher… très cher. Et c’est d’autant plus vrai si vous passer votre code au 64 bits… ou si vous utiliser des librairies pour le parallélisme. J’essaierai de vous lister plusieurs outils en fonction des langages utilisés dans ma section “Librairies, Langages & Outils pratiques” qui n’est pas encore bien étoffée. Mais bon, progressivement j’ajoute une structure “fixe” en mode wiki à ce blog pour lui donner une véritable valeur ajoutée en terme d’expertise, et pas seulement un blog qui liste des news au fur et à mesure. Et ça prend du temps…

Ces articles pourraient aussi vous intéresser …