STL pour les jeux, oui ou non? [fermé]

Chaque langage de programmation a sa bibliothèque standard de conteneurs, algorithmes et autres éléments utiles. Avec des langages tels que C #, Java et Python, il est pratiquement inconcevable d’utiliser ce langage sans sa bibliothèque standard.

Pourtant, dans de nombreux jeux C ++ sur lesquels j'ai travaillé, nous n’utilisions pas du tout la STL, n’en utilisions qu'une infime fraction, ou utilisions notre propre implémentation. Il est difficile de dire si c'était une décision judicieuse pour nos jeux, ou une décision prise simplement par ignorance du STL.

Alors ... est-ce que la STL convient ou pas?

À l'époque où je travaillais dans le développement de jeux professionnels, STL était trop immature et gonflé. Mais c'était il y a plus de 10 ans.

Maintenant, je travaille dans la simulation militaire, qui a des exigences de performances encore plus strictes (comme le framerate ne peut jamais descendre en dessous de certains FPS). Dans la simulation militaire, STL est utilisé partout.

Certaines personnes qui vous disent de ne pas utiliser STL utilisent l'argument selon lequel ce n'est pas toujours la solution parfaite ni même la meilleure solution au problème. Mais ce n'est pas une réponse à la question. La question devrait être la suivante: y a-t-il quelque chose qui cloche fondamentalement avec l’utilisation de STL dans les jeux? Je dirais que non, STL est la plupart du temps une meilleure implémentation que ce qu'un utilisateur propose lui-même.

Assurez-vous simplement de savoir comment utiliser la STL et utilisez-la dans votre jeu. Lisez quelques livres et examinez le code de mise en œuvre dans le STL que vous utilisez.

Je dirais que, de mémoire, il est préférable d’utiliser la STL à moins que vous ne sachiez exactement pourquoi vous ne voulez pas l’utiliser.

Voici la chose à propos de la STL: elle est développée par des personnes plus intelligentes que vous. Ce n'est pas destiné à être offensant ou quoi que ce soit, c'est simplement que le STL est développé par des personnes dont le travail est réellement de construire le STL. Elle sera à peu près aussi rapide que la plate-forme le permettra et sera généralement beaucoup plus robuste qu'une solution maison (et cela devrait être aussi une préoccupation sinon plus que de se soucier de la vitesse brute - parce que votre jeu a besoin robustesse un peu plus que vous avez besoin de vitesse, le dernier est sans signification sans l'ancien.

Les plaintes selon lesquelles le TSL impose une "vision étroite du monde" me paraissent un peu ridicules. Ce sont des conteneurs. Ils ont un ensemble d'opérations limité car les conteneurs ont des ensembles d'opérations limités. Que faites-vous qui ne concorde pas avec cela?

J'ai vu très peu de raisons de ne pas utiliser la STL pour les jeux.

Pour les problèmes d'allocation de mémoire, beaucoup de gens ne le savent pas, mais vous pouvez écrire des allocateurs personnalisés pour vos classes de conteneur STL. Les affectateurs sont essentiellement des classes de stratégies que vous transmettez dans vos modèles pour déterminer comment les attributions sont effectuées. En les utilisant, vous pouvez généralement contourner les problèmes de mémoire qui posent problème sur la plate-forme de votre choix.

Bien sûr, si vous utilisez la STL et faites des choses idiotes, telles que des cartes de chaînes de caractères de grande taille, sans type de pointeur, vous avez de plus gros problèmes.

La LIST par défaut présente de nombreux problèmes qui rendent son utilisation difficile avec les jeux, en particulier en ce qui concerne l’alignement de la mémoire.

Une variante personnalisée telle que la EA STL est spécialement conçue pour les jeux et peut vous permettre d’améliorer les performances de la mémoire et la convivialité de la console. Il est devenu open source en 2016, sous une clause BSD-3, avec un référentiel sur GitHub .

Voici ce que Mike Acton (directeur des moteurs chez Insomniac Games de Spyro the Dragon, de Ratchet & Clank et de la renommée de Resistance) avait à dire à ce sujet lorsqu'il a été interrogé ici . Notez qu'il a été interrogé sur STL et Boost en général en ce qui concerne l'utilisation dans le développement de jeux.

STL / Boost, appartient-il à gamedev? Si seulement des parties, lesquelles?

Vous parlez de deux choses différentes ici, non? STL et Boost, séparément. Mais en réalité, ma réponse est la même: il n’ya rien de mal à l’un ou l’autre, mais je décourage leur utilisation. L' utilisation de l' une encourage les gens à adapter une solution à un problème plutôt que de trouver une solution à un problème. La solution doit toujours être adaptée aux données disponibles, aux contraintes matérielles, etc. STL et Boost ont une vision extrêmement étroite du "monde" et leur utilisation appropriée est limitée. Vraiment, je les décourage, car ils guident tout de suite les programmeurs dans la mauvaise direction. Je dis souvent que si vous sentez que vous en avez besoin, vous ne comprenez probablement pas vraiment le problème que vous rencontrez.

J'ai également remarqué que la plupart des développeurs de jeux professionnels se tournent davantage vers le C que vers le C ++.

Si vous vous retrouvez en train de réécrire quelque chose qui existe déjà dans la STL, arrêtez pour une raison quelconque . Utilisez le STL.

La STL a été optimisée au fil des années d'analyse et de temps, et il y a fort à parier que vous n'écrirez probablement pas quelque chose qui soit plus efficace. Cela ne veut pas dire que vous devriez utiliser STL là où une solution plus simple peut être possible (par exemple, utilisez un tableau lorsque vous avez un nombre connu de choses, pas une liste stl :: list), mais si vous écrivez votre propre implémentation d'une carte ( la structure de données de base, pas une carte du monde du jeu), vous le faites mal.

Est-ce que STL convient aux jeux? Absolument. Les jeux sont des logiciels complexes, la STL fournit des fonctionnalités qui aident à gérer la complexité, donc c'est bien.

Est-ce un bon choix pour votre plate-forme? Pas nécessairement. Si vous écrivez pour une console, vous devez faire très attention à l'utilisation de la mémoire et du cache. La STL ne rend pas cela très facile.

Je pense que trop souvent, nous confondons les "jeux" avec les "jeux haute performance en temps réel fonctionnant sur du matériel embarqué ou sur mesure", mais il est important de faire la distinction. Si vous écrivez un jeu Windows qui n'essaie pas de fonctionner en plein écran à une cadence constante de 60 images par seconde, il n'y a aucune raison d'éviter les outils fournis par la bibliothèque standard.

Je sais que la soirée a pris beaucoup de retard, mais le temps change et les réponses restent. C ++ 11 a des changements radicaux, dont beaucoup sont destinés à améliorer les performances de C ++ et de la bibliothèque standard. Il semble que ceux qui n'utilisent ni le STL ni le Boost, ont tendance à ne pas suivre les nouvelles normes non plus, laissant les solutions filées à la maison sans améliorations importantes, bien sûr, ce n'est pas toujours le cas.

J'ai utilisé STL sur tous les projets du milieu des années 90 à aujourd'hui, à l'exception d'un court laps de temps chez EA. Je pense que le parti anti-STL avait des raisons peu rationnelles de ne pas l'utiliser. Ceux-ci sont en grande partie partis. Les allocateurs personnalisés sont une solution, l’utilisation de la réserve en est une autre, et ne pas passer les choses par valeur en est une troisième, mais elles sont assez simples et tout programmeur devrait les connaître. Plus important encore est l'utilisation d'algorithmes. Les rédacteurs du compilateur savent exactement ce que fait un for_each () et peuvent optimiser le code. Cela ne peut pas se produire avec une boucle roulée à la maison. for_each () sur un objet const est encore mieux. Microsoft optimise for_each de nombreuses manières, y compris la sérialisation. Ils ont également la bibliothèque AMP qui a parallel_for_each (). Si vous en avez l'occasion, parlez-en aux ingénieurs du compilateur. Les compilateurs de la console vont optimiser ce qui est utilisé, alors C'est un problème de poule et d'oeuf. Microsoft utilise beaucoup de C ++ 11 et la prochaine XBox ne sera pas différente. Je n'ai aucune idée de la PS4, nous n'en avons pas encore.

Les allocateurs personnalisés sont un moyen de traiter le problème de mémoire, mais une autre option (souvent négligée) consiste à utiliser les classes new et delete. Des augmentations de performances énormes peuvent être obtenues de cette façon.

La notion que Boost et STL ont une vision étroite de la résolution de problèmes est de la pure folie. Je suis stupéfait de voir combien de choses dans le TSL et dans Boost peuvent être personnalisées à l'aide de traits et de règles. Recherchez un exemple de comparaison de chaîne indépendante de la casse.

En ce qui concerne les temps de liaison longs et le gonflement du code, le nouveau modèle extern devrait vous aider. En général, les longs temps de compilation sont dus à un couplage excessif et à une mauvaise utilisation de pch.

La raison la plus convaincante d’utiliser STL au-dessus de l’animal domestique est que des millions de personnes peuvent vous aider à utiliser le STL. Comme toujours, n'optimisez pas prématurément et testez, testez, testez.

C'est un sujet brûlant dans le développement de jeux. Personnellement, je ne le recommande pas, sauf peut-être pour EASTL, comme mentionné ci-dessus. J'ai deux problèmes principaux avec STL (techniquement, "La bibliothèque standard C ++", car STL n'est plus son nom) dans les jeux. 1) L’allocation dynamique de mémoire gaspille souvent beaucoup de temps d’exécution dans les jeux lorsque STL est utilisé. 2) L’utilisation de STL encourage une approche de l’architecture de jeu basée sur un ensemble de structures, alors qu’une approche basée sur une structure de tableaux est beaucoup plus conviviale pour le cache.

Ça dépend. Quelle est la taille du projet, sur quelle (s) plate-forme (s) et quel est le calendrier?

Si vous travaillez sur un projet de grande envergure, sur des plates-formes aux ressources limitées, avec un échéancier et un budget importants, épargnez-vous beaucoup de problèmes en évitant l'inévitable enfer qui consiste à rechercher dans un demi-million de codes de lignes jonché de STL, ne peut pas conserver un framerate supérieur à 30, consomme suffisamment de RAM pour stocker plusieurs ressources et prend 2 heures pour le créer.

Dans d’autres situations, STL et même Boost peuvent être très utiles lorsqu’ils sont appliqués correctement. J'ai travaillé sur des titres qui utilisaient une sélection de STL / Boost et constituaient un rêve absolu pour le codage: moins de bugs / fuites et une maintenance facile du code signifient plus de temps pour coder de nouvelles fonctionnalités! Pour les projets de loisir en particulier, c'est une victoire énorme pour le service de la motivation.

Savoir quand échanger la performance pour plus de commodité!

IMHO Je dirais que c'est un bon choix, car STL fonctionne déjà bien et est optimisé pour les tâches pour lesquelles il est conçu. De plus, vous travaillez sur un jeu, alors utilisez les outils à votre disposition qui vous simplifient la vie et réduisent le risque de code pour les bugs.

Pourquoi se donner la peine de réinventer la roue alors que vous pouvez travailler sur quelque chose comme l'IA du jeu, l'expérience utilisateur, ou mieux encore; tester et déboguer?

STL convient parfaitement aux jeux, à condition de bien le comprendre. Notre moteur en fait un usage intensif et cela n'a jamais été un problème. Je n'ai aucune expérience du développement sur console, ce qui est peut-être une histoire totalement différente, mais il est bien pris en charge sur toutes les plates-formes PC (Windows / Mac / Linux).

La chose la plus importante est de comprendre quelles sont les forces et les faiblesses de chaque type de conteneur et de choisir le conteneur approprié pour le travail que vous effectuez.

Mon ancien employeur a abandonné l'utilisation d'un ensemble robuste de classes de conteneurs personnalisés au profit de STL. Les temps de construction ont augmenté et la facilité de débogage a été réduite de manière significative. Si nous étions partis de zéro, STL (peut-être mieux utilisé) aurait probablement eu un sens, mais il ne m'a jamais été clair que nous aurions gagné quoi que ce soit en passant à STL qui justifierait de jeter du code fonctionnel, rapide et débogable.

Pour mes projets personnels, si STL convient ou pas dépend du projet. Si j'essaie de faire un travail optimisé basé sur les données, l'optimisation de la mémoire et du cache de Mike Acton, je penserai au moins à la création de mes propres structures de données personnalisées. Si je prototype des algorithmes ou un gameplay et que je ne me soucie pas des performances, de l'évolutivité, de la plate-forme cible, etc., je récupère automatiquement STL.

Mes 2 cents sur ce point est que la STL fonctionne très bien. J'ai développé un moteur de jeu en 3D (pas de qualité AAA, mais assez avancé - types d'entités scriptés, rendu différé, physique Bullet intégrée) pour PC et je n'ai pas encore vu les conteneurs devenir le principal goulot d'étranglement. Une utilisation incorrecte des API 3D et de mauvais algorithmes ont été les meilleures cibles (déterminées par le profilage!) Chaque fois que j'y suis allé et que j'essayais d'obtenir un peu plus de performances.

J'ai construit des jeux en utilisant STL et je l'aime bien, et il semble bien performer.

Bonne question! Une question plus spécifique est de savoir quelles sont les exigences communes d’un jeu qui ne peuvent pas être satisfaites avec STL et Boost.

D'après mon expérience, les limites de mémoire limitées du matériel de la console font de tout type de conteneur de taille dynamique une idée fausse, quel que soit le niveau de sophistication de votre allocateur personnalisé. Les conteneurs qui n'ont pas de limite volontaire encouragent les programmeurs à écrire du code qui ne limite pas les limites de leurs ensembles de données. En fonction d'innombrables variables difficiles à suivre, vous pouvez dépasser vos limites de mémoire. J'ai l'impression que c'est l'une des principales causes d'instabilité dans les jeux modernes.

De plus, une utilisation excessive de modèles peut entraîner des temps de compilation très longs dans une base de code volumineuse et gonfler la taille de votre exécutable de sorte qu'il ne rentre plus dans le cache d'un noyau auxiliaire sur un ps3, par exemple.

Cependant, pour le développement uniquement sur PC, je pense que STL et Boost sont très bons. Bien que les solutions générales ne soient pas toujours idéales, elles sont souvent suffisantes. Votre première solution à un problème n’est presque jamais idéale et vous améliorez ou remplacez les insuffisances jusqu’à ce qu’il soit suffisamment bon.

La STL convient parfaitement à votre jeu si la STL convient parfaitement à votre jeu.

Comme pour tous les choix technologiques faits au cours du développement, vous devez peser le pour et le contre. Est-ce que rouler dans ma propre bibliothèque me donnera une utilisation de la mémoire, des performances et une productivité plus bénéfiques que d'utiliser simplement le STL? Peut-être; Cependant, il est tout aussi facile de créer une vectorimplémentation utilisant plus de mémoire, plus lente et nécessitant une maintenance importante pour rester fonctionnelle par rapport à ce qui existe déjà.

Les gens ne devraient pas éviter d'utiliser la STL dans leurs jeux, car d'autres personnes évitent d'utiliser la STL dans des jeux; ils devraient éviter de l'utiliser s'ils ont pesé toutes leurs options et s'ils sont sincèrement convaincus qu'une autre mise en œuvre améliorera la qualité de leur produit.

Comme pour la plupart des questions, la réponse n’est jamais "oui ou non", en noir ou en blanc. STL est un bon choix pour certains problèmes, son utilisation pour ces problèmes devrait bien se passer. C'est une erreur de supposer que c'est inutile, mais c'est aussi une erreur de supposer qu'il convient de l'utiliser dans toutes les situations.

L'allocation de mémoire est le principal problème à surveiller lors de l'utilisation de STL dans le développement de jeux. Les allocateurs par défaut de STL ne semblent pas bien s'intégrer aux stratégies d'allocation préférées pour le développement de jeux. Bien sûr, des allocateurs personnalisés peuvent être utilisés, mais cela rend l'idée moins attrayante si vous envisagez d'ajouter ou non STL à une base de code non-STL.

Ajoutez à cela que si votre base de code est non-STL, il est possible que personne ne soit assez familier avec les concepts de STL ou de modèles pour implémenter correctement les allocateurs personnalisés.

Je pense que cette discussion peut se résumer comme suit:

code médiocrement écrit spécifique à l'application <code d'usage général bien écrit <code spécifique à l'application bien écrit

Quiconque dont la solution locale tomberait dans la catégorie 3 connaît sûrement la réponse à la question initiale pour son problème particulier. Le TSL entre dans la catégorie 2. Donc, pour quelqu'un qui a besoin de poser la question «Devrais- je utiliser le TSL», la réponse est probablement oui.

STL convient parfaitement à un PC, car son système de mémoire virtuelle évolué rend la nécessité d’une allocation de mémoire prudente un peu moins cruciale (même s’il faut tout de même être très prudent). Sur une console, avec des ressources de mémoire virtuelle limitées ou inexistantes et des coûts de mémoire cache exorbitants, il est probablement préférable de ne pas écrire de structures de données personnalisées dotées de modèles d’allocation de mémoire prévisibles et / ou limités. (Et vous ne vous tromperez certainement pas en faisant la même chose sur un projet de jeu sur PC.)

Je pense que cette question est vraiment une grande question non posée - devrais-je utiliser X dans mon Y ? Et la seule façon de vraiment y répondre est de l'essayer soi-même. Pour chaque personne trouvée qui dit que X fonctionne très bien, vous trouverez quelqu'un qui dit que c'est horrible. Et tous deux ont raison - pour leur projet.

L'avantage des logiciels, contrairement à la plupart des autres disciplines, est que vous pouvez toujours changer les choses plus tard si vous trouvez que cela ne fonctionne pas comme vous le souhaitez. Vous découvrez plus tard que STL ne travaille pas pour vous dans ce projet? Arrache-le, mets quelque chose d'autre à sa place. Vous n'aimez pas la façon dont vous avez divisé les tâches entre vos objets? Refactor. Vous n'aimez pas que vous avez utilisé des objets? Remplacez-les par des méthodes droites en C. Vous n'aimez pas tout ce qui est stocké dans des structures et des méthodes pour les manipuler? Remplacez-les par des objets C ++.

Je dis non à la STL. Ma raison est assez simple:

1. Vous n'avez pas besoin de la STL pour écrire des jeux. Pas même les grands.
2. STL augmente considérablement votre temps de compilation.
3. Un temps de compilation important réduit le nombre d'itérations sur votre développement.

Je considère que le nombre d'itérations est de la plus haute importance. Je me tiens donc à l'écart du STL et de toute autre technique de développement qui ralentit les itérations (comme l'architecture pour le plaisir ou les langages de script qui doivent être compilés).

Des itérations coûteuses conduisent à d'énormes équipes de développement composées de personnes qui essaient de faire avancer les choses avec très peu de choses en réalité. Je l'ai vu et entendu, et l'un des coupables semble être la compilation des bibliothèques de modèles.