Comparaison entre XNA et DirectX (C #)
En termes de développement PC (hors Xbox et Zune),
Quelle est la différence entre XNA et C # DirectX? C # DirectX a-t-il un avantage significatif sur XNA (en termes de vitesse, de redevances, etc.)?
Comment sont les deux par rapport à la vitesse C++ DirectX non managé?
Où évolue l'industrie en termes de programmation de jeux?
Si vous êtes réellement doué pour écrire du code non managé, vous pourrez probablement écrire un moteur graphique plus rapide au-dessus de DirectX. Cependant, pour l'amateur, XNA a beaucoup de performances, à la fois pour le développement de jeux 2D et 3D.
Voici une bonne vidéo de Channel 9 où ils exécutent un jeu de course construit sur XNA sur Xbox 360. Il fonctionne bien même en Full HD. Plusieurs des jeux XBox Live Arcade ont été développés par la communauté XNA.
En ce qui concerne C # DirectX, si je me souviens bien, Managed DirectX, comme on l'appelait, n'est plus officiellement pris en charge, car XNA le remplace essentiellement. Je peux me tromper, ça fait très longtemps que je ne l'ai pas regardé.
Les différences de performances sont négligeables entre XNA et Managed DirectX car, en substance, c'est la même chose; XNA n'a que quelques bits pratiques pour réduire la quantité de code standard que vous devez écrire.
Les trucs de Xna Game Studio sont axés sur la résolution de problèmes centrés sur le jeu, bien que je remette en question toute affiche qui dit que les performances des trucs de Xna Game Studio sont pires que celles gérées directement x sans voir des mesures décentes.
Un groupe indépendant en dehors de MS a créé un projet appelé SlimDx - http://slimdx.mdxinfo.com/ Si vous écrivez une application plutôt qu'un jeu (ce que je suppose que vous n'êtes pas l'un par l'autre) questions) alors cela pourrait valoir la peine d'être considéré.
L'industrie utilise encore fortement C++ pour les tripes de jeu, mais il y a eu des versions réussies de jeux écrits en code entièrement géré à l'aide de XNA Game Studio dans la section des jeux communautaires de XBox live, et publiés sur la XBox Arcade elle-même. Il devrait y avoir très bientôt des statistiques intéressantes sur le nombre de personnes ayant gagné sur les jeux communautaires.
De nombreux jeux à prix plein utilisent C++ pour certains, mais quelque chose comme Lua pour la logique du jeu ... et Lua n'est pas connu pour la vitesse fulgurante!
C # a une bonne courbe d'apprentissage et est utilisé par les programmeurs d'outils de l'industrie - ce serait un langage utile à avoir sous votre ceinture. Le C++ serait un excellent langage, mais il nécessite plus de discipline pour créer du code fonctionnel - et donne à quelqu'un de nouveau beaucoup plus de corde pour se tenir. C # peut changer dynamiquement et faire des choses comme dérouler des boucles au moment de l'exécution plutôt que de compiler - un bon C # peut être aussi rapide ou plus rapide qu'un bon C++ lisible - mais vous devez savoir comment l'utiliser. Dans les boucles vraiment serrées, C++ et Assembler peuvent gagner dans certaines circonstances. Souvent dans les jeux utilisant C++, les allocateurs personnalisés sont créés avec leurs propres stratégies de mémoire pour essayer d'aider à la fragmentation causée par les allocateurs normaux ... ce genre de chose est traité par le CLR dans .Net/C # et aussi longtemps que vous programmez sur le les points forts des récupérateurs (les mêmes que vous auriez à faire avec votre propre implémentation C++), vous n'avez donc pas à vous préoccuper de ces détails d'implémentation de bas niveau dans .Net.
Si vous cherchez à vous lancer dans le développement de jeux et à choisir une langue (qui, la lecture entre les lignes semble être l'endroit où vous allez avec cette ligne de questionnement), alors la meilleure langue à utiliser est celle où vous avez terminé projet à montrer à la fin de celui-ci, que ce soit C++, Objective C, C #, Flash, Silverlight, etc. Alors que les langues changent et vont et viennent en faveur, les recruteurs recherchent souvent une maîtrise éprouvée de différentes langues - ce qui pourrait atténuer l'ignorance celui qu'ils utilisent actuellement - et un portefeuille de travaux achevés le ferait.
- XNA et DirectX sont des implémentations très différentes pour résoudre le même problème - une programmation graphique intensive. Les deux prennent en charge les composants 2D, 3D, audio et réseau. DirectX n'est pas géré uniquement lorsque XNA est du code géré.
- Il existe une implémentation gérée de DirectX qui est un wrapper autour des appels DirectX mais qui n'est pas mis à jour après la version actuelle, donc je ne m'embêterais pas avec.
- XNA n'est pas un wrapper autour de DirectX non managé. Il utilise des parties de DirectX mais ce n'est pas un wrapper.
- L'industrie semble toujours très dépendante de DirectX non managé - je dis cela parce que toutes les grandes sociétés de moteurs codent toujours en C++, ASM et prennent en charge DirectX (soit uniquement, soit en conjonction avec OpenGL pour les versions Linux/Mac). Le fait que Microsoft "abandonne" l'encapsuleur géré DirectX et indique aux gens d'utiliser plutôt XNA montre que c'est là qu'ils poussent les développeurs gérés.
Pour le moment, il semble que Microsoft n'envisage pas de prendre en charge XNA dans les applications de style Metro. Une alternative à XNA et au "Managed DirectX" désormais obsolète est SharpDx . Cela peut être utilisé pour créer des applications de style Metro et a été favorablement comparé contre XNA, SlimDX et le pack de code API Windows.