Il serait utile que vous expliquiez brièvement ce qui vous a donné l'idée, car c'est une idée très étrange pour le moins.
Konrad Rudolph
2
Considérant que Quake se fait en C .. ;-)
The Communist Duck
Je me posais juste cette question moi-même!
Jeff
2
On dirait que par «jeux de l'industrie», vous entendez ce qu'on appelle généralement les «titres AAA».
chaos
Réponses:
53
Dans un sens, C ++ est vraiment en train d'être remplacé - non seulement par C #, mais par une multitude d'autres langages. Mais si vous demandez, est-ce que cela va être complètement remplacé - alors la réponse est définitivement non .
En effet, C ++ est traditionnellement utilisé à deux titres. Tout d'abord, pour créer le moteur de jeu : les composants de bas niveau qui chargent les ressources, poussent les polygones à l'écran et calculent les nombres dans les simulations physiques. Deuxièmement, pour coder la logique du jeu : les règles réelles qui font le gameplay.
Cette deuxième capacité ne nécessite pas les points forts de C ++ (comme un contrôle complet sur les détails de bas niveau), mais souffre de ses faiblesses (telles que la gestion de la mémoire codée à la main sujette aux bogues). Et dans cette deuxième capacité, C ++ est remplacé par différents langages de script. Beaucoup de développeurs utilisent Lua; certains utilisent Python. Mais si une plate-forme CLI est disponible, sous la forme de .NET ou Mono, elle présente un excellent candidat hôte de script. Ces plates-formes sont assez rapides, fiables, offrent un langage largement connu (C #) et une bibliothèque de classes de base complète. N'oublions pas les outils: MS Visual studio et SharpDevelop / MonoDevelop ne sont peut-être pas les meilleurs IDE au monde, mais ils sont assez bons.
Cela dit, le moteur de jeu ne sera pas écrit en C # (ni Lua, ni Python d'ailleurs). Pourquoi? Parce qu'ils ne sont tout simplement pas assez rapides.
Contrairement à de nombreuses croyances populaires, le plus gros succès de performance aujourd'hui est dû à la latence de la mémoire . Cela signifie que l'accès à la mémoire est une affaire sérieuse. Et les langages gérés ne permettent pas à l'utilisateur de contrôler l'accès à la mémoire - c'est précisément pourquoi ils sont "gérés" en premier lieu. Aucun langage géré ne permettra donc d'écrire un moteur de jeu très rapide. En fait, tous les gros moteurs "C #" auxquels je peux penser - XNA, MOGRE, Unity - sont basés sur du code C ++ natif ; mais permet d'écrire la logique du jeu en C #.
Pour résumer : C # va être utilisé à la place de C ++ ou d'autres langages. Mais il ne remplacera jamais C ++, du moins jusqu'à ce que quelqu'un invente une mémoire sans latence et à accès instantané.
+1 Visual Studio est un très bon IDE. Même si c'est le côté obscur ...
Michael Coleman
1
Bah, d'après mon expérience, C # n'est pas assez rapide pour la simulation non plus, mais cela n'empêche pas les gens d'essayer.
BigSandwich
@Nevermind Qu'est-ce que les "langues gérées"?
Quazi Irfan
3
@iamcreasy Au sens large, par «langages gérés», je veux dire les langages qui s'exécutent sous une machine virtuelle qui inclut une forme de collecte des ordures et / ou de gestion de la mémoire. Plus strictement, les langues gérées sont des langues qui ciblent (une certaine implémentation de) Common Language Runtime, mais ma réponse ne s'applique pas seulement à elles.
Nevermind
À votre avis, les régimes de GC comptés par référence relèvent-ils de cette catégorie à la Vala?
weberc2
6
Le choix de la langue dépend fortement de la plate-forme. À l'heure actuelle, il semble vraiment peu probable que quoi que ce soit, sauf une plate-forme Microsoft, nécessite réellement .NET comme implémentation.
La sagesse conventionnelle dirait qu'une petite plate-forme devrait être proche du métal pour être performante, mais d'un autre côté, les plates-formes gérées sont plus sûres . C'est probablement la raison pour laquelle Windows Phone 7 vous oblige à utiliser .NET.
Il serait certainement intéressant que la nouvelle Xbox nécessite une plate-forme gérée. Si le matériel d'un téléphone peut le gérer (et il le fait), je pourrais certainement les voir l'utiliser sur une console pleine taille. Cela remuerait un peu l'écosystème de la console car il serait plus difficile d'écrire des jeux multi-plateformes sans écrire tout votre code de jeu dans un langage de script. Si c'est le cas, alors C # ne remplacerait pas C ++, mais cela irait de pair.
À l'heure actuelle, vous pouvez utiliser Mono comme back-end de script (similaire à ce que fait Unity), mais j'imagine que la plupart des fabricants de moteurs voudraient soit rouler le leur, soit utiliser quelque chose de plus compact comme Lua ou Python que C #.
Quoi qu'il en soit, il s'agit du bon outil pour le bon travail. De toute façon, vous devriez vraiment apprendre les deux langages, car C # facilite certaines choses (développement d'outils, développement de serveurs probablement, etc.), et vous ne pouvez pas utiliser autre chose que C ++ dans certains cas.
À partir de maintenant, 3 ans plus tard, l'état de C # pour le développement de jeux est beaucoup plus évolué. Mono-Project a repris XNA Game Studio et l'a rebaptisé MonoGame. SharpDX, SlimDX et OpenTK sont tous des wrappers opengl / directx très décents. Même quelques moteurs physiques en c # ont vu le jour. Mono / MonoGame vous permet de créer un jeu une fois et de le porter automatiquement sur Android, Linux, Mac OS, iOS, Xbox 360, PS3, PS4 et Wii.
Ryan Mann
3
Ce n'est pas probable. C ++ a l'avantage d'être de bas niveau afin que les développeurs puissent réellement modifier les moindres détails pour obtenir les meilleures performances possibles.
Avec C # et .NET, vous disposez d'une récupération de place, ce qui est très utile, mais lorsque vous travaillez avec des plates-formes à mémoire et ressources limitées (consoles portables et dans une certaine mesure, consoles domestiques), vous devez avoir autant de contrôle sur la mémoire que possible pour en faire le meilleur usage. des ressources. Permettre aux langues gérées de vous allouer et de libérer de la mémoire vous causerait très probablement beaucoup de problèmes.
La vitesse est également un problème (bien que probablement moins). Au fil du temps, je suis sûr que les langages gérés pourraient être conçus pour fonctionner de manière comparable aux compilateurs C ++.
Dans l'ensemble, d'après mon expérience, les développeurs de jeux ont tendance à être des fous de contrôle en matière de mémoire, de temps CPU et de ressources (pour obtenir autant de performances que possible), c'est pourquoi C / C ++ sont les langages principalement utilisés.
AFAIK .NET GC souffre toujours d' arrêter l' algorithme de style mondial . Bien que cela puisse convenir à une grande variété d'applications, c'est inacceptable pour les applications en temps réel comme les jeux.
En fait, il est très difficile d'utiliser efficacement les langages gérés pour les programmes en temps réel jusqu'à ce que nous ayons quelques percées dans GC.
Non. En fonction de .NET, cela impliquerait des réécritures massives pour les plates-formes sans Framework disponible, comme la PS3, et les inconvénients de performances peuvent être parfaitement acceptables sur le PC ou pour les jeux Live Arcade, mais les jeux plus grands auront besoin de chaque morceau de performances de leurs consoles pour fonctionner assez rapidement. Plus que cela, il existe d'énormes bases de code existantes en C ++ que personne ne pouvait se permettre de mettre à niveau, même s'il le voulait. Le C ++ est dans l'industrie du jeu et il va y rester longtemps.
Bien que l'inertie existe, les bases de code C ++ ne sont pas elles-mêmes aussi vieilles - peut-être 10 ans au plus. Presque tout le code qu'ils contiennent a été remplacé au cours de cette période - pour les accélérateurs 3D, les pipelines programmables, les architectures pilotées par les données et la prise en charge des scripts. Si un développeur AAA voulait effectuer une migration complète vers C #, il pourrait probablement l'accomplir pour un coût minimal en l'espace de trois jeux - l'utiliser d'abord comme outil et hôte de script, déplacer ensuite les couches logiques du jeu vers lui et le troisième port le moteur de rendu pour utiliser un wrapper DX / GL géré.
1
Mono a une solution commerciale .NET pour PS3.
Dan Olson
Appuyé, si vous construisez votre jeu en c # contre mono ou avec monogame (remplacement xna), vous pouvez le porter sur ps3 / ps4, wii, xbox 360, android, max os, etc. intégré.
Ryan Mann
0
À une époque où la puissance de l'ordinateur était rare, tout devait être programmé en C ou C ++, simplement parce que les langages récupérés détournent le contrôle de la mémoire du programmeur, et donc les performances peuvent chuter.
De nos jours, les ordinateurs sont plus rapides, mais comme le dit Knuth et pour faire court, l'optimisation peut être mauvaise:
il est évident que les fonctionnalités de base de bas niveau doivent être optimisées, car le calcul de la géométrie 3D, de la physique, des collisions, de l'éclairage peut rapidement faire gonfler le meilleur processeur disponible. Vous pouvez facilement dire que l'augmentation de la qualité visuelle sur une machine tue presque toujours considérablement les performances.
Maintenant, il existe d'autres fonctionnalités, telles que les états de jeu, l'IA, le son, l'entrée, le réseau, qui sont toujours importantes dans un jeu, mais qui ne prendront presque jamais autant de ressources informatiques. Ces fonctionnalités, la plupart du temps, ne doivent pas être optimisées. C'est le but du langage de script et des langages récupérés: vous n'avez pas à penser à la cohérence de votre mémoire et à l'organisation de votre application, car le code que vous écrirez avec ces langages, si vous ne codez pas des trucs de bas niveau, ne sera jamais un goulot.
Exemple avec 2 cas
Expédiez 500 kg de meubles avec un camion.
Expédiez 30 tonnes de matériel avec un bateau.
les deux sont à 500 km de distance.
Dans les deux cas, est-il important d'accélérer le processus de chargement / déchargement pour raccourcir le temps de transport, sachant que vous CANT rendez le bateau ni le camion plus rapides?
La réponse est: cela importait avec le camion, mais plus avec le bateau, car vous avez déjà beaucoup fait en déplaçant le stock avec le bateau.
Je ne sais pas si vous comprenez cette métaphore, mais d'une certaine manière, cela peut vous faire imaginer le problème mathématique, qui est plus important que de comprendre la réponse.
Les langages de script permettent de rendre les jeux plus rapides si vous avez déjà un moteur programmé en C / C ++: le moteur 3D résout les problèmes de bas niveau, maintenant vous devez faire le jeu avec vos scripts.
Mais rappelez-vous: vous ne pourrez jamais remplacer le langage compilé de bas niveau, JAMAIS. Les langages compilés de manière statique sont au cœur des performances et vous NE POUVEZ PAS les exclure, que ce soit un noyau, un moteur 3D ou un pilote de carte graphique.
Mais bien sûr, si votre jeu est graphiquement simple et ne nécessite pas beaucoup de calculs vectoriels, vous pouvez vous concentrer sur le gameplay et oublier l'optimisation, car dans ce cas, vous n'aurez jamais à gérer l'optimisation car votre machine est très rapide pour ça
Sauf si vous prévoyez de porter ir sur la DS. Mais je m'arrête là.
"l'optimisation peut être mauvaise" est de loin la version la plus inutile de sa déclaration que j'ai lue.
eh bien je l'explique, c'est pourquoi j'ai trouvé inutile de citer toute sa déclaration, qui est une phrase assez longue et qui n'est pas vraiment expliquée ... En plus de ça, on parle de jeux, ce qui n'est pas pareil un logiciel plus large dont Knuth voulait parler.
jokoon
Vous mentionnez que la saisie ne prend presque jamais beaucoup de ressources informatiques. Je voudrais souligner que lorsque le joueur devient plus connecté physiquement au jeu, cela devient moins vrai. Par exemple, le kinect. C'est une forme d'entrée, mais nécessite de nombreuses ressources informatiques pour être utilisée.
Ponkadoodle
0
Écoutez, je sais que c'est une diatribe mais je ne fais pas que couper des cheveux. Je pense que la plupart des programmeurs ne mettent pas vraiment cela ensemble. Un langage lui-même n'a rien à voir avec la vitesse d'exécution / les performances. C'est le compilateur / framework. Vous pourriez mieux argumenter gcc contre cl (compilateur Microsoft pré 2010) ou msbuild (compilateur c ++ actuel pour 2010). À chaque version, ces compilateurs s'améliorent, vous devez également les comparer aux versions précédentes d'eux-mêmes. Je suis très impressionné par .net et il fonctionne bien mais même s'il était légèrement meilleur, je ne le vois pas prendre le dessus, une raison: la portabilité.
Les jeux AAA veulent être sur Windows, Linux, Mac, XBox, PS3, Nintendo, etc.
Certes, l'implémentation du compilateur joue un rôle, mais différents langages offrent différentes possibilités d'optimisation pilotée par le compilateur, et différentes possibilités pour les programmeurs de contourner les règles de langage habituelles et de parler directement au matériel. La langue et la cible en soi ont beaucoup à voir avec les performances.
Un langage peut avoir beaucoup à voir avec la vitesse d'exécution / les performances car la syntaxe et les bibliothèques standard favoriseront différentes approches. Par exemple, un langage dans lequel il est difficile d'utiliser des tableaux de mémoire contiguë en raison du fait que tous leurs objets sont des pointeurs aura tendance à détruire le cache beaucoup plus qu'un où vous pouvez utiliser efficacement des tableaux ou des vecteurs.
Kylotan
+1 très bon point, que vous auriez pu faire sans insulter les gens stupides, ils ne savent pas qui ils sont.
Fire Crow
Sauf qu'à partir d'aujourd'hui, vous pouvez construire contre mono et il se connecte à peu près à tout. Par exemple, il est désormais hautement portable.
Réponses:
Dans un sens, C ++ est vraiment en train d'être remplacé - non seulement par C #, mais par une multitude d'autres langages. Mais si vous demandez, est-ce que cela va être complètement remplacé - alors la réponse est définitivement non .
En effet, C ++ est traditionnellement utilisé à deux titres. Tout d'abord, pour créer le moteur de jeu : les composants de bas niveau qui chargent les ressources, poussent les polygones à l'écran et calculent les nombres dans les simulations physiques. Deuxièmement, pour coder la logique du jeu : les règles réelles qui font le gameplay.
Cette deuxième capacité ne nécessite pas les points forts de C ++ (comme un contrôle complet sur les détails de bas niveau), mais souffre de ses faiblesses (telles que la gestion de la mémoire codée à la main sujette aux bogues). Et dans cette deuxième capacité, C ++ est remplacé par différents langages de script. Beaucoup de développeurs utilisent Lua; certains utilisent Python. Mais si une plate-forme CLI est disponible, sous la forme de .NET ou Mono, elle présente un excellent candidat hôte de script. Ces plates-formes sont assez rapides, fiables, offrent un langage largement connu (C #) et une bibliothèque de classes de base complète. N'oublions pas les outils: MS Visual studio et SharpDevelop / MonoDevelop ne sont peut-être pas les meilleurs IDE au monde, mais ils sont assez bons.
Cela dit, le moteur de jeu ne sera pas écrit en C # (ni Lua, ni Python d'ailleurs). Pourquoi? Parce qu'ils ne sont tout simplement pas assez rapides.
Contrairement à de nombreuses croyances populaires, le plus gros succès de performance aujourd'hui est dû à la latence de la mémoire . Cela signifie que l'accès à la mémoire est une affaire sérieuse. Et les langages gérés ne permettent pas à l'utilisateur de contrôler l'accès à la mémoire - c'est précisément pourquoi ils sont "gérés" en premier lieu. Aucun langage géré ne permettra donc d'écrire un moteur de jeu très rapide. En fait, tous les gros moteurs "C #" auxquels je peux penser - XNA, MOGRE, Unity - sont basés sur du code C ++ natif ; mais permet d'écrire la logique du jeu en C #.
Pour résumer : C # va être utilisé à la place de C ++ ou d'autres langages. Mais il ne remplacera jamais C ++, du moins jusqu'à ce que quelqu'un invente une mémoire sans latence et à accès instantané.
la source
Le choix de la langue dépend fortement de la plate-forme. À l'heure actuelle, il semble vraiment peu probable que quoi que ce soit, sauf une plate-forme Microsoft, nécessite réellement .NET comme implémentation.
La sagesse conventionnelle dirait qu'une petite plate-forme devrait être proche du métal pour être performante, mais d'un autre côté, les plates-formes gérées sont plus sûres . C'est probablement la raison pour laquelle Windows Phone 7 vous oblige à utiliser .NET.
Il serait certainement intéressant que la nouvelle Xbox nécessite une plate-forme gérée. Si le matériel d'un téléphone peut le gérer (et il le fait), je pourrais certainement les voir l'utiliser sur une console pleine taille. Cela remuerait un peu l'écosystème de la console car il serait plus difficile d'écrire des jeux multi-plateformes sans écrire tout votre code de jeu dans un langage de script. Si c'est le cas, alors C # ne remplacerait pas C ++, mais cela irait de pair.
À l'heure actuelle, vous pouvez utiliser Mono comme back-end de script (similaire à ce que fait Unity), mais j'imagine que la plupart des fabricants de moteurs voudraient soit rouler le leur, soit utiliser quelque chose de plus compact comme Lua ou Python que C #.
Quoi qu'il en soit, il s'agit du bon outil pour le bon travail. De toute façon, vous devriez vraiment apprendre les deux langages, car C # facilite certaines choses (développement d'outils, développement de serveurs probablement, etc.), et vous ne pouvez pas utiliser autre chose que C ++ dans certains cas.
la source
Ce n'est pas probable. C ++ a l'avantage d'être de bas niveau afin que les développeurs puissent réellement modifier les moindres détails pour obtenir les meilleures performances possibles.
Avec C # et .NET, vous disposez d'une récupération de place, ce qui est très utile, mais lorsque vous travaillez avec des plates-formes à mémoire et ressources limitées (consoles portables et dans une certaine mesure, consoles domestiques), vous devez avoir autant de contrôle sur la mémoire que possible pour en faire le meilleur usage. des ressources. Permettre aux langues gérées de vous allouer et de libérer de la mémoire vous causerait très probablement beaucoup de problèmes.
La vitesse est également un problème (bien que probablement moins). Au fil du temps, je suis sûr que les langages gérés pourraient être conçus pour fonctionner de manière comparable aux compilateurs C ++.
Dans l'ensemble, d'après mon expérience, les développeurs de jeux ont tendance à être des fous de contrôle en matière de mémoire, de temps CPU et de ressources (pour obtenir autant de performances que possible), c'est pourquoi C / C ++ sont les langages principalement utilisés.
la source
AFAIK .NET GC souffre toujours d' arrêter l' algorithme de style mondial . Bien que cela puisse convenir à une grande variété d'applications, c'est inacceptable pour les applications en temps réel comme les jeux.
En fait, il est très difficile d'utiliser efficacement les langages gérés pour les programmes en temps réel jusqu'à ce que nous ayons quelques percées dans GC.
la source
Non. En fonction de .NET, cela impliquerait des réécritures massives pour les plates-formes sans Framework disponible, comme la PS3, et les inconvénients de performances peuvent être parfaitement acceptables sur le PC ou pour les jeux Live Arcade, mais les jeux plus grands auront besoin de chaque morceau de performances de leurs consoles pour fonctionner assez rapidement. Plus que cela, il existe d'énormes bases de code existantes en C ++ que personne ne pouvait se permettre de mettre à niveau, même s'il le voulait. Le C ++ est dans l'industrie du jeu et il va y rester longtemps.
la source
À une époque où la puissance de l'ordinateur était rare, tout devait être programmé en C ou C ++, simplement parce que les langages récupérés détournent le contrôle de la mémoire du programmeur, et donc les performances peuvent chuter.
De nos jours, les ordinateurs sont plus rapides, mais comme le dit Knuth et pour faire court, l'optimisation peut être mauvaise:
il est évident que les fonctionnalités de base de bas niveau doivent être optimisées, car le calcul de la géométrie 3D, de la physique, des collisions, de l'éclairage peut rapidement faire gonfler le meilleur processeur disponible. Vous pouvez facilement dire que l'augmentation de la qualité visuelle sur une machine tue presque toujours considérablement les performances.
Maintenant, il existe d'autres fonctionnalités, telles que les états de jeu, l'IA, le son, l'entrée, le réseau, qui sont toujours importantes dans un jeu, mais qui ne prendront presque jamais autant de ressources informatiques. Ces fonctionnalités, la plupart du temps, ne doivent pas être optimisées. C'est le but du langage de script et des langages récupérés: vous n'avez pas à penser à la cohérence de votre mémoire et à l'organisation de votre application, car le code que vous écrirez avec ces langages, si vous ne codez pas des trucs de bas niveau, ne sera jamais un goulot.
Exemple avec 2 cas
les deux sont à 500 km de distance.
Dans les deux cas, est-il important d'accélérer le processus de chargement / déchargement pour raccourcir le temps de transport, sachant que vous CANT rendez le bateau ni le camion plus rapides?
La réponse est: cela importait avec le camion, mais plus avec le bateau, car vous avez déjà beaucoup fait en déplaçant le stock avec le bateau.
Je ne sais pas si vous comprenez cette métaphore, mais d'une certaine manière, cela peut vous faire imaginer le problème mathématique, qui est plus important que de comprendre la réponse.
Les langages de script permettent de rendre les jeux plus rapides si vous avez déjà un moteur programmé en C / C ++: le moteur 3D résout les problèmes de bas niveau, maintenant vous devez faire le jeu avec vos scripts.
Mais rappelez-vous: vous ne pourrez jamais remplacer le langage compilé de bas niveau, JAMAIS. Les langages compilés de manière statique sont au cœur des performances et vous NE POUVEZ PAS les exclure, que ce soit un noyau, un moteur 3D ou un pilote de carte graphique.
Mais bien sûr, si votre jeu est graphiquement simple et ne nécessite pas beaucoup de calculs vectoriels, vous pouvez vous concentrer sur le gameplay et oublier l'optimisation, car dans ce cas, vous n'aurez jamais à gérer l'optimisation car votre machine est très rapide pour ça
Sauf si vous prévoyez de porter ir sur la DS. Mais je m'arrête là.
la source
Écoutez, je sais que c'est une diatribe mais je ne fais pas que couper des cheveux. Je pense que la plupart des programmeurs ne mettent pas vraiment cela ensemble. Un langage lui-même n'a rien à voir avec la vitesse d'exécution / les performances. C'est le compilateur / framework. Vous pourriez mieux argumenter gcc contre cl (compilateur Microsoft pré 2010) ou msbuild (compilateur c ++ actuel pour 2010). À chaque version, ces compilateurs s'améliorent, vous devez également les comparer aux versions précédentes d'eux-mêmes. Je suis très impressionné par .net et il fonctionne bien mais même s'il était légèrement meilleur, je ne le vois pas prendre le dessus, une raison: la portabilité.
Les jeux AAA veulent être sur Windows, Linux, Mac, XBox, PS3, Nintendo, etc.
la source