Discussion :

[Heptaeon]

Voila, je voulais savoir ce qu'en pense la communauté de développeur francophone. Voila 2ans que ca a été annoncé.

J'en vient a me poser de multiple questions

- Est ce le début d'une phase de migration de c++ à c# pour les jeux, comme semble le vouloir Microsoft ?
- C# sur la XBox 360, mais pour la PS3 et la WII ?
- XNA à t'il un avenir ?

http://www.xbox.com/fr-FR/community/news/gdc2006.htm

Il y a aussi beaucoup d'info sur le site de Microsoft. dont le CTP que je n'ai pas essayé.

http://www.microsoft.com/xna/

Qu'en pensez vous ?

[Viquel]

Je ne pense pas que le C# prennent vraiment le pas sur le C++ pour les jeux. D'ailleurs, il n'y ait pas fait mention dans le XDK360... Par contre c'est vrai que Microsoft mais en avant le C# (suffit de faire une recherche sur la MSDN pour tomber toujours en premier sur les article C#...) mais je pense que c'est plus dans le but de conter Sun/Java que de vraiment remplacer le C++.

Pour ce qui est de la plateforme XNA, je trouve que c'est vraiment une bonne idée. En ayant des outils similaires pour le developpement PC et console (XBox), ça fera forcément gagner beaucoup de temps au developpeur. On peut d'ailleurs voir le portage de PIX de la XBox (qui s est le meilleurs outils d'analyse 3D qu'il m'a était donné de voir, encore bien au dessus de la version PC actuelle) vers le PC comme le début du XNA.

[mat.M]

- Est ce le début d'une phase de migration de c++ à c# pour les jeux, comme semble le vouloir Microsoft ?
- C# sur la XBox 360, mais pour la PS3 et la WII ?
?

C# produit-il du code natif ?

Je ne pense pas que le C# prennent vraiment le pas sur le C++ pour les jeux.

Cet argument je l'ai tenu maintes fois sur ces forums ce qui a entrainé maintes polémiques

[Sixissor]

- Est ce le début d'une phase de migration de c++ à c# pour les jeux, comme semble le vouloir Microsoft ?

Non.
Le C# demeure le langage "chouchouté" par Microsoft sur ses plateformes comme Windows ou PocketPC. Il s'agit d'un bon langage objet qui permet de gagner du temps par rapport au C++, mais le mérite va plus au framework dotNET qu'au langage lui-même, qui possède des classes très performantes et touche-à-tout. De plus il est mieux compréhensible que le C++ (ça c'est toujours mon avis).
Ensuite, comme l'a laissé sous-entendre mat.M, C# ne produit pas de code natif et donc dépendant du framework dotNET, donc oublie C# sauf pour les plateformes Microsoft. En gros c'est pas portable sur Linux par exemple... OK y'a Mono et alors ?

Et puis Microsoft.... Jeux... Imposer...
Y'a comme un truc qui pique les oreilles... Faut pas oublier qu'ils sont encore newbie au niveau du temps dans le secteur des consoles, jeu vidéo. Ils imposent ce qu'ils veulent sur la XBox mais c'est tout.
Et généralement personne n'impose rien dans ce secteur (encore heureux)... sauf peut-être connaitre le C++

Hé oui ! Faut pas oublier que la grande majorité des Game Engine ou des Graphics Engine proposé sont en C++, et pas en C#. Donc si tu connais pas le C# on s'en fout, par contre si tu connais pas le C++, tu sors

- C# sur la XBox 360, mais pour la PS3 et la WII ?

C/C++ et autres. La routine quoi.
Enfin bon... Question assez évidente. Le plus important à retenir c'est que Sony et Nintendo vont surtout pas allez chercher Microsoft avec leur C#...

Pour info: la PS3 aura un coeur Linux , donc je te laisse envisager les possibilitées.

- XNA à t'il un avenir ?

Actuellement il faut savoir que les Games Tools proposés par Microsoft (dont XNA fait parti) pour la XBox (et sa grande soeur) sont les plus performants du marché et les plus appréciés par les développeurs (d'après ce que j'ai entendu dire).
Donc OUI, XNA a un avenir assuré (d'après moi).

[Heptaeon]

...
C# produit-il du code natif ?
...

Justement, il y aura une platforme .net sur la XBox, donc pas du tout besoin de l'être.

Actuelement, nous somme tous bien d'avis que le C++ est le plus utilisé, c'est incontestable. Et ma question n'était pas posé pour le présent, mais bien pour le futur.

quant au code natif pour le c#, oui c'est tout a fait possible les compilateur JIT peuvent executer ou sortir du code natif. Ca perdrais tout l'interet du c# par contre et je supose qu'il serais plus lent qu'en C++. Je n'ai jamais tester je ne peu pas parler de vitesse du c# en natif.

Tout les jeux s'installe, Il pourais se compiler a l'installation et serais adapter a la machine .

[Sixissor]

Salut.

J'espère pouvoir re-apporté un début de réponse argumenté un minimum à une de tes questions.

Nous savons tous que le C# est en pleine évolution.

Pour moi, il reste un super langage avec beaucoup d'atouts, et en plus il est agrémenté d'une super bibliothèque de classe que nous appelerions QuezaC... (ok ) fournie par la plateforme DotNET ! Et l'utiliser avec un IDE comme Visual Studio 2005 est un vrai plaisir (auto-complétion géniale, marquage des erreurs de syntaxes en live, ...).

Si jamais demain je dois faire un logiciel quelconque (sur Windows), il y a d'énormes chances que je m'oriente vers C# avec les solutions proposés par Microsoft. Gain indéniable de temps et confort certain. Très peu de points négatifs.

- Est ce le début d'une phase de migration de c++ à c# pour les jeux, comme semble le vouloir Microsoft ?

Maintenant si je dois faire quelque chose de graphique, mais plus poussé, comme un jeu ou un moteur graphique ou autres, il y a 2 API graphiques majeures: OpenGL et DirectGraphics (on va dire DirectX en général), mais comme là on parle de "c++ à c# pour les jeux", XBox etc., on va pencher pour DirectX.
Et là s'offrent 2 solutions:

1. DirectX en C++ (Natif, voir Unmanaged ou même Managed, avec tout ce que ça implique)
2. DirectX en C# (Managed, avec tout ce que ça implique)

Lequel choisir ?

Actuellement les standards de l'industrie optent pour le C++, on le sait tous. Mais DxM/C# est un bon combo aussi, et on écrit la même chose qu'en C++ Natif avec beaucoup moins de lignes à taper, car une partie est généré (events, etc. Visual oblige).

Pour revenir au troll C++/C# et la rapidité, il faut savoir que VS.NET 2005 a un compilateur JIT qui génère du MSIL de très bonne qualité et très optimisé, avec des performances donc presques identiques au code natif. Bien sûr, du C++ natif optimisé sera plus performant que du C#, il ne faut pas se voiler la face, mans dans quelle mesure ? Si c'est pour passer de 200 à 130 fps avec une application finie écrite respectivement en C++ natif et C#/DirectX Managed, je choisi les 130 fps, car visuellement il n'y aura pas de différences notables à l'oeil nu mais par contre j'aurai développé mon appli en 2 fois moins de temps.
Après c'est les optimisations qui jouent.
Et là je vous vois déjà arriver avec l'assembleur tout ça... Pour info, de l'assembleur mal écrit est plus lent que le code généré par le compilateur de VS.NET 2005. Donc pas la peine d'écrire en assembleur pour le mythe du gain de temps assuré. Ca reste d'actualité seuleument si on sait programmer en assembleur.
Vous connaissez le proverbe (et slogan Adidas ): "Sans maîtrise la puissance n'est rien" qui est ô combien vrai et valable pour tout.
[MYLIFE]D'ailleurs il me plait bien je vais le mettre en signature[/MYLIFE]

Donc C# pour les jeux, l'avenir nous le dira, mais je suis très confiant sur les plateformes Microsoft pour les personnes qui utilisent DirectX / C++. Ceux qui utilisaient OpenGL vont certainement rester en C++... Après c'est une question d'API.
Passer du C++ au C# est assez naturel, donc pas de problèmes de compréhension. Quelques notions objet en plus, petites différences et c'est tout.
Il y a déjà des moteurs graphiques et des gens qui s'intéressent au C# depuis quelque temps... D'ailleurs si quelqu'un connait un jeu écrit en C#/DxM, ça serait bon de le faire savoir parce que moi j'en connais pas

Je concluerai sur ça: si on veut rester libre de développer des jeux sur n'importe quelle plateforme, C++ est le choix naturel, avec OpenGL et d'autres bibliothèques annexes.
Par contre, si on se base sur la solution DirectX pour la programmation sur les plateformes Microsoft, personnellement je pencherai plus pour le C# / DirectX Managed. Une fois qu'on y goûte, on est accro.
J'ai l'impression que DirectX Managed a l'air de faire peur, à injuste raison... Surtout pour une partie des amateurs dans ce secteur qui ont un synonyme de "Managed" dans leur tête qui est "lent". Je suis amateur aussi mais je pense pas ça. Je n'ai jamais eu à me plaindre des performances C#/ DxM et je n'ai pas vu d'applications graphiques qui "ramaient" à cause du C#... S'ils se serait appelé DirectX Ultra Gore Fast Lightning Mega MMO-project DOOM5 HL6 NEXT GENERATION ou un truc du genre, tout le monde s'y serait mis .
Et puis faut pas oublié un point clé: la rétro-compatibilité de DirectX en C++ et C#. Il est rare (treès rare...) de compiler un code DirectX/C++ compatible entre plusieurs versions de DirectX, alors que ce n'est pas le cas avec DirectX Managed: les changements sont minimes. Donc la question de mise à jour du code se pose aussi

Voilà tout .
J'espère pas avoir dit trop de conneries

PS (important):

1. Si j'ai parlé de DirectX, c'est parce que c'est une API graphique commune au C++ / C# et aux plateformes Microsoft dans le secteur de la programmation de jeux vidéos. Donc il fallait en parler pour l'évolution du C# dans ce domaine...
2. Si jamais dans ce que j'ai dit, les modérateurs y voient du troll, ce n'était pas du tout mon intention. Ils peuvent bien sûr, et je les incite, éditer les parties qui peuvent être sujettes à d'inombrables posts "kikoo lol OpaineGL c'est meiu" - like. Merci

++

[Heptaeon]

Personellement, j'ai l'impression que le C++ se fait avoir a cause de sa syntaxe tout de même trop lourde. On dirais qu'il y a trop de finesse dans se language qui devrais être implicite.

Quant au code final du C, pour avoir regarder ce qu'il pond en ASM sur des petits programmes, il faut vraiment mal coder de l'asm pour se faire avoir non ?

[Sixissor]

Personellement, j'ai l'impression que le C++ se fait avoir a cause de sa syntaxe tout de même trop lourde. On dirais qu'il y a trop de finesse dans se language qui devrais être implicite.

Je ne pense pas que ça soit la syntaxe qui pénalise le C++. Mais plutôt côté finesse de programmation (ce qui est différent). Je sais qu'on peut faire des choses très abstraites et compliquées en C++ mais là ça requiert plus du skill en programmation orienté objet qu'autre chose je pense. Il faut être bien structuré dans sa tête... et sur papier surtout !
Si tu veux faire dans le compliqué, je sais que le C++ offre cette possibilitée .

Quant au code final du C, pour avoir regarder ce qu'il pond en ASM sur des petits programmes, il faut vraiment mal coder de l'asm pour se faire avoir non ?

Je ne vois pas ce qui différencie l'ASM des autres langages: il y a des trucs propres et des choses à éviter. A partir du moment où l'on manipule un langage de programmation, généralement on a plusieurs méthodes pour arriver au but final, mais toutes les méthodes ne se valent pas.
L'unique différence c'est que l'ASM est le plus bas niveau.

[mat.M]

Prends le language que tu veux ; le principal c'est de faire quelque chose qui ait "de la gueule" et soit intéressant pour les autres.
On s'en fiche si c'est C# ou C++....
Cependant avec Php par exemple ça sera un peu limité ( difficile de faire de la 3d )

Commencer en C# puis si tu veux tirer les performances au max tu peux essayer de passer à C++ si le gain est vraiment significatif

[Heptaeon]

Prends le language que tu veux ; le principal c'est de faire quelque chose qui ait "de la gueule" et soit intéressant pour les autres.
On s'en fiche si c'est C# ou C++....
Cependant avec Php par exemple ça sera un peu limité ( difficile de faire de la 3d )

Commencer en C# puis si tu veux tirer les performances au max tu peux essayer de passer à C++ si le gain est vraiment significatif

C'est contre ma philosophie : "bosser dans le vide" et "recommencer ce que j'ai deja fait" =D

[Invité]

C'est contre ma philosophie : "bosser dans le vide" et "recommencer ce que j'ai deja fait" =D

/!\ Poste hautement inutile...

"Bosser dans le vide", cela veux dire quoi exactement ? Tout ce que tu fait sert à quelque chose, même si ce n'est pas le code produit qui va servir, il reste un facteur très important, cela s'appelle "apprendre", sisi tu sais, "c'est en forgeant, blablabla..."

Et quand au "recommencer ce que j'ai déja fait", ce n'est jamais un mal, si tu ne fait pas un transcription directe, mais en améliorant, en essayant d'etre plus concis, plus proche du travail à faire, ou alors en generalisant plus, il y'a des multiples methodes de traité un même sujet, et sous le pretexe de "je l'ai deja fait, je repompe mon code, sans me poser de question", tu peux passer à coter de pleins de choses.

Refaire un bout de code que l'on a deja fait, c'est poser un regard critique sur son boulot, dans le bit d'ameliorer, et de gagner en experience. "Et si je faisait un arbre pour les acces aux données, ce ne serait pas mieux ?" "Et si je faissait un cache, est-ce que je gagnerai pas du temps" "Et si j'essayait de voir si je ne peux pas faire marcher ce bout de code de la maniere la plus portable possible"

My 2 cents, cela ne sert à rien ce que je dit, juste une petite reflexion stupide, mais j'ai franchement tiqué sur un coté "je reussi ce que je fait du premier coup" qui me déplait fortement... désolé.

[Sixissor]

De toute façon, pour moi un développeur se doit de connaître un minimum tous les langages de programmation, ou au moins connaître les plus importants, et pas se cantonner au C/C++ et Php ou autres.
Premièrement pour adapter le langage au projet qu'il compte faire, même si normalement c'est le chef de projet qui s'y colle.
Deuxièmement, je me vois mal demander à un vétéran du code qui a travaillé 30 ans dans le secteur du développement de me pondre un petit truc en Python et qu'il dise "Python ? .... Connais pas !".

Après, pour retranscrire son code dans un autre langage, je trouve qu'il n'y a rien de mieux pour comparer les performances et les avantages/défauts/contraintes.
Perso c'est en commençant à retranscrire mon code DirectX/C++ en DirectX Managed / C# que j'ai découvert le C# et je trouve que j'ai vraiment fait une belle découverte. Comme quoi ça vaut le coup

EDIT: faute d'orthographe

[ash.ice.loky]

De toute façon, pour moi un développeur se doit de connaître un minimum tous les langages de programmation

tres dur, surtout a la vue du nombre existant mais dans l'ensemble je suis d'accord.

je me suis mi par curiosité au C#.
j'ai commencé avec le C puis passage oblige au C++, pour enfin me mettre au JAVA car dans le monde professionnel on ne fait pas toujours ce que l'on veut.

pour mes developpement perso j'utilise le C++ et c'est surtout du a 2 raisons :
- j'aime coder sous linux G++ / automake / autoconf / cvs / emacs
- le nombre de classes que je possedes commence a etre consequent

lorsque je me suis mi a la prog windows, j'ai decouvert Code::blocks et la j'ai eu un coup de coeur car son systeme de templates, son editeur et son import de projet/ multi compilateur est vraiment genial.

puis j'ai essayé visual et la j'ai pas trop accroché.
pour le C#, le gros frein est la plate-forme .NET et ses langages de description qui m'enerve ... mais j'avoue que comparé a WxWidget ou meme QT il n'y a pas photo dans la vitesse de developpement.

Pour les jeux le probleme qui se posent est l'obligation de directX et donc exit OpenGL/SDL. Lorsque l'on fait ca par passion devoir reprendre tout depuis le debut est assez decourageant.

sans tombé dans un troll, DX et ses nouvelles versions non compatibles m'on toujours decourager. pourrais-tu Sixissor m'expliquer en quoi DX managed en C# evite ces problemes ?

[Sixissor]

sans tombé dans un troll, DX et ses nouvelles versions non compatibles m'on toujours decourager. pourrais-tu Sixissor m'expliquer en quoi DX managed en C# evite ces problemes ?

2 cas: pratique et théorique.

Dans les 2 cas, on a la dernière version de DirectX pour XP: 9.0c et le framework dotNET le plus récent (2.01 si je ne fais pas erreur).

Cas pratique concernant la rétro-compatibilité:

• Si un code DirectX C++ ne compile pas et si l'erreur vient des prototypes de fonctions qui changent, des fonctions avec plus ou moins d'arguments en plus ou en moins, etc. C'est vraiment prise de tête pour modifier son code et le mettre à jour. La galère est que, Direct Graphics (entre autres) est incompatible entre les différentes versions de DirectX.
• S'il y a une erreure dans la compilation d'un prog DirectX Managed / C#, il suffit de mettre à jour les assemblies Microsoft.DirectX Microsoft.DirectX.Direct3D et Microsoft.DirectX.Direct3DX pour que ça fonctionne (clique droit->supprimer, clique droit->ajouter; les 1.X pas les 2.X car encore trop jeunes).

Cas théorique concernant la rétro-compatibilité:

• DirectX (C++) utilise le modèle COM et à chaque nouvelle version et vu les nouveaux apports et améliorations, l'interface change aussi. Pour chaque version de DirectX et plus particulièrement DirectGraphics, l'interface ainsi que les fonctions attachées changent et donc il faut mettre à jour l'ancienne interface utilisé dans son programme. Je prends par exemple IDirectDraw7:: , etc. Ca semble évident que cette Interface ne fonctionnera pas avec les versions DirectX plus récentes (Direct Graphics).
• Pour DirectX Managed, c'est différent... Tout d'abord il faut savoir que cette version de DirectX conçue spécialement pour le framework dotNET a été réecrite entièrement, et se passe du modèle COM (dotNET se veut être le successeur de COM). Donc plus de problèmes d'interfaces car ce nouveau framework se veut générique. Par conséquent, plus de problèmes de prototypes, et les changements se font passer presque inaperçus tellement qu'ils sont minimes. D'ailleurs vous-êtes vous déjà posé la question pourquoi appelle-t-on DirectX sur la plateforme dotNET DirectX Managed et non pas DirectX Managed 1.0 ou 2.0 ou plus ? ... Ca semble logique.

Sans parler des incompatibilités entre DirectX 10 et DirectX 9, et sans même parler des incompatibilitées qu'il y aura entre toutes les versions de DirectX dans le futur, et ce, pour chaque version.

Pour résumer ce que je pense de la rétro-compatibilité DirectX rien ne vaut un dessin:

++

[ash.ice.loky]

Si j'ai bien compris, lors des evolutions de DX, dotNet se charge de maintenir une compatibilité qui devrais en theorie passer inapercu pour l'utilisateur, mais en pratique peut neccessité quelques changements, mais rien de dramatiques ?

en tout cas merci pour cette explication

[mat.M]

C'est contre ma philosophie : "bosser dans le vide" et "recommencer ce que j'ai deja fait" =D

Tu te trompes totalement ;
si ton projet est bien architecturé avec des classes bien définies et modélisées le tout bien structuré , tu n'as pas perdu ton temps que cela soit en C# ou C++ ou autre.

Pour mon projet les appels systèmes Direct X et win32 c'est même pas 15 % du total du code source.
Tout le reste c'est du C/C ++ avec STL.
Si je dois tout porter en C#, ça me prendra peu de temps.

Prends le code source de Civilisation Call to Power c'est pareil il ya peu d'appels
à l'OS.

[funkydata]

Je dirais que le C# a encore trés mauvaise réputation au niveau de la vitesse de son code compilé. J'avais, pour tout vous dire, les mêmes à priori et c'est sans grande conviction que j'ai fait des tests entre le couple c++/dx9 et c#/mdx justement, afin d'orienter mon choix de plateforme pour mon projet. J'ai découvert (avec stupeur je dois bien le dire) que le c#/mdx offrait les mêmes performances que c++/dx9 dans 90% des cas... les 10% restants était principalement des tests très très lourds de calculs en virgule flottante ou des tests de IO... Je dirais donc que par rapport aux avantages qu'apporte C#, la perte de performances est vraiment négligeable d'autant que les applications DirectX sont de plus en plus pensée (évolution du matériel oblige ) afin d'utiliser un maximum le GPU et d'éviter (comme c'était encore le cas il y a quelques temps) les IO inutiles.

Pour en revenir à XNA je trouve cette librairie trés prometteuse mais encore trop de manques apparaissent dans la première version béta sortie. Une fois la release terminée, je pense que cette librairie pourra s'avérer bien utile même si dans l'absolu elle se contente d'implémenter des fonctions de bases que tout développeur DirectX à déjà du programmer. J'attendrais toutefois la version finale pour me prononcer définitivement

[Inverse]

XNA Game Studio Express est un bijou pour la création amateur et pour l'apprentissage de la programmation de jeux vidéos 2D. Concernant la 3D, la beta n'incluant pas encore le content production pipeline, je ne me suis pas encore donné le loisir de tester.

Pour ce qui est du débat futile du C# vs C++ vs le reste du monde, XNA Game Studio Express permet de créer facilement du concret et en très peu de temps. On peut faire plus performant avec d'autres solutions, certes, mais à quel prix (moyens, coûts, temps de développement, etc..) ? XNA n'a pas pour but d'être la solution ultime et universelle, ceci étant, il remplit parfaitement son rôle.