Discussion :

[SBHR_]

Quel avenir pour le C# dans les jeux vidéos ?
Pourra-t-il concurrencer le C++ dans un futur proche ?

Les jeux vidéo sont aujourd'hui souvent développés à l'aide du langage C++.
Un indicateur fiable sont les offres d'emploi dans les studios de développement.

Pourtant, aujourd'hui, quelquefois, des connaissances en C# commencent à être demandées.
Cela reste rare.

J'ai posé directement la question suivante : "Hello. Do you think that C# will replace C++ in studios in a near future?"
à Stefan Boberg (directeur technique du Frosbite Engine chez EA DICE) et à Christopher Kline (directeur technique d'Irrational Games).

Voici leur réponse :
- Stefan Boberg : "Hi, no it will not replace C/C++ for AAA games at least. It may be used as a supplement though, for higher-level gameplay code."
- Christopher Kline : "not for AAA console titles. XBLA and other smaller games are already using it."

John Carmack (fondateur et directeur technique d'Id Software) a même écrit récemment :"if you are just starting, java or c# might be better than c++" et "all the snarky comments about shooting yourself in the foot with C and C++ are true. C# and java trade some perf for some safety."

Quel est votre avis sur le sujet?

[LittleWhite]

Bonjour,

Vous avez de très bons contacts

Je pense à peu près la même chose, notamment car je suis dans une école de jeux vidéos.
Le C#, c'est ultra pour faire des trucs du genre:
- Interface utilisateur (outils par exemple)
- Communication avec internet
- Développement rapide de petite application.
- Très bonne intégration Windows

Comme le marché commence un peu à s'orienter vers des portage Mac OS X (Starcraft2, Steam ...) le C# est a évité (car pas supporté sur Mac OS X).

Donc un premier point négatif.

Le deuxième point, important, qui est négatif, c'est la très mauvaise intégration de DirectX en C#. Y a eu XNA, mais on dirait que Microsoft abandonne un peu ce truc pour s'orienté sur Windows Phone 7. (Voir la fusion du SDK de WP7 et de XNA4).

De plus, y a cette héritage de perte de performance entre une application purement compilé et une application en byte code (quelque soit le nom que donne Microsoft à ce code à moitié compilé).

Voilà.

Mais je vais revenir sur un point. C# peut être utilisé dans les compagnies de jeux videos (comme python aussi (Eutechnix le fait)). Pour les outils, et le scripting (python).

Les outils en C# == une interface rapide à faire, développement rapide, pas besoin de trop de performance. Ainsi, j'ai un ami qui a été embauché principalement pour faire des outils en C# aidant les diverses équipes à développer le jeux (Ubisoft 'Reflections' Newcastle).

Sinon, même les jeux pour la Xbox ou PS3 sont en C++.

Pourquoi le C++ est aussi un avantage:
- Liberté maximale (qui est souvent dangereuse), cela permet de réimplementer les Memory "Manager" (clin d'oeil pour Emmanuel Deloget), mais pas seulement.
- Performance maximale. Le code compilé est optimisé pour la machine.
- Portabilité (même si dans les jeux vidéos, on évite). Quoique, PS3 et Wii sont tout de même des machines qui ne supportent pas trop le C#, mais qui ont un compilateur C++.
- Et puis finalement, le C++ a un héritage historique, une présence dans les esprits qui sera certainement longue à enlever.

Voilà ce que je peux en dire.

[Mat.M]

Le deuxième point, important, qui est négatif, c'est la très mauvaise intégration de DirectX en C#. Y a eu XNA, mais on dirait que Microsoft abandonne un peu ce truc pour s'orienté sur Windows Phone 7.

il n'y a plus de Managed Direct X.
Donc utiliser C# pour faire un jeu sous Windows ne présente pas d'intérêt à mon sens sauf si on prend le SDK de XNA ou bien Irrlicht .NET par exemple

[Mat.M]

Bonjour,
Les jeux vidéo sont aujourd'hui souvent développés à l'aide du langage C++.
Un indicateur fiable sont les offres d'emploi dans les studios de développement.
Pourtant, aujourd'hui, quelquefois, des connaissances en C# commencent à être demandées.
Cela reste rare.
.

C# n'est pas très répandu pour les jeux vidéos.
Sauf dans certains cas : par exemple pour le studio qui utilise Unity Engine ce qui semble se faire de plus en plus , il faut maitriser C# parce que le SDK de Unity utilise .NET ( avec Boo ou C#)
Sinon une large partie des middlewares de jeux et moteurs "faits maisons" sont en C++
Donc je vois mal les studios de jeux vidéos refaire leurs outils et middleware en C# ça coûterait une fortune pour un résultat et une pertinence fort improbables.

[oxyde356]

Je pense que le duo C#/XNA est très bien pour faire des petits jeux. Mais pour les AAA il n'y a toujours pas de remplaçant au C++ en vue.

[iliak]

Salut,

Je rajoute mon petit grain de sel car je lis des trucs qui ne sont pas totalement vrais.

Tout d'abord le framework .Net, et le C# en l'occurence, tourne principalement sur du Microsoft, mais aussi sur d'autres plateformes (cf wikipedia). Le langage est normalisé, donc portable. De plus Microsoft a ouvert une partie du framework (cf wikipedia à nouveau). Pour une utilisation de .Net sur Mac, il existe une version de Mono. Je ne pousse pas plus loin car je n'utilise le framework .Net uniquement sur du Microsoft.
Niveau performances, le .Net n'a pas à rougir comparé à du C/C++, bien au contraire ! Il faut abandonner l'idée que de l'interprété sera toujours plus lent que du binaire (cf toujours wikipedia)


Il est vrai que DirectX est une horreur avec .Net. Pour cela, Microsoft a sorti XNA. Pour le moment, il n'est absolument pas question pour Microsoft de laisser tomber Xna, bien au contraire ! On peut utiliser Xna sur du Windows, de la XBox et sur le Windows Phone. Si tu fais des recherches sur amazon (par ex), tu peux trouver plus en plus de bouquins qui abordent le sujet. Par exemple : [ame="http://www.amazon.com/Game-Programming-Serious-Creation/dp/1435455568"]Amazon.com: C# Game Programming: For Serious Game Creation (9781435455566): Daniel Schuller: Books@@AMEPARAM@@http://ecx.images-amazon.com/images/I/515moWPaXoL.@@AMEPARAM@@515moWPaXoL[/ame]par exemple).

Bref, il faut envisager que le C# (ou le VB.Net accessoirement) puisse prendre de l'ampleur dans un avenir très proche et je partage pleinement l'avis de Carmack.

[LittleWhite]

Tout d'abord le framework .Net, et le C# en l'occurence, tourne principalement sur du Microsoft, mais aussi sur d'autres plateformes (cf wikipedia). Le langage est normalisé, donc portable. De plus Microsoft a ouvert une partie du framework (cf wikipedia à nouveau). Pour une utilisation de .Net sur Mac, il existe une version de Mono. Je ne pousse pas plus loin car je n'utilise le framework .Net uniquement sur du Microsoft.
Niveau performances, le .Net n'a pas à rougir comparé à du C/C++, bien au contraire ! Il faut abandonner l'idée que de l'interprété sera toujours plus lent que du binaire (cf toujours wikipedia)

Alors certes, il y a Mono (grand projet). Qui supporte jusqu'à .NET 2.0 je crois. Mais qu'en est il de DirectX (ou XNA) pour Mono ?
Car y a toujours pas de DirectX sous Mac ou GNU/Linux.

Et puis il est dur d'implémenter une Virtual Machine pour C# sans spécifications (et ça, Microsoft n'aime pas trop donné).

[oxyde356]

Niveau performances, le .Net n'a pas à rougir comparé à du C/C++, bien au contraire ! Il faut abandonner l'idée que de l'interprété sera toujours plus lent que du binaire (cf toujours wikipedia)

Et il faut arrêter de croire à des bêtises. Un programme écrit avec un langage interprété sera toujours moins rapide qu'un écrit avec un langage natif tout simplement parce que chaque opérations de base à une charge supplémentaire en interprété, c'est logique et toutes les optimisations qui existent et qui existeront ne serviront qu'à se rapprocher des performances des langages natifs mais ne pourront pas les atteindre.
C'est et ça sera toujours plus lent que du binaire, théoriquement, et concrètement, il suffit de faire quelques benchmark, par contre attention plein de fanboy des langages interprétés en font avec du langage natif mal écris et du coup forcément le résultat est totalement biaisé. Pour être sûr autant faire le benchmark soit même ou sinon être sûr de l'impartialité et de la compétence de l'auteur du benchmark.

Il ne faut pas s'offusquer du fait que les langages interprétés soient plus lent, ils ont leurs avantages et leur inconvénients, leur inconvénient majeur est d'être à peu près 4x plus lent qu'un langage natif comme le C++ (bien sûr tout dépend des opérations effectuées mais ils vaut mieux prendre le pire cas), mais la productivité, la portabilité est meilleur. Si les applications temps réel et semi temps-réel sont toujours écris en langage natif ce n'est pas qu'une question d'héritage du temps.

P.S. : le seul passage soulignant de meilleurs performances nécessite une référence, je serais tenté de lui donner un lien sur le site de Microsoft

[sylvain230]

Euh désolé si ma question est bête mais le C# c'est pas plutôt utilisé pour faire des IHM que des jeux vidéos ? ^^

[oxyde356]

Bien sûr mais justement certaines personnes ressentent le besoin de dévier en jouant à qui à la plus grosse avec des mauvais arguments (sans vouloir être agressif) :/
Mais bon après pour des petits jeux pas trop gourmand ou pour scripter un jeu pourquoi pas !

[sylvain230]

A d'accord ça me rassure

Plutôt que d'utiliser du C#, (J'ai jamais fait de jeux vidéos donc j'y connais rien) je pense qu'utiliser du C++ et de l'openGL est efficace pour faire un jeu.
Après ce n'est que mon avis

[oxyde356]

Pour ceux que ça intéresse voilà un benchmark intéressant (l'auteur à activer les optimisations dans tous les cas pas seulement pour les langages interprétés et a compilé en release apparemment ) : http://www.codeproject.com/KB/dotnet...rformance.aspx

[iliak]

Alors certes, il y a Mono (grand projet). Qui supporte jusqu'à .NET 2.0 je crois. Mais qu'en est il de DirectX (ou XNA) pour Mono ?
Car y a toujours pas de DirectX sous Mac ou GNU/Linux.

Ca c'est un autre problème. Une rapide recherche sur google montre qu'il y a quelques tentatives de faire du XNA sur Mono. Je ne sais pas ce que ça vaut toutefois. Mais cela ne pose pas de problème, il est tout à fait possible d'utiliser OpenGL, OpenAL (entre autres) pour contourner ce manque. Certes XNA est un framework bien fourni, mais il n'est pas essentiel ni crucial pour faire un jeu. Pour exemple, j'utilise OpenGL et OpenAL pour mon jeu Dungeon Eye et ça marche bien (que sur du Microsft je l'accorde car je ne m'occupe pas du portage sur d'autres plateformes).
Il en va de même pour la version. En .Net 2.0 tu fais déjà de très belles choses.

Et puis il est dur d'implémenter une Virtual Machine pour C# sans spécifications (et ça, Microsoft n'aime pas trop donné).

Bien au contraire, le framework .Net est ouvert et standardisé (cf Wikipedia mais en anglais cette fois, Common Language RunTime et Common Language Interface). Toujours selon Wikipedia il y a des portages en cours : Mono, DotGNU, Portable.NET. Donc je suppose que ce n'est pas si fermé que ça...

[LittleWhite]

Ca c'est un autre problème. Une rapide recherche sur google montre qu'il y a quelques tentatives de faire du XNA sur Mono. Je ne sais pas ce que ça vaut toutefois. Mais cela ne pose pas de problème, il est tout à fait possible d'utiliser OpenGL, OpenAL (entre autres) pour contourner ce manque. Certes XNA est un framework bien fourni, mais il n'est pas essentiel ni crucial pour faire un jeu. Pour exemple, j'utilise OpenGL et OpenAL pour mon jeu Dungeon Eye et ça marche bien (que sur du Microsft je l'accorde car je ne m'occupe pas du portage sur d'autres plateformes).
Il en va de même pour la version. En .Net 2.0 tu fais déjà de très belles choses.

Là on dévie de la discussion et qui rentrerai dans celle qui est: OpenGL Vs DirectX.

Bien au contraire, le framework .Net est ouvert et standardisé (cf Wikipedia mais en anglais cette fois, Common Language RunTime et Common Language Interface). Toujours selon Wikipedia il y a des portages en cours : Mono, DotGNU, Portable.NET. Donc je suppose que ce n'est pas si fermé que ça...

Standardisé, peut être. Ouvert, non.
Pour un langage standardisé en 2001 (donc il est "vieux"), ils ont ouvert du code source en 2007:

Microsoft a ouvert le code source de certaines bibliothèques utilisées par le C♯ en octobre 2007 sous la licence Microsoft Reference License (MS-RL).

Et ceci, que sous une licence bien précise, et que pour certaines bibliothèques (dans la page anglaise, on apprend quelles bibliothèques). C'est loin d'être la Virtual Machine d'ouverte ...
Sur la page wiki (comme vous aimez la wiki) de Mono:

Puisque ces composants ne sont pas couverts par les normes ECMA, ceux-ci restent sujets à l'inquiétude relevant des brevets et licences détenues par Microsoft.

Donc une implémentation libre, mais qui doit lutter contre des brevets (on parle d'ouverture ?)

Accord entre Novell et Microsoft

Microsoft et Novell ont annoncé le 2 novembre 2006 la signature d'un accord dans lequel Microsoft s'engage à ne poursuivre ni Novell, ni leurs clients, pour violation de brevets logiciels3. Selon Miguel de Icaza, chef du développement de Mono, le projet Mono est concerné par cet accord, mais uniquement pour les développeurs de Novell et pour leurs clients4. Ceci a été critiqué par de nombreux acteurs du mouvement pour les logiciels libres, car cela viole les principes d'égalité de droits entre tous les utilisateurs d'un programme particulier5,6,7.

Ce qui veut dire, oui Microsoft a juste dit, je ne les attaquerai pas (donc, un seul, des multiples projets autour de .NET / C#) Ce qui est peut ... et on remarque bien que Microsoft garde un controle (une ouverture, mais pas trop non plus) Et en aucun cas, il est dit que Microsoft fournis la spécification de la Machine virtuelle, par exemple.

[Mat.M]

Pour ceux que ça intéresse voilà un benchmark intéressant (l'auteur à activer les optimisations dans tous les cas pas seulement pour les langages interprétés et a compilé en release apparemment ) : http://www.codeproject.com/KB/dotnet...rformance.aspx

merci
C++ Rulez

[LLB]

Et il faut arrêter de croire à des bêtises. Un programme écrit avec un langage interprété sera toujours moins rapide qu'un écrit avec un langage natif tout simplement parce que chaque opérations de base à une charge supplémentaire en interprété

.NET est compilé et c'est du code natif de la machine qui est exécuté au final (JIT), parler d'interprété n'a aucun rapport avec la discussion.

Donc je vois mal les studios de jeux vidéos refaire leurs outils et middleware en C# ça coûterait une fortune pour un résultat et une pertinence fort improbables.

C'est vrai. Mais les nouveaux outils peuvent être écrits en C#, c'est d'ailleurs ce qui se fait parfois (j'ai eu plusieurs offres d'emploi pour ça). En matière d'interface graphique et d'outils, C# offre bien des avantages. Pour le cœur des jeux AAA, C# n'est pas d'actualité (parmi les problèmes, il y a le garage collector, peu adapté aux contraintes temps-réel des jeux les plus ambitieux).

Alors certes, il y a Mono (grand projet). Qui supporte jusqu'à .NET 2.0 je crois.

Mono n'est plus aussi en retard que certains voudraient le faire croire (en général, les gens répètent ce qu'ils ont entendu et c'est vrai que Mono était loin derrière il y a 5 ans). Mono supporte .NET 4.0, et il était même possible d'utiliser en partie C# 4.0 sous Mono avant que la version Microsoft ne soit publiée. Mono offre d'ailleurs des avantages et fonctionnalités qui ne sont pas sur la version Microsoft de .NET (par exemple, le shell interactif pour C#).

Standardisé, peut être. Ouvert, non.

C'est standardisé et il existe au moins une implémentation libre (tu peux même écrire la tienne, si tu as du temps à perdre). Que veux-tu de plus ? Microsoft a, à plusieurs reprises, aidé Mono (par exemple en leur donnant des fichiers de tests). Microsoft s'assure aussi que certains de ses produits tournent sur Mono. Prends F#, la compatibilité Mono est testée régulièrement et prise très au sérieux (Microsoft a même financé l'implémentation de plugins pour Monodevelop).

Et en aucun cas, il est dit que Microsoft fournis la spécification de la Machine virtuelle, par exemple.

Les spécifications de .NET sont disponibles depuis longtemps. Par exemple, pour la CLI, c'est ici. Tu trouveras les autres facilement (C#, etc.).

Mais qu'en est il de DirectX (ou XNA) pour Mono ? Car y a toujours pas de DirectX sous Mac ou GNU/Linux.

DirectX ne fait pas partie de .NET et Mono n'a pas vocation à l'implémenter. Mais cette question n'a rien à voir avec C# (en C++ non plus, tu n'as pas DirectX sous Mac).

[oxyde356]

.NET est compilé et c'est du code natif de la machine qui est exécuté au final (JIT), parler d'interprété n'a aucun rapport avec la discussion.

Forcément qu'au final c'est du code natif, vu qu'un processeur ne sait traiter que du code natif... Il n'empêche que la "compilation" dont tu parles ne permet de générer qu'un code intermédiaire et pas un code natif (tout comme JAVA), qui doit ensuite être interprété par le JIT (respectivement la JVM) à l'exécution donc ... Le langage est donc compilé (mais ne produit pas d'instructions natives) puis interprété. C'est quand même bien ce que l'on entend par langage interprété ! Après on peut jouer sur les mots et dire qu'un langage interprété c'est plutôt du script m'enfin je pense que l'on se comprend au final là ce qui compte c'est ce qui se passe au runtime.
Ne retenir que le fait que le langage soit "compilé" c'est vraiment juste un argument marketing car au final ça ne change strictement rien niveau performance c'est juste utile pour unifier les différents langages autour de .NET.

[bafman]

Forcément qu'au final c'est du code natif, vu qu'un processeur ne sait traiter que du code natif... Il n'empêche que la "compilation" dont tu parles ne permet de générer qu'un code intermédiaire et pas un code natif (tout comme JAVA), qui doit ensuite être interprété par le JIT (respectivement la JVM) à l'exécution donc ... Le langage est donc compilé (mais ne produit pas d'instructions natives) puis interprété. C'est quand même bien ce que l'on entend par langage interprété ! Après on peut jouer sur les mots et dire qu'un langage interprété c'est plutôt du script m'enfin je pense que l'on se comprend au final là ce qui compte c'est ce qui se passe au runtime.
Ne retenir que le fait que le langage soit "compilé" c'est vraiment juste un argument marketing car au final ça ne change strictement rien niveau performance c'est juste utile pour unifier les différents langages autour de .NET.

si si, le Java et le C# compilent à la volée leurs IL pour en faire du code natif qui est ensuite executé par le proc. Quand on execute un programme Java intensif, par exemple, on a un leger bloquage du programme à un moment, c'est la compile JIT et ensuite, le programme est plus rapide .

Bon, par contre, pour faire du code VRAIMENT performant, ça ne resoud rien du tout le JIT. Pour cela, il faut au minimum l'ensemble des caractèristiques suivantes :
- maitriser completement la representation memoire des données (pour plus d'info, lire le très bon blog cell performance de Mike Acton est notemment typical C++ bullshit qui montre bien que du code C++ classic ne repond déjà pas aux problèmes de performance dans le jeu video (alors ne parlons pas de Java et C# ))
Cette maitrise de la representation memoire englobe bien evidemment les problèmes d'alignement memoire, du faire de ne pas vouloir de pointeur de table de fonction virtuelle dans les float3 etc... Bref, on ne parle pas seulement de garbage collector et d'allocation memoire, mais de tout ce qui touche aux transferts entre le CPU, la memoire et la carte graphique.
- pouvoir acceder aux spécificité processeurs propre à chaque plateforme tel que les instruction SIMD (ça elimine d'office le Java, par contre, je croit qu'il existe une implementation de SIMD sous mono, mais je ne sais pas ce que ça donne au niveau performance) qui reste le seul moyen de tirer le meilleurs des performance d'un processeur donné à un temps t.

bref, ces deux condition necessaires pour faire du code performant consiste tout simplement à connaitre et exploiter la plateforme sur laquelle on tourne. C'est donc relativement antagoniste avec la notion d'abstraction de la plateforme que proposent Java et C#. Le tout etant de savoir si le surcout de l'exploitation de ces plateformes est interessant d'un point de vue financier.

Globalement, la reponse est : oui, si cette performance est un des critère majeur d'evaluation du produit (ce qui est le cas sur les jeux AAA, mais pas forcement sur les autres)

[oxyde356]

Si l'interpréteur ne fait plus rien après avoir transformé le CIL en byte-code pourquoi les perfs sont si mauvaises :o non parce que en réalité les performances sont vraiment moins bonnes quand même :/

Dans le cas des hautes performances je ne vois vraiment pas l'intérêt d'un langage comme C#. Celui ci est censé augmenter la productivité en enlevant toutes les problématiques bas niveaux et hop on y replongerait dedans alors que l'intérêt du langage est en bonne partie de se soustraire à ces problèmes. Et forcément vu que c'est quand même bien censé être crossplateforme sans développement spécifique du coup si on tombe bas niveau il faut faire du code spécifique selon les différentes machines/OS visés.

[bafman]

Si l'interpréteur ne fait plus rien après avoir transformé le CIL en byte-code pourquoi les perfs sont si mauvaises :o non parce que en réalité les performances sont vraiment moins bonnes quand même :/

Dans le cas des hautes performances je ne vois vraiment pas l'intérêt d'un langage comme C#. Celui ci est censé augmenter la productivité en enlevant toutes les problématiques bas niveaux et hop on y replongerait dedans alors que l'intérêt du langage est en bonne partie de se soustraire à ces problèmes. Et forcément vu que c'est quand même bien censé être crossplateforme sans développement spécifique du coup si on tombe bas niveau il faut faire du code spécifique selon les différentes machines/OS visés.

la lenteur peut venir de pleins de truc :
- les verification au runtime des limites des tableaux
- le garbage collector
- les 18 niveau d'heritage qui font que la construction du moindre objet appel autant de constructeurs
- les autoboxing caché à pleins d'endroits
- le moindre appel de fonction est virtuel et fait dont un lookup dans la metaclass
bref, la lenteur ne vient pas forcement du runtime, mais en grande partie du langage en lui même...

sinon, pour le C#, ça pourrait être une bonne chose de pouvoir descendre dans des couches plus basses sans passer par des couche d'interoperabilité du type pInvoke. Quand on developpe un jeu, on peut vouloir faire des optimisations localisé tout en gardant le code non critique plus simple. Malheureusement, dans l'etat actuelle des chose, quand on veut faire ça, on se tape des couche d'interop qui font perdre tout le benefice de la version optimisée