Discussion :

[Kannagi]

Pour ma part la raison de leur technique 'old school' est simple , quand tu code un moteur tu privilégie les fonctionnalité de base et la tu n'as pas besoin de plein de nouveauté du C++14 , mais juste plusieurs routines bien pensé et optimisé , quand ces routines qui consomme facilement 50% du jeu sont bien optimisé , le reste c'est juste le codage de l'architecture et du Jeu et la toute les techniques modernes sont les bienvenues , ce que doit faire aussi le moteur Unity codé en C++ (et probablement des parties très bas niveau avec une ancienne technique) , mais tout le gameplay en C#.

[yildiz-online]

Il ne faut pas oublier que les contraintes en entreprise sont très différentes de celles d'un amateur:

• Connaissances et compétences des personnes en interne et sur le marché.
• Compatibilité avec l'existant.
• Ressources nécessaires pour tester de nouvelles approches.
• Coût pour former les personnes en interne.

Tout ceci est à prendre en compte lors d'un changement de technologie et le rend beaucoup moins trivial sur un projet de xM loc avec son lot de dépendances, ses x personnes travaillant dessus et les décideurs qui valideront le budget ou non que sur un projet de 10k loc fait tout seul dans son coin.

[Luc Hermitte]

Du old school pour plein de choses en effet.

Tu ne vois pas ? Ben eux ils voient ; s'ils ont décidé de se passer des exceptions, c'est pas par masochisme, c'est parce qu'ils ont fait des mesures, du profilage, etc, pour déterminer que ça nuisait aux perfs.

J'ai croisé pas mal d'arguments en défaveur des exceptions
- google> les développeurs n'y comprennent rien/ ne savent pas (/ne sauront jamais) écrire du code robuste => on les fuit (résultat ils considèrent les mallocs qui renvoient NULL comme des erreurs qui doivent planter les applications -- perso j'ai déjà eu à faire des allocations de tailles venant de l'extérieur (et donc non contrôlées) et toutes les allocations ne pouvaient pas aboutir (et bossant sur des softs critiques, on évite de planter chez nous))
- regoogle> on a une vieille base de code qui n'est pas exception-safe (la seule justification valide à mon gout)
- plein> mauvaises perfs
- AAA-console> la PSP-machin crashe à cause des exceptions (OK, c'est la seconde justification valide que je connaisse)


Pour les perfs, je ne suis pas convaincu. Il y a longtemps les compilos n'optimisaient pas le chemin nominal, et effectivement, ça coutait cher. Maintenant, le chemin nominal est optimisé. Résultats: un binaire plus gros et un sur-cout au lancement -- et des perfs médiocres dans les chemins non nominaux (et là, OSEF ce qui coute le plus cher dans un chemin non nominal, c'est l'utilisateur final qui va devoir régler le problème)). Seulement ... j'ai l'impression que ceux qui critiquent les exceptions ne mesurent jamais les performances du chemin nominal entre un code avec exceptions (et des catchs bien placés => en nombre restreint (merci le RAII)), et un code qui n'est pas au pays magique où les erreurs n'existent pas, c'est à dire d'un code qui a un if toutes les deux lignes. Il m'est avis que le problème est que c'est très difficile à comparer correctement. Il ne s'agit pas d'avoir des benchs de 50 lignes, mais des programmes plus pertinents avec des arbres d'appels de fonctions de jusqu'à quelques dizaines de niveaux de profondeur, avec des boucles, etc et qui remontent leurs erreurs), et écrire ces programmes en double demande du boulot pour avoir un bench fiable.

Pourquoi je suis plus que dubitatif : un if, c'est une prédiction de flot d'exécution qui peut foirer dans le pire des cas, voire pas de prédiction du tout parfois. Quand il y a un "if" entre deux call/gosub, cela fait beaucoup de prédictions qui peuvent foirer. Avec des exceptions, les tests n'ont lieu qu'aux seuls points où les erreurs peuvent être détectées. Cela fait beaucoup moins de tests. Ce qui fait qu'en nominal, cela devrait tracer bien plus vite.

On pourrait arguer qu'il ne devrait pas y avoir des cas exceptionnels dans un jeu vu qu'ils prennent la voie des optims de l'embarqué (toutes les allocations en début d'exécution), mais ... je n'y crois pas un seul instant : un câble peut-être retiré, et pouf, plus de joypad, plus de réseaux, ... Et puis d'ailleurs, ils ont implémenté leur propre système de dépilage de contexte, preuve en est qu'il y a toujours des cas exceptionnels à traiter. Cela veut-il dire qu'il ont fait le choix pays magique (pas de if), mais avec instrumentation avec leur système de surveillance de contexte ? Je serai curieux de savoir si leur code passe le test de robustesse décrit par Raymon Chen.
Et je pense à un autre élément, "noexcept" est parfaitement utilisable pour les zones du code où l'on peut s'attendre à ce qu'aucune entrée n'ait besoin d'être vérifiée (affichages, sorties audios, ...) -- je pense rejoindre Lolilolight là.

Bref je suis plus que dubitatif.

Sur le sujet:
- http://741mhz.com/exceptions-performance/ (une analyse des assembleurs produits, mais pas de bench associé)
- http://www.flounder.com/exceptions.htm (autre bench, mais la propagation d'erreur n'est pas mesurée, et il ne semble pas compiler avec un -fno-exception ou équivalent)
- http://stackoverflow.com/questions/3...es-in-c#307716 (autre analyse de l'assembleur)
- http://nwcpp.org/october-2006.html (une analyse de 2006 qui conclue qu'un code correct a des performances équivalentes à celles d'un code avec EH)


Concernant virtual, les branch-miss, & cie. Virtual devrait couter aussi cher que des tables de pointeurs de fonctions, car en interne c'est la même chose. De plus, virtual offre de meilleures performances que des if/switch à partir d'une demi-douzaine de cas (mais des benchs sont à faire pour chaque plateforme pour connaitre le seuil exact de chacune).
Mais ... avec ces ECS qui ont le vent en poupe (et qui viennent du monde du jeu si j'ai bien compris), reste-t-il tant de virtual que cela dans les codes des jeux ? Je ne suis pas sûr qu'il en reste beaucoup avec ce pattern.

PS: il y a eu plusieurs confs par des gens d'UBI soft ou autre AAA cette dernière année, et ils utilisent le C++11 notamment pour optimiser sauvagement des accès concurrentiels. Il n'y a pas que les amateurs qui exploitent des outils récents.

[Vetea]

Bonjour,
Je suis un petit développeur indé "old school" mais je n'ai rien compris au sujet et j'ai vite perdu pied au fil du débat ...
On a beau savoir comment se goupille un jeu, n'empêche que j'ai l'impression que sans faire de passéisme, les machines d'antan étaient au service des développeurs alors que maintenant ça m'a l'air d'être tout le contraire ...

[CodeurPlusPlus]

Mais non Vétéa, tu n'es pas largué du tout. En réalité c'est cette foutue programmation orientée objet, et en particulier le langage C++ qui est un horrible bricolage à dix mille couches, qui complique ce qui devrait être simple. Mais c'est devenu la religion d'état dans "developpeur land".

Ils sont rigolos tous ces programmeurs de jeu AAA : "Alors C++ c'est génial, mais on n'en utilisera pas les fonctionnalités avancées... parce que sinon on n'a pas les perfs dont ont besoin nos super jeux".

Ok. Je suis d'accord avec vous. Revenez donc au bon vieux C et cessez de vous cassez les couilles sur ce qui n'en vaut pas la peine.

[Invité]

Mais non Vétéa, tu n'es pas largué du tout. En réalité c'est cette foutue programmation orientée objet, et en particulier le langage C++ qui est un horrible bricolage à dix mille couches, qui complique ce qui devrait être simple. Mais c'est devenu la religion d'état dans "developpeur land".

Je ne leur conseille pas d'utiliser des technologies comme JEE ou là il m'arrive d'être, vraiment largué, des fois.

Ils sont rigolos tous ces programmeurs de jeu AAA : "Alors C++ c'est génial, mais on n'en utilisera pas les fonctionnalités avancées... parce que sinon on n'a pas les perfs dont ont besoin nos super jeux".

Sur des PC, je ne perçois pas de différence, que je fasse de l'orienté objet ou pas (même lors de benchmark), il suffit d'utiliser les bonnes options de compilation et quelques techniques modernes et j'arrive à du 30 FPS sur des PC vieux de plus de 5 ans. (Et je n'ai pas de différence entre un rendu à 60 et à 30 FPS)

Même avec du debug , du profiling et des exceptions, ça ne pose pas de problèmes, j'arrive à débuguer sans soucis.

Bref, c'est pour cela que je trouvais leur arguments plutôt rigolos, je sais qu'ils chargent plus d'entités que moi mais je ne pense pas que ils s'amusent à charger et à décharger des entités à chaque tour de boucle, si ils connaissent bien les technologies modernes, ils pourraient facilement utiliser un cache et un design de type d'entité/composant.

Allons, la POO n'est pas si compliquée, et permet de s'y retrouvé dix fois mieux dans le code, maintenant c'est sûr que si il ont autant de lignes de codes avec autant d'employé, je préférerais laissé tout comme ça plutôt que de changer le code ou bien carrément repartir à 0.

PS : Et peut importe le nombre de triangles à chargé, vu que AAA en charge sûrement plus que moi, avec le cache et la mémoire cache, la mémoire ne sera pas bouffée et les perfs non plus.

Bref, moi aussi je les trouves vraiment rigolos dans ce qu'ils avancent comme argument.

[foetus]

Lolilolight il est rigolo

La POO n'est pas compliquée. Dans un sens ce n'est pas compliqué effectivement.

Mais POO + multi-threading (*) + architecture embarquée bridée (**) + contraintes de m*rd* (style pas de sockets bloquantes) + équipe avec des non-techniques (et surtout avec des commerciaux) (***) = shitstorm

* -> Lolilolight et son processeur unicore
** -> Cela a beau être du Jaguar
*** -> Le créa qui veut tester rapidement sa superbe texture pour habiller un personnage

[TRUAN2LAGALERE]

Les gamedev du dimanche qui enragent après Ubisoft, ça me fait penser aux musiciens du dimanche qui enragent après lady gaga parce qu'ils se sont fait refouler à la nouvelle star. Ceux qui répètent et composent toute la semaine pour racler des cachets de misère ont déjà un avis plus objectif mais ça vous intéresse moins parce que bèèh on parle pas aux sales pauvres.

Et puis c'est un peu fastoche (et d'une lâcheté haïssable) de vous défouler à quinze contre un sur lolilolight alors que c'est loin d'être le plus amateur de votre petite cour de récré, c'est même apparemment un des rares qui bosse un peu sérieusement sur des composants de jeu et la majorité d'entre vous n'ont pas le niveau pour comprendre ce qu'il raconte. Par exemple je vois "codeurplusplus" qui écrit des âneries d'une énormité consternante mais ça se voit moins car il sait dire des bêtises en se donnant l'air intelligent et il se trouvera toujours un parterre de baltringues qui n'y voient que du feu.

J'éspère pour vous qu'Alex Fleury va pas tomber sur ce topic de petits caniches jaloux qui jappent en meute, ça risque de le dégoûter de donner des cours gratos. Y'a des choses très pertinentes dans leurs méthodes de boulot mais puisque ça n'a l'air d'intéresser personne, continuez à radoter "moi je m'en fous je programme des jeux pour m'amuser le dimanche et j'ai pas envie de me fouler", ça vous va bien, changez rien.

[tomlev]

C'est un peu incohérent ton histoire... d'un côté tu t'en prends à ceux qui critiquent ce que dit Nicolas(*) Fleury dans sa présentation (et là je suis d'accord avec toi), et de l'autre tu défends Lolilolight qui a pourtant été le premier à critiquer le contenu de la présentation, avec des arguments assez douteux... il faudrait savoir

(*) et non Alex, mais je suppose que c'est ce que tu voulais dire

[TRUAN2LAGALERE]

Quand tu auras fait un jeu AAA à toi tout seul, on en reparlera...

Ce genre de rélfexion c'est le running-gag des fanboys d'internet, tu peux décliner ça à toutes les sauces, genre quand t'auras réalisé douze blockbusters t'auras le droit de dire que hobbit 3 est un navet.

C'est un peu incohérent ton histoire... d'un côté tu t'en prends à ceux qui critiquent ce que dit Nicolas(*) Fleury dans sa présentation (et là je suis d'accord avec toi), et de l'autre tu défends Lolilolight qui a pourtant été le premier à critiquer le contenu de la présentation, avec des arguments assez douteux... il faudrait savoir

C'est parce que j'ai l'esprit analogique et pas binaire.

Ca n'est pas parce que je trouve lamentablement puéril votre bolossage en groupe de lolilolight, que je suis d'accord avec tout ce qu'il dit.

Mais pour me faire plus précis, les passages que je trouve intéressants dans le cours d'ubisoft ne sont pas ceux que lui critique.


De toutes façons je ne me sens pas en position de critiquer le travail d'Ubisoft, je bosse pour des petits studios français fauchés, l'industrie triple A j'y connais rien, c'est un autre monde... je vois juste qu'il y'a quand même quelques techniques universelles chez eux que j'utilise aussi. Je pousse même le vice plus loin à revenir à des optimisations des années 80 (on ne programme pas tous pour ps4) ça m'empêche pas non plus de profiter des avantages de l'oo, je pije pas trop où y'a conflit, fin, pas grave.

[tomlev]

Ce genre de rélfexion c'est le running-gag des fanboys d'internet, tu peux décliner ça à toutes les sauces, genre quand t'auras réalisé douze blockbusters t'auras le droit de dire que hobbit 3 est un navet.

Euh... as-tu vraiment lu le message auquel je répondais ? Dans ce contexte, je ne vois pas en quoi ma remarque est un "running gag des fanboys d'internet". Et ton analogie avec les blockbusters est assez foireuse...

[Cirrus Minor]

Oh !
Jean-Kevin Musclor est de retour !

[TRUAN2LAGALERE]

Tomlev > C'est trop facile de jeter des tomates à lolilolight parce qu'il aurait commis l'erreur de mélanger AAA et indé dans la même discussion, alors que vous faites pareil que lui. C'est pratique hein le bouc-émissaire sur lequel on rejette des conneries commises par tout le groupe.

Tout ça parce qu'il est malhabile sur la forme, il maîtrise moins bien le français que vous. Par contre il m'a l'air d'étaler pas mal de monde en c++, je suis obligé d'en déduire que ça pue la jalousie primaire.

[Kannagi]

Cirrus Minor a toi aussi ces posts te font pensé a lui ?
Si c'est le cas le multi compte c'est pas bien , d'ailleurs je pense que si c'est le cas Jean-Kevin Musclor n'etait pas son premier multi compte.

[Luc Hermitte]

Là où je rejoins le clandestin chinois, c'est quand le débat sort du technique pour passer aux attaques ad hominen.
Ca gâche beaucoup de choses. A force trainer sur le net, ce genre d'attaques me font plus douter des arguments des attaquants que de ceux des attaqués -- ce qui n'est certainement pas le but recherché.

Bref, si vous devez ne pas être d'accord, restez concentrés sur le technique. On n'est pas sur un blog politique ou reddit ici, non ? (et encore, le reddit/cpp est d'assez bonne qualité je trouve -> ça trolle moins que ce à quoi je m'attendais)

[TRUAN2LAGALERE]

Ici on est sur le forum jeuxvideo :noel: :hap: de developpez.com, 99% des intervenants n'ont aucune expérience du métiay, ils "programment" des "jeux" pour s'amusay le dimanche et se sentent tout-puissants d'être libéray de l'enfer des contraintes professionnayles, ça répond constemment à côtay, ça complote pour détournay le forum en terrain de chasse genre wow avec les graphismes en moins, ils ont réussi à explosay le niveau de connerie d'en face.

Ici c'ay une grosse cour de maternaylle gouvernay par day cafteurs autistes.

Bon zut moi aussi je tombe dans la raillerie lycéenne là, je montre pas l'exemple. Je vais essayer d'être un peu sérieux même si le lieu donne pas envie.

C'est pas la peine de rager après les gros studios ricains bourrés de thunes, s'ils ont pas de boulot pour vous c'est comme ça c'est la vie, et ça n'est certainement pas en pissant sur leur porte qu'ils vont vous l'ouvrir.

Là je vois dans cette communauté plein de gens avec des bras, un cerveau, de la bonne volonté et du temps disponible, ils pourraient tout à fait faire des choses intéressantes s'ils étaient assez intelligents pour bosser ensemble plutôt que de faire chacun égoïstement son petit truc dans son coin et pousser le sadomasochisme à inciter tout le monde à s'engouffrer dans des projets d'office voués à l'échec commercial.

Vous voulez faire des jeux mais vous n'irez nulle part tout seul, y'a pas de secret c'est comme n'importe quel autre type de programme: il faut du code, du code, du code, du code, du code, du code, du code et encore du code, il faut une armée de codeurs pour ça. Là j'en vois une potentielle mais complètement éparpillée, désorganisée, qui se jette des briques à la figure, mise tout sur l'esprit de compète individualiste et n'arrive rien à faire ensemble. Faut un adjudant pour leur mettre un bon coup de pompe au fion et les mettre au travail, et après ça ira mieux.

C'est bien ça la catastrophe des jeux vidéo en france, le comportement "nianiania moi je veux que faire des petites merdes dans mon coin parce que les autres ils sont tous nuls et puis les méthodes agil ça fait mal à la tête et ça m'intéresse pas j'aime pas apprendre je sais déjà tout", ça pourrit les amateurs comme les pros. Faudrait arrêter le concours de quéquette, chacun a des compétences différentes et c'est justement en les additionnant qu'on arrive à une équipe intéressante, plutôt qu'en les soustrayant pour se mettre en valeur au détriment du voisin.

[CodeurPlusPlus]

Heureux de te voir de retour Jean-Kevin, on va encore bien se marrer.

Sinon je maintiens que C++ est un langage atrocement mal conçu qui fait office de religion d'état ; il y a quinze ans je défendais la POO à mort et en particulier C++, mais j'en suis bien revenu. Le C c'est bien, le C with classes aussi dans certains cas (il existe des problèmes qui se prêtent bien à une modélisation objet), mais le "vrai" C++, le C++ "moderne", celui qui fait haïr le C, c'est de la vraie merde.

[Luc Hermitte]

Aller. Je vais répondre malgré le manque flagrant d'argumentation.

Sinon je maintiens que C++ est un langage atrocement mal conçu qui fait office de religion d'état ; il y a quinze ans je défendais la POO à mort et en particulier C++, mais j'en suis bien revenu. Le C c'est bien, le C with classes aussi dans certains cas (il existe des problèmes qui se prêtent bien à une modélisation objet), mais le "vrai" C++, le C++ "moderne", celui qui fait haïr le C, c'est de la vraie merde.

Le C++ moderne, aka C++ avec RAII dans mon acceptation, est la chose qui fait que le C m'insupporte. J'ai autre chose à faire que de rendre mes codes illisibles et pénibles à maintenir à devoir gérer les libérations de ressources à la main. Comme d'hab, cf les deux codes robustes : celui à la C, et celui à la C++ qui sont donnés en fin d'article: http://alexandre-laurent.developpez....ou-exceptions/

La POO ? Un bonus quand j'en ai besoin. Ce n'est pas là que réside la différence majeure entre le C et le C++.

Les templates, un autre gros plus par rapport aux macros pour écrire des types abstraits et des algos génériques. Mais, cela reste un avantage qui ne détrône pas le RAII.

Du coup, le C ? Je le cantonne aux plateformes exotiques dépourvus de compilateurs C++, ou pour les rares cas où j'ai des problèmes d'ABI à résoudre.

[foetus]

C'est pas la peine de rager après les gros studios ricains

UBISoft = Union des Bretons Indépendants

Au fait, TRUAN2LAGALERE tu me mettras 2 t-shirts de côté

La POO ? Un bonus quand j'en ai besoin. Ce n'est pas là que réside la différence majeure entre le C et le C++.

Les templates, un autre gros plus par rapport aux macros pour écrire des types abstraits et des algos génériques. Mais, cela reste un avantage qui ne détrône pas le RAII.

C'est pour cela que le C++ est considéré comme une boîte (ou une caisse) à outils: POO, template, héritage multiple, amitié ... copy/ swap pattern, ...

Mais certains n'arrivent pas à comprendre qu'on puisse coder en C++ sans ses outils et notamment juste en utilisant le principe de classe - RAII et l’encapsulation.
Ce n'est pas pour rien (du moins je le pense ) que les struct en C++ ce sont des classes avec une encapsulation publique.

[Invité]

Bon comme l'ont si bien fait remarqués certains :

-Coder des projets plus conséquent du genre AAA ça demande d'avoir une armée de codeurs, donc, à moi tout seul, je doute fort que je pourrai, donc, je pense que je vais faire comme une majorité de personnes ici (voir tout le monde) semble vouloir faire c'est à dire, coder des petits projets dans mon coin avec mon moteur.

Sur les systèmes embarqués, surtout ceux qui ne supportent pas les compilateurs c++ modernes et les socket non bloquant et ou il faut utiliser la cross-compilation, c'est très galère et souvent porteurs de nombreux bugs. :/
Mais se genre de système doit sûrement être relativement ancien. (Genre de vieux PC ou bien de vieille consoles portant à disparaître du marché ?)

J'ai donc voulu laissé tombé cela et me concentrer uniquement à la programmation de jeux vidéos sur des systèmes modernes.

J'ai du mal à justifier mes arguments et au niveau organisation aussi mais, ce n'est pas une raison pour se mettre à 4-5 contre moi.

Les grosses boîtes en général recrutent des indépendants qui ont déjà fais des petits projets et qui viennent tout juste de sortir d'une école. (enfin, je pense, et encore même avec ça j'ai du mal à trouver une porte ouverte, et pourtant, on ne peux pas dire que coder un moteur de jeux tel que le mien soit un petit projet.)

Mais bon je pense qu'ils sont loin d'être vraiment pros pour autant car faire des petits projets puis rejoindre une grosse équipe ne signifie pas avoir une maîtrise de tout ce qui est technique de programmation moderne, utilisée dans la plupart des entreprises autres que des développeurs de jeux vidéos.

Je connais des entreprises qui font des applications en c++14, je pense qu'ils ont plus d'expérience dans le monde professionnel que ceux qui sont resté au c et donc qui n'ont pas vu les deux langages. (pas à fond en tout cas)
Ce que je trouve dommage, et ce qui peut frustrer c'est que dans les SSI on ne recherche que des codeurs Java, JEE, C#, Sharepoint, etc.., qui demande de maîtriser un tas de concepts et avec des bugs à foisons, bref, je ne connais que une SSI qui utilise du c++14. (du moins en Belgique)
Encore faut t'il savoir si leur code c'est bien du c++14 et pas du c with c++14.

J'essayerai de mieux me justifier sur mon devblog quand j'aurai le temps, car là, j'ai pleins de petits projets de prévus pour 2016.

Mais en général :

-JEE et C# j'évite de rentrer dans ces boîtes car je sais que ça va être trop difficile pour moi et souvent ça va conduire à des bugs à foison.
-C with C++14 ou bien C tout cours également à cause de la gestion manuelle de la mémoire, pas de POO, d'héritage, de template qui facilitent beaucoup la programmation générique, et permet de s'y retrouver 100* mieux dans le code.

Mais pour moi tout seul je pense que ça s'arrêtera à POO + marketing se sera déjà bien.

Rajouter tout le reste (multithreading, système embarqué et cross compilation et compatibilité avec les anciennes plateformes) c'est du suicide.