Discussion :

[LittleWhite]

Nicolas Fleury, architecte logiciel à Ubisoft Montréal nous montre l'utilisation du C++ faites dans les jeux vidéos AAA.
Dans cette vidéo, vous comprendrez mieux les contraintes en termes de programmation d'un programme de jeu vidéo. En effet, malgré la multitudes de fonctionnalités dont dispose le C++, certaines sont à éviter.

Bonne vidéo.

[MoDDiB]

Superbe article.

Pour résoudre cela, les développeurs pourraient trier les objets par type, mais le problème ne serait que diminué et non supprimé. Le mieux est donc de se passer du mécanisme des fonctions virtuelles.

Il peut être sympa d'expliquer comment s'en passer : avec des pointeurs de fonctions par exemple, attention c'est vraiment une optimisation à ne faire qu'en cas de nécessité : c'est extra chiant à débuguer après...

[Kannagi]

Après ce genre article est plus a titre informative pour ma part , mais un peu inutile pour le programmeur amateur/indépendant vu que cela n'est pas pareil en terme de projet et de code , je ferais un amalgame entre faire sa propre maison et faire un building de plus de 100 mètres de haut y a certes des points commun , mais certaine technique serait particulière au building (et inutile pour une simple maison).

[tomlev]

Intéressant. Mais au final, s'ils n'utilisent ni fonctions virtuelles, ni exceptions, ni RTTI... peut-on encore dire que c'est du C++? Finalement c'est quasiment du C.

Sinon j'ai trouvé intéressant de voir qu'ils utilisent assez massivement C#, mais j'aurais aimé avoir un peu plus de détails sur les cas d'utilisation.

[Lutarez]

Vidéo très intéressante !

Sinon j'ai trouvé intéressant de voir qu'ils utilisent assez massivement C#, mais j'aurais aimé avoir un peu plus de détails sur les cas d'utilisation.

D'après ce qu'il dit, ils s'en servent essentiellement pour toutes les aspects où les performances ne sont pas la problématique principale. Par exemple, les éditeurs, le code réseau, les "launcher"/"updater", etc.

[Invité]

Article intéressant mais inutile pour un développeur indie comme moi.

[foetus]

Donc en gros tout est fait à la main : compilation, linkage, débogage, gestion mémoire, ce qui implique très très peu de STL et rien d'autre.

Et même la gestion mémoire j'ai cru comprendre que les développeurs ont un énorme tableau global (qui peut être mis en cache ou en mémoire) qu'ils utilisent comme tas

Il peut être sympa d'expliquer comment s'en passer :

Mon anglais est très moyen mais j'ai cru comprendre 2 choses:

1) Lors de la compilation/ linkage, le processus remplit des tableaux dans les classes avec les pointeurs des méthodes (+ des informations comme où se trouve cette méthode (fichier, ligne)).

D'ailleurs, il me semble que c'est plus ou moins illégal en C++ de prendre en direct l'adresse d'une méthode.

2) Un peu ce qu'il dit souvent; par du global. Là c'est flou . Mais on peut penser qu'il y a une tripotée de fonctions/ procédures globales, et qu'ensuite elles sont appelées dans des méthodes inline.
Ou alors, comme son exemple template, ils font une "grosse" classe mère (peut-être singleton) qu'il utilise via des petites classes filles avec des méthodes inline.

D'ailleurs, il ne parle jamais de namespace. Vu comme c'est chiant c'est peut-être pour cela

[Invité]

Ouf, ça craint, ils parlent de singleton et puis de contexte multi-thread, juste déjà cela ça m'a fait fuir.
Ce sont pour des raisons de performances qu'ils utilisent des techniques aussi dangereuses ?
Car le singleton n'est pas thread safe.
Et une classe mère singleton instanciée avec des classes fille template, cela me semble vraiment salle comme implémentation.

Pour l'uploader et la plateforme de téléchargement ainsi que l'éditeur je trouve ça bien d'utiliser du c# par contre.
Reste à savoir si ce langage est assez bien sécurisé, si oui, je pense que je vais utiliser ça aussi.

Le nombre d'employé et de développeur me semble énorme et le nombre de ligne de code également, sincèrement en tant qu'indé moi je me casse pas le cul je fais la même chose mais avec beaucoup moins de lignes de codes, et le tout, tout seul. (Ou au mieux à deux mais c'est rare)

Mais bon en même temps je ne m'amuse pas à faire toutes les optimisations qu'ils font!

Je n'ai pas compter le nombre de ligne de code de mon moteur mais si il fait 10 000 lignes de code, c'est déjà bien.

De plus ils utilisent deux moteurs différents pour leur deux jeux ?

PS : les exceptions je trouve ça bête de ne pas les utiliser, surtout depuis qu'il y a les pointeurs intelligent, surtout que elles ne se lancent pas pendant la boucle de jeux en général mais plutôt lors du chargement de ressources ou de la sérialisation, je ne vois pas du tout en quoi ça pourrai gêné les performances.

Pour le système de RTTI autant utiliser typeid plutôt que de le réinventé. :/
Je ne vois pas en quoi ne pas l'utilisé augmenterai la sécurité.

Bref encore des arguments et un débats qui me semble, être du grand n'importe quoi.

Ce n'est pas du c++14, ça ressemble plutôt à du c en effet.

[foetus]

Car le singleton n'est pas thread safe.

Il peut être encapsulé pour être "thread-safe"

Et une classe mère singleton instanciée avec des classes fille template, cela me semble vraiment salle comme implémentation.

Oui mais il n'y a pas de pointeurs, ni de new/ delete

Je n'ai pas compter le nombre de ligne de code de mon moteur mais si il fait 10 000 lignes de code, c'est déjà bien.

Il y a de grandes chances que leur moteur soit à base de pools threadés de tâches et patron de conception Observer avec une tripoté de managers (mémoire, réseau, hardware, ...)

PS : les exceptions je trouve ça bête de ne pas les utiliser, surtout depuis qu'il y a les pointeurs intelligent,

Pointeurs intelligents dit pointeurs

Pour le système de RTTI autant utiliser typeid plutôt que de le réinventé. :/
Je ne vois pas en quoi ne pas l'utilisé augmenterai la sécurité.

Peut-être qu'avec la RTTI il faut faire des reinterpret_cast.

C'est plus "simple" de faire ton propre système et qu'il soit utile pendant l'exécution mais aussi pendant le débogage et à l'optimisation mémoire.

[Invité]

Il peut être encapsulé pour être "thread-safe"

Oui je me disais ça et je faisais ça avant pour mon système de gestion des ressources, cependant, je suis passé à un système de contexte. (D'ailleurs on m'a conseillé de le faire par propreté du code et par respect pour la programmation orientée objet.)

Je trouve ça beaucoup plus propre de tout initialiser les entités au chargement et de tout détruire à la fin du programme, lorsque le contexte est détruit, plutôt que d'utiliser un singleton.

Je ne crée rien et je ne détruit rien au cours du jeux, (à part des particules mais je ne le fais pas avec des new et des delete), je ne fais que de changer des pointeurs...

Je tourne à du 30 FPS avec un vieux PC de plus de 5 ans et une veille carte graphique avec en plus une vieux driver qui ne supporte même pas l'opengl moderne.

Oui mais pas il n'y a pas de pointeurs, ni de new/ delete.

Oui enfin, je ne vois pas en quoi ça augmente les performances surtout si les news et les delete ne sont pas fait dans la boucle de jeux.

Il y a de grandes chances que leur moteur soit à base de pools threadés de tâches et patron de conception Observer avec une tripotés de managers (mémoire, réseau, hardware, ...)

Pas besoin de threads pour faire cela, des sockets non bloquants, et des timers suffisent.

Pointeurs intelligents dit pointeurs

Je ne vois pas en quoi ça pose problème d'utiliser des pointeurs surtout si on ne les allouent pas et si on ne les détruits pas dans la boucle de jeux. (ce qui bien sûr baissent les performances)

Peut-être qu'avec la RTTI il faut faire des reinterpret_cast.

C'est plus "simple" de faire ton propre système et qu'il soit utile pendant l'exécution mais aussi pendant le débogage et à l'optimisation mémoire.

Non, sans RTTI tu vas devoir définir une std::string personnalisée pour chaque type que tu vas enregistrer dans ta factory, je ne fais aucun reinterpret cast et devoir te souvenir du nom lors de l'appel de la fonction non virtuelle template puisque apparemment ils n'utilisent pas non plus de fonctions virtuelles.
Un système de réflexibilité est plus lent qu'une fonction virtuelle,

Au niveau du débogage je m'en sors très bien comme ça.

Bref ce qu'ils font là ce n'est rien d'autre que du c with c++.