XNA et C # vs les 360 dans le processeur de commande

Après avoir lu cette diatribe , je pense qu'ils ont probablement raison (vu que le Xenon et le CELL BE sont tous deux très sensibles aux codes ignorants branchés et cache ), mais j'ai entendu dire que les gens font aussi bien les jeux avec C #.

Alors, est-il vrai qu'il est impossible de faire quelque chose de professionnel avec XNA, ou l'affiche manquait-elle juste ce qui fait de XNA l'API de tueur pour le développement de jeux?

Par professionnel, je ne veux pas dire dans le sens où vous pouvez gagner de l'argent, mais plutôt dans le sens où les jeux les plus professionnels ont des modèles phsyics et des systèmes d'animation qui semblent hors de portée d'un langage avec des barrières bien définies à l'intrinsèque. . Si je voulais écrire un système de collision ou un moteur de dynamique des fluides pour mon jeu, je n'ai pas l'impression que C # m'offre la chance de le faire car le générateur de code d'exécution et le manque d'intrinsèques entravent les performances.

Cependant, beaucoup de gens semblent bien travailler avec ces contraintes, rendant leurs jeux réussis mais évitant apparemment tous les problèmes par omission. Je n'ai remarqué aucun jeu XNA faisant autre chose que ce qui est déjà fourni par les bibliothèques ou géré par des shaders. Cet évitement de la dynamique de jeu plus complexe est-il dû aux limitations de C # , ou simplement à des gens qui se concentrent pour le faire ?

En toute honnêteté, je ne peux pas croire que la guerre de l'IA puisse maintenir de nombreuses unités d'IA sans une approche orientée données, ou quelques hacks C # sales pour la faire fonctionner mieux que l'approche standard, et je suppose que c'est en partie ma question aussi, comment des gens ont piraté C # pour pouvoir faire ce que les codeurs de jeux font naturellement avec C ++?

OK, juste pour percer quelques trous dans cette diatribe que vous avez liée:

• "C # s'appuie sur un interpréteur" Just In Time "" - faux - c'est un compilateur JIT . Une fois qu'une méthode est JITtée une fois , le code compilé est réutilisé pour chaque appel. Le code compilé est très proche du code natif précompilé.
• "CPU Xenon est un processeur" en place " - veut-il dire" dans l'ordre "? - Et: "Le processeur Xenon n'a pas de prédiction de branche" . Il implique que cela signifie que la compilation JIT produit naturellement du mauvais code qui doit être réorganisé par le CPU et provoque beaucoup de branchements - ce qui est un non-sens absolu . Les mêmes conseils de performances pour l'exécution sur cette architecture CPU s'appliquent à la fois à C ++ et C #.
• "[JIT] nécessite un vidage constant sur le 360" - faux, le code compilé peut être conservé dans le cache comme tout code normalement compilé. (S'il veut dire rinçage du pipeline, voir le point ci-dessus.)
• "génériques [...] utilisent la génération de code" - les génériques sont JITted comme tout le reste et, comme tout le reste, le code JITted est rapide. Il n'y a pas de pénalité de performance pour l'utilisation de génériques.
• "tous les éléments sexy du langage [...] nécessitent une prédiction de branche ..." - comment cela ne s'applique-t-il pas également au C ++? - "... ou [...] génération de code sur place" - veut-il dire JITting? Ai-je mentionné que c'est rapide? (Je n'entrerai pas dans tous les endroits où le CLR de bureau utilise la génération de code réelle - une fonctionnalité non prise en charge par la Xbox 360!)
• "[C # n'a pas] les bibliothèques massives [de C ++]" - sauf, disons, XNA lui-même? Et bien plus . (Pourtant, c'est un point assez juste.)

XNA sur la Xbox 360 s'exécute sur une version modifiée du .NET Compact Framework CLR. Je ne doute pas que ce n'est pas à la hauteur de la version de bureau. Le JITter n'est probablement pas aussi bon - mais je ne pense pas que ce soit mauvais non plus. Je suis surpris qu'il n'ait pas mentionné le garbage collector qui est affreux par rapport au CLR de bureau.

(Bien sûr - vous ne devriez pas frapper le garbage collector dans un jeu développé par des professionnels de toute façon , comme vous devez être prudent avec les allocations dans tout jeu de qualité professionnelle.)

(Pour une discussion technique réelle du .NET Compact Framework, commencez peut-être par cette série d'articles: Présentation , Compilateur JIT , GC et tas .)

La façon dont il est entièrement imprécis sur sa terminologie rend difficile de comprendre ce qu'il veut dire. Soit il est en mode délire maximum, soit il ne sait pas de quoi il parle.

Maintenant que nous avons obtenu que sur le chemin, voici quelques choses que vous ne manquez pas sur en utilisant XNA sur la 360, plutôt que d' aller natif :

• Accès à l'unité SIMD / Vector pour effectuer des calculs en virgule flottante CPU vraiment, très rapides
• Possibilité d'utiliser du code en langue native qui sera probablement un peu plus rapide que C #
• Capacité à être un peu plus paresseux avec la façon dont vous allouez la mémoire
• Les jeux XBLIG n'ont accès qu'à 4 des 6 cœurs (mais nous avons toujours les 3 processeurs, et ils ne sont pas non plus pleins, donc nous ne manquons pas grand-chose) - je ne sais pas si cela s'applique aux non-XBLIG XNA Jeux
• Accès DirectX complet pour faire de la supercherie graphique vraiment obscure

Il convient également de souligner qu'il ne s'agit que de restrictions côté processeur. Vous avez toujours un accès entièrement gratuit sur le GPU.

J'ai décrit ces choses dans cette réponse à ce qui est effectivement la même question que celle-ci. Comme je l'ai mentionné dans cette réponse, XNA convient parfaitement au développement "professionnel" .

Les seules raisons que vous éviteriez sont que vous ne pouvez pas embaucher de talents C #, licencier des moteurs C # et réutiliser le code C # existant de la même manière que vous le faites avec la base existante de connaissances C ++. Ou parce que vous ciblez également une plate-forme qui ne prend pas en charge C #.

Bien sûr, pour beaucoup d'entre nous qui ne sont pas des développeurs "professionnels", XNA est notre seule option pour accéder à la Xbox 360, ce qui est discutable.

Pour répondre à vos autres questions:

Rien en C # vous arrête d' utiliser des approches axées sur des données essentiellement exactement de la même façon que vous les utiliser en auriez C ++.

C # n'a pas la capacité de coder automatiquement le code en ligne au moment de la compilation, et (sans aller vérifier), je suis presque sûr que le JITter du CLR compact ne peut pas intégrer les méthodes (le CLR de bureau le peut). Ainsi, pour le code essentiel aux performances, vous devrez peut-être vous aligner manuellement en C #, où C ++ fournit une assistance.

Une raison plus importante pour laquelle vous ne voyez pas souvent des choses intensives en CPU comme la détection de collision et les simulations fluides en C # est le manque d'accès à l'unité vectorielle (comme mentionné ci-dessus).

Il faudrait définir «professionnel». Pourriez-vous faire Angry Birds, Plants vs Zombies, etc.? Absolument. Pourriez-vous faire Crysis 2, COD, Halo? J'en doute. L'utilisation de C # ne va vraiment avoir un impact que sur les jeux qui sont très gourmands en CPU et doivent également comprimer chaque dernier octet de mémoire (vous perdez à la collecte des ordures), donc il y a encore beaucoup à faire.

En tant qu'outil d'apprentissage pour les débutants, outil de prototypage, plate-forme pour écrire des jeux qui peuvent faire face au compromis, etc., c'est fantastique et a beaucoup de puissance et de simplicité, il n'est tout simplement pas conçu pour faire ce que vous feriez nécessairement appelez les jeux «AAA». Cela enlève également beaucoup de douleur et de souffrance dont les gens doivent s'inquiéter avec le portage et la compatibilité multiplateforme.

Si vous proposez un jeu incroyable et que vous rencontrez les limites de ce que vous pouvez faire avec XNA, je vous suggère de contacter MS directement, si l'idée est vraiment assez bonne, ils pourraient simplement vous permettre de mettre la main sur un développement complet trousse.

Le simple fait est que vous n'avez pas besoin d'un nombre de polygones élevé, d'un éclairage Full HDR ou de la physique la plus intéressante du monde pour créer un jeu intéressant, et si votre plan de jeu n'en inclut aucun, alors pourquoi ne pas opter pour un jeu plus rapide solution de temps de développement?

des jeux plus professionnels ont des modèles physiques et des systèmes d'animation

C'est juste faux. Les jeux professionnels ont ce dont ils ont besoin pour mettre en œuvre leur gameplay et atteindre leur look artistique, et rien de plus et en effet, rien de moins. Un jeu n'est pas plus professionnel car il a l'air plus réaliste ou a une physique plus détaillée. Un jeu professionnel atteint son gameplay et ses objectifs visuels, dans les délais, le budget, etc., et est expédié et fait un profit.