Le langage Java est-il adapté pour les jeux vidéo ?

Citation:

---

Envoyé par screetch

combien de mega octets pour faire tourner la VM ? y a t'il des allocations "sur la piles" qui ne créent pas des allocations sur le tas ?
portabilité de java sur les consoles?

j'ai l'impression que toi meme, tu ne connais pas trop le C++. donc, 1-1 balle au centre.

---

Sur PS3, on peut faire tourner Java (OpenJDK 1.7) mais il faut installer Linux (Yellow Dog par exemple). On peut se servir de PSGL (une version d'OpenGL-ES spécifique aux consoles Sony depuis la PS2) et de JOGL-ES. Disons que ce n'est pas simple de faire tourner Java et d'utiliser l'accélération matérielle en même temps sur cette machine. Beaucoup de "geeks" se sont cassés les dents là-dessus.

Sur Wii, à ma connaissance, on ne peut pas (encore) développer en Java, le kit de développement permet de développer en C/C++. Mais encore une fois, quelques geeks ont réussi à faire tourner JME sur Wii :
http://www.youtube.com/watch?v=VOUpzzo5ykM

Sur XBox, on peut aussi arriver à faire tourner Java encore une fois en installant Linux. Par contre, je ne sais pas si c'est possible sur XBox 360.

Sur Nintendo DS, il y a Java2NDS qui s'inspire du portage de la KVM de Torlus sur GBA :
http://blog.davr.org/2007/08/08/java-for-nds/
Le projet j2me-NDS est en cours mais je n'arrive pas à en avoir le statut.

Pour résumer, le développement de jeux vidéo en Java sur console n'est pas très accessible à l'heure actuelle alors que la porte est grande ouverte pour C/C++. Cependant, je rappelle que plus de 800 millions d'ordinateurs sont équipés de Java, le développement de jeux vidéo en Java sur PC est donc bien plus accessible, idem sur téléphones mobiles (essentiellement avec J2ME et quand c'est possible avec JOGL-ES).

Une machine virtuelle Java pour PC peut tourner avec un certain nombre de Mo, cela dépend des paramètres que tu passes à la JVM (-Xms pour le démarrage et -Xmx comme borne supérieure). Par défaut, c'est 64 Mo sur le tas.

D'après Brian Goetz de Sun :
"The Java language does not offer any way to explicitly allocate an object on the stack, but this fact doesn't prevent JVMs from still using stack allocation where appropriate. JVMs can use a technique called escape analysis, by which they can tell that certain objects remain confined to a single thread for their entire lifetime, and that lifetime is bounded by the lifetime of a given stack frame. Such objects can be safely allocated on the stack instead of the heap. Even better, for small objects, the JVM can optimize away the allocation entirely and simply hoist the object's fields into registers."
Je me trompe peut-être mais si je comprends bien, il parle d'allocation sur la pile au lieu d'allocation sur le tas, ça laisse entendre que tu peux allouer sur la pile sans allouer sur le tas.

Je ne connais pas C++ aussi bien que Java (j'ai programmé quand même quelques années en C++) mais quand je ne sais pas, je ne m'avance pas autant que ce que tu as fait concernant les méthodes virtuelles, je préfère dire que je ne sais pas.

le langage c++ a ses forces et ses faiblesses, le langage java a ses forces et ses faiblesses. ils trouvent tous les deux des applications, certaines sont beaucoup plus faciles en C++ qu'en java et certaines sont beaucoup plus faciles en java.

Personne ne consteste la possibilité de faire des jeux en java, certains contestent que ce choix implique des limites que l'on a un peu de mal a lever.
Tout comme personne ne conteste qu'on peut developper des applis web en C++, mais que c'est moins bien adapté que le java.

il y a des choses specifiques au java qui sont un obstacle pour des choses tres specifiques aux jeux videos. par exemple, le manque de controle sur les allocations fait que l'on ne peut pas predire quand le jeu risque de bloquer pour faire une passe sur le garbage collector. or, un jeu a un besoin quasi constant d'etre a 30/60fps, et a besoin de regularité. tout comem la recompliation dynamique. Si le programme se modifie a l'execution, on atteint une vitesse un peu superieure, mais on risque de bloquer le jeu pour une courte periode et d'avoir une frame trop longue.
Ces choses, sur une appli webs, ne posent aucun probleme, et deviennent une grande force du java. la possibilité de prédire le C++ de maniere plus formelle donne un avantage au C++ dans les jeux videos.

Enfin, les jeux sont de grands consommateurs de ressources. l'utilisation du GPU en java est la meme qu'en C++, mais quid de la mémoire ? qui des threads, du CPU qui sont mobilisés par la VM et que tu ne peux pas utiliser ?

donc, la conclusion pour moi est que faire des jeux en java est tout a fait possible tout en sachant que ton jeu consommera 120% des resources qu'un jeu en C++ consomme. pour 90% des projets cela n'a pas d'incidence. pour les 10% restant, ca coincera un peu.

très joli résumé screetch ;)

j'ajouterai juste quelques petites choses:

au niveau amateur (ce qui est le cas pour la grande majorité d'entre nous je pense) on va pas tenter de faire un crysis-like donc, à la limite on pourrait faire un jeu en scheme/prolog/c++/java que ça ferait pas grand chose de différent. La plupart du temps, c'est nous même qui sommes les limites du langage. Donc, faut juste choisir celui qu'on préfère.

Citation:

---

Envoyé par gouessej

mais quand je ne sais pas, je ne m'avance pas

---

Citation:

---

Envoyé par gouessej

Mais encore une fois, quelques geeks ont réussi à faire tourner JME sur Wii :
http://www.youtube.com/watch?v=VOUpzzo5ykM

---

as-tu la certitude que c'est sur Wii et pas juste une wiimote liée à un pc? :roll:

Citation:

---

Envoyé par screetch

le langage c++ a ses forces et ses faiblesses, le langage java a ses forces et ses faiblesses. ils trouvent tous les deux des applications, certaines sont beaucoup plus faciles en C++ qu'en java et certaines sont beaucoup plus faciles en java.

Personne ne consteste la possibilité de faire des jeux en java, certains contestent que ce choix implique des limites que l'on a un peu de mal a lever.
Tout comme personne ne conteste qu'on peut developper des applis web en C++, mais que c'est moins bien adapté que le java.

il y a des choses specifiques au java qui sont un obstacle pour des choses tres specifiques aux jeux videos. par exemple, le manque de controle sur les allocations fait que l'on ne peut pas predire quand le jeu risque de bloquer pour faire une passe sur le garbage collector. or, un jeu a un besoin quasi constant d'etre a 30/60fps, et a besoin de regularité. tout comem la recompliation dynamique. Si le programme se modifie a l'execution, on atteint une vitesse un peu superieure, mais on risque de bloquer le jeu pour une courte periode et d'avoir une frame trop longue.
Ces choses, sur une appli webs, ne posent aucun probleme, et deviennent une grande force du java. la possibilité de prédire le C++ de maniere plus formelle donne un avantage au C++ dans les jeux videos.

---

Si tu as besoin de plus de prédictabilité en Java, tu peux te servir de RT5J et de Javolution. Fixer la taille du tas avec les paramètres dont j'ai parlé augmente la prédictabilité :
"Setting -Xms and -Xmx to the same value increases predictability by removing the most important sizing decision from the JVM."
cf. http://java.sun.com/docs/hotspot/gc/index.html
Depuis Java 1.3, on peut pas mal paramétrer le ramasse-miettes et depuis Java 1.6, la machine virtuelle est capable de générer des valeurs plus intelligentes pour ces mêmes paramètres (pas seulement les deux dont j'ai parlé) ce qui améliore les performances.
Tu peux aussi choisir entre plusieurs algorithmes de garbage collection, par exemple, pour réduire les pauses :
"If your application would benefit from shorter garbage collector pauses and can afford to share processor resources with the garbage collector when the application is running, I suggest using the concurrent low pause collector. " cf. http://articles.techrepublic.com.com...1-6108296.html

Les optimisations dynamiques ne produisent pas le genre de lag dont tu parles à ma connaissance même quand tu charges dynamiquement des classes de façon récurrente.

C'est bien beau tout ça mais j'ai joué à de nombreux jeux vidéo en Java et même ceux qui ne s'embêtent pas avec les paramétrages dont j'ai parlé n'ont pas de problème de lag dû au ramasse-miettes.

Si le garbage collector était un si grand obstacle que tu le dis, on n'écrirait aucun jeu vidéo en Java. Les lags auxquels tu fais allusion se produisent uniquement si tu forces la finalisation et le passage du garbage collector à un moment inopportun, c'est souvent mieux de ne pas faire ça, c'est écrit dans la documentation.

Citation:

---

Envoyé par screetch

Enfin, les jeux sont de grands consommateurs de ressources. l'utilisation du GPU en java est la meme qu'en C++, mais quid de la mémoire ? qui des threads, du CPU qui sont mobilisés par la VM et que tu ne peux pas utiliser ?

donc, la conclusion pour moi est que faire des jeux en java est tout a fait possible tout en sachant que ton jeu consommera 120% des resources qu'un jeu en C++ consomme. pour 90% des projets cela n'a pas d'incidence. pour les 10% restant, ca coincera un peu.

---

Tu ne parles que de ce que tu perds mais avoir plus de contrôle peut aussi amener à faire moins bien que ce que ferait la JVM. Je parle de la JVM mais je devrais parler des JVM car il y en a plusieurs et certaines configurations sont plus adaptés au milieu de l'embarqué. Ca peut avoir du bon d'avoir moins de contrôle. Si ça te manque tant que ça, pourquoi n'écris-tu pas tous tes programmes entièrement en assembleur? :P Si je suis ton raisonnement, pourquoi programmes-tu en C++? Tu as moins de contrôle qu'en assembleur non?

Citation:

---

Envoyé par luckyvae

j'ajouterai juste quelques petites choses:

au niveau amateur (ce qui est le cas pour la grande majorité d'entre nous je pense) on va pas tenter de faire un crysis-like donc, à la limite on pourrait faire un jeu en scheme/prolog/c++/java que ça ferait pas grand chose de différent. La plupart du temps, c'est nous même qui sommes les limites du langage. Donc, faut juste choisir celui qu'on préfère.

---

Même dans le monde professionnel (je rappelle que je suis ingénieur en informatique dans un département de R&D), la principale limite au niveau des performances mémoire et en vitesse d'exécution n'est pas le langage informatique choisi même si ça a son importance. Encore une fois, choisir C++ n'assure pas que ton jeu ira plus vite. Si tes algos sont nazes, quelque soit le langage, les performances ne seront pas au rendez-vous.

Citation:

---

Envoyé par luckyvae

as-tu la certitude que c'est sur Wii et pas juste une wiimote liée à un pc? :roll:

---

As-tu pris le temps de lire ce qu'il répond quand on lui demande d'expliquer comment il a fait? AvetanaBT est une bibliothèque qui permet de piloter le bluetooth en Java sous Linux donc déjà ce point-là tient la route.

Citation:

---

Envoyé par gouessej

As-tu pris le temps de lire ce qu'il répond quand on lui demande d'expliquer comment il a fait?

---

oui, et il ne parle à aucun moment du fait que ça tournerait sous Wii. Il dit qu'il a utilisé AvetanaBT pour linux, qu'il a fait une dll jni pour windows et qu'il a utilisé jme.


Un autre truc auquel je pense: la compilation de code java en code natif via gcj, est-ce que cela permet d'avoir de meilleurs/moins bonne/identique performance? Je ne connais absolument rien au sujet, juste que ça existe...

Citation:

---

Envoyé par luckyvae

Un autre truc auquel je pense: la compilation de code java en code natif via gcj, est-ce que cela permet d'avoir de meilleurs/moins bonne/identique performance? Je ne connais absolument rien au sujet, juste que ça existe...

---

D'après http://shootout.alioth.debian.org/sa...t=all&lang=gcj c'est mitigé. Des fois c'est mieux, des fois non. En regardant les tests dans l'ensemble il ne me semble pas y avoir de vainqueur. Cela dit ce sont des benchmarks, donc de là à savoir ce que cela donnerait sur une application complète...

Citation:

---

Envoyé par luckyvae

on est d'accord ;)


à l'exception que je n'ai jamais fait de C++ et que je programme quasi qu'en java et que j'aime ça ;)


oui, et il ne parle à aucun moment du fait que ça tournerait sous Wii. Il dit qu'il a utilisé AvetanaBT pour linux, qu'il a fait une dll jni pour windows et qu'il a utilisé jme.


Un autre truc auquel je pense: la compilation de code java en code natif via gcj, est-ce que cela permet d'avoir de meilleurs/moins bonne/identique performance? Je ne connais absolument rien au sujet, juste que ça existe...

---

Je déconseille GCJ. C'est un mythe que parce que c'est natif ça tourne plus vite. Une JVM sert aussi à optimiser les performances, pas juste à consommer de la mémoire et du temps CPU pour rien et ainsi de tendre le bâton pour se faire battre par les fans du C++. De plus, il me semble que GCJ n'est pas compatible avec Java 1.6.

Si tu aimes bien Java et que tu programmes des jeux dans ce langage, même des projets assez simples, n'hésite pas à les soumettre sur "The Java(tm) Game Tome" : www.javagametome.com
Les projets en cours qui ne sont pas encore jouables sont placés dans l'incubateur, je pense le créer sous peu car quelques programmes intéressants sont de bons candidats pour y figurer.

C++ autorise l'insertion de code assembleur ou d'appel aux intrinsics pour les fortes parallelisations, ce qui n'est pas possible en java je pense. donc oui, quand on a besoin de plus de controle on prend du C++.

il y a quand meme une raison pour laquelle la plupart des boites utilisent le C++ et pas le java pour le jeu video, et que l'ecrasantemajorité des jeux soit faite en C++. dans les jeux notés 70+ dans les magazines, combien sont en Java ?

alors traiter tous les developpeurs de jeux videos de cons parce qu'ils ne savent pas ce qu'ils disent et que java va plus vite, ca commence a bien faire, il faudrait songer al acher un peu quelques centimetres de terrain parfois.

il y a une raison aussi bien historique a la faible representation de java, c'est un langage relativement neuf sur le plan du jeu video donc mal maitrisé et connu.

Citation:

---

On parle de RTTI (Run-Time Type Identification). Java détecte par défaut le type dynamiquement sauf si on lui précise le contraire (modifieur "final"), C++ détecte le type statiquement sauf si on lui précise le contraire (modifieur "virtual", mot-clé "dynamic_cast<>"). La méthode statique est moins coûteuse mais peut amener des problèmes difficiles à déceler alors que la méthode dynamique est plus coûteuse mais plus simple à appréhender en Java tout du moins selon moi.

---

Si tu veu mon avis,cet exemple montre parfaitement pourquoi les developpeurs utilisent c++ plutot que java.
On ne peut pas nier que la JVM prend de la puissance.C++ et Java possede tout les deux des optimisations,mais je ne voit pas comment Java pourait etre plus performant que le c++ en terme de vitesse.

Cela dit,pour les 99% des projets,et particulièrement les projets amateurs,qu'ils soient en c++ ou en java ne feras aucune différence dans les perfs,vu qu'il y a énormément de choses a optimiser avant.
Et la portabilité du Java est un atout énorme.

Citation:

---

Envoyé par gouessej

Si tu aimes bien Java et que tu programmes des jeux dans ce langage, même des projets assez simples, ....

---

tu nous refait un débat Java Vs C++.
Moi je n'y crois pas trop à Java pour les jeux vidéos commerciaux les gros titres parce que, comme je le répète, les SDK sont principalement en C++
Tu prends Direct X c'est essentiellement en C++, OpenGL aussi,SDL etc..
Je dis pas que cela ne soit pas réalisable avec d'autres langages mais le C/C++ semble être le langage le plus approprié pour faire des jeux vidéos.
Quand tu as des milliers d'objets à afficher dans une boucle de rendu et que tu as une IA derrière je n'y crois pas trop à Java ; en Java tu ne peux pas accéder à des pointeurs live;
d'accord c'est le majeur défaut du C/C++ et si c'est mal géré tu as plantages ou fuites mémoires.
Mais dans le cas de Java voire .NET si à chaque instruction tu vérifies si tu ne déclenches pas une exception parmi des milliers ceci dans une boucle de rendu les performances doivent en patir..
Est-ce que tu comprends ce que je veux dire ?

Citation:

---

Envoyé par gusgus

Si tu veu mon avis,cet exemple montre parfaitement pourquoi les developpeurs utilisent c++ plutot que java.
On ne peut pas nier que la JVM prend de la puissance.C++ et Java possede tout les deux des optimisations,mais je ne voit pas comment Java pourait etre plus performant que le c++ en terme de vitesse.

Cela dit,pour les 99% des projets,et particulièrement les projets amateurs,qu'ils soient en c++ ou en java ne feras aucune différence dans les perfs,vu qu'il y a énormément de choses a optimiser avant.
Et la portabilité du Java est un atout énorme.

---

C'est trop tard, c'est fait, il arrive parfois que la JVM arrive à aller plus vite que du code natif. Je te rejoins sur le fait qu'il y a plein de choses à optimiser avant, je suis entièrement d'accord. Pinailler entre C++ et Java pour un projet amateur ne sert pas à grand chose. Si ton scénographe est pourri, peu importe le langage, ça se verra sur les performances. Je sais très bien que dans les deux langages tu as de très bons moteurs sauf que les moteurs commerciaux sont plutôt écrits en C++ à l'heure actuelle.

L'adage "Write Once, Run Everywhere" est à peu près vérifié sur PC mais c'est l'enfer sur mobile. La portabilité de Java est quand même satisfaisante.

Citation:

---

Envoyé par Mat.M

tu nous refait un débat Java Vs C++.
Moi je n'y crois pas trop à Java pour les jeux vidéos commerciaux les gros titres parce que, comme je le répète, les SDK sont principalement en C++
Tu prends Direct X c'est essentiellement en C++, OpenGL aussi,SDL etc..
Je dis pas que cela ne soit pas réalisable avec d'autres langages mais le C/C++ semble être le langage le plus approprié pour faire des jeux vidéos.
Quand tu as des milliers d'objets à afficher dans une boucle de rendu et que tu as une IA derrière je n'y crois pas trop à Java ; en Java tu ne peux pas accéder à des pointeurs live;
d'accord c'est le majeur défaut du C/C++ et si c'est mal géré tu as plantages ou fuites mémoires.
Mais dans le cas de Java voire .NET si à chaque instruction tu vérifies si tu ne déclenches pas une exception parmi des milliers ceci dans une boucle de rendu les performances doivent en patir..
Est-ce que tu comprends ce que je veux dire ?

---

Je ne refais pas un débat Java versus C++; des programmeurs C++ me répondent, c'est tout. Je comprends ce que tu veux dire et ça ne tient pas la route, ce n'est pas vérifié dans la réalité. Certes, la sécurité a un coût, il faut garder les pieds sur terre, mais tu le surestimes. On peut utiliser OpenGL en Java, où est le mal? Ca te dit quelque chose JOGL? LWJGL? Connais-tu JME? JOAL? JORBIS? JOGG? Java3D? JInput? Tu n'y crois pas mais je ne parle pas de croyance, il y a déjà de bons moteurs 3D en Java, je ne vais pas les citer encore une fois de plus. On a ce qu'il faut. Là où pèche Java c'est par son manque d'une solution unifiée comparable à XNA mais tu peux tout à fait composer une solution complète convenable en regroupant plusieurs produits cités précédemment, LWJGL est déjà assez complet par exemple car il regroupe DevIL, FMOD, JOAL, OpenGL et JInput (j'en oublie surement, désolé).

je ne parlais pas de parallelisme de thread mais de parallelisme d'instruction, le SSE(2)
c'est tres utilisé dans le jeu video de part la nature des données traitées (vecteurs et matrices)

de part la taiille des données traitées (vertex buffer, index buffer, mais aussi les structures d'organisation des objets dans l'espace comme les quad tree et les sphere tree) on manipule des grosses memoires, en travaillant activement avec le cache CPU. la JVM fout la moitié de ton cache en l'air sans raison

enfin, les programmeurs de jv ont un controle tres pointu des allocations. on sait en gros quand un objet est alloué ici, quand et ou il sera desalloué, ce qui permet de choisir ou le mettre en memoire. les sphere tree ou quad tree sont contigus en memoire et on utilise un "placement new" pour creer les cases, garrantissant la localité de l'arbre et permettant d'utiliser efficacement le cache.


si je devais donner le probleme numero 1 du java pour un jeu video recent, c'est le support de DX.
Si je devais donner le probleme numero 2, c'est le non controle des allocations. deja en C++ beaucoup pensent que ce n'est pas suffisant, imagine.

Citation:

---

Envoyé par screetch

Si je devais donner le probleme numero 2, c'est le non controle des allocations. deja en C++ beaucoup pensent que ce n'est pas suffisant, imagine.

---

Comme le dit le dicton :mrgreen: :

• Les développeurs C++ pensent que l'allocation de la mémoire est trop importante pour laisser le compilateur/MV l'a gérer
• Les développeurs Java pensent que l'allocation de la mémoire est trop importante pour laisser les développeurs l'a gérer

Citation:

---

Envoyé par screetch

je ne parlais pas de parallelisme de thread mais de parallelisme d'instruction, le SSE(2)
c'est tres utilisé dans le jeu video de part la nature des données traitées (vecteurs et matrices)

de part la taiille des données traitées (vertex buffer, index buffer, mais aussi les structures d'organisation des objets dans l'espace comme les quad tree et les sphere tree) on manipule des grosses memoires, en travaillant activement avec le cache CPU. la JVM fout la moitié de ton cache en l'air sans raison

enfin, les programmeurs de jv ont un controle tres pointu des allocations. on sait en gros quand un objet est alloué ici, quand et ou il sera desalloué, ce qui permet de choisir ou le mettre en memoire. les sphere tree ou quad tree sont contigus en memoire et on utilise un "placement new" pour creer les cases, garrantissant la localité de l'arbre et permettant d'utiliser efficacement le cache.


si je devais donner le probleme numero 1 du java pour un jeu video recent, c'est le support de DX.
Si je devais donner le probleme numero 2, c'est le non controle des allocations. deja en C++ beaucoup pensent que ce n'est pas suffisant, imagine.

---

Moi DirectX je m'en fous, je préfère OpenGL qui en fait autant (bien que OpenGL 3 prend beaucoup de retard, je le concède). Explique moi pourquoi tu dis que "la JVM fout la moitié de ton cache en l'air sans raison". Il y a bien une raison si c'est vraiment le cas, la JVM ne fait pas ça juste pour te donner un bel argument.

Avec JOGL, on peut utiliser des nio buffers pour créer des VBO et il existe déjà des moteurs en Java qui implémentent les quadtrees (JavaIsDoomed par exemple), ça n'a pas l'air si bloquant que ça...

tu es fatigant. pas de support des consoles, 120% des ressources au lieu de 100, voila, tout est dit, le marché s'orientant fortement vers les consoles et Dx10, java ne fera pas partie des grands élus. j'ai dit plus haut que cependant 90% des projets pourraient l'utiliser, pour ces 90% c'est le nombre de docs assez faible et le nombre de libs moindre qu'en C++ qui emporte la decision.

Tiens je l'avais pas vu ce thread.

Alors JAVA j'y ai passé 6mois à faire des tests et a écrire ma propre API avec.
Le langage est productif et eclipse de très bonne qualité, ceux qui diront le contraire ne se sont pas penché dessus.

Mais malgré tout le bien que l'on puisse voir dans JAVA, il n'est clairement pas fait pour le jeu. Sans rentrer dans des considérations de Perfs, les APIs sont inexistante. 5 mois sur JOGL pour en arriver à la conclusion que je perdais mon temps.

J'ai développé il y a 3ans maintenant un framework en C++ dans le style de SDL et sfml plus récent et vraiment il n'y a pas photo, facile d'optimiser avec le C++ et surtout TOUTES les librairies interessantes permettent d'utiliser le langage.

J'ai essayé Ruby, Python durant 3 mois et JAVA durant 6 mois mais je reviens toujours au C++.

Bon la ca fait un bon moment que j'explore C# et toutes ces lib WPF, WCF, WF, LINQ, ..., et vraiment encore une fois JAVA est à la rue. Si je trouvais JAVA pratique, C# est magnifique.

Maintenant je vais me pencher sur la conception d'un jeu avec afin de me faire une idée de ce langage dans ce domaine. Je vois que microsoft à pensé a tous avec XNA, encore plus depuis la version 3.0, mais je regrette vraiment de ne pas avoir accès à OpenGL ou DirectX, car si c'est pour retomber dans des APIs haut niveau difficilement customisable, je craint d'être déçu comme je l'ai été avec JAVA.

Citation:

---

Envoyé par ash.ice.loky

Bon la ca fait un bon moment que j'explore C# et toutes ces lib WPF, WCF, WF, LINQ, ..., et vraiment encore une fois JAVA est à la rue. Si je trouvais JAVA pratique, C# est magnifique.

---

si tu dis de C# qu'il est magnifique j'imagine que c'est uniquement du fait des bibliothèques qui s'accumulent autour de lui, notamment XNA pour le jeu vidéo ?

parceque niveau langage, java écrase C# (qui en a repompé 80% des idées)
C# est encore jeune mais M$ investit énormément de resouces dedans (autant humaines que financières)
et les problème entres C# et C++ sont les mêmes qu'entre java et C++

s'il existait un XNA en java, on pourrait sérieusement faire des jeux en java
par sérieusement j'entend un jeu jouable, commercialisable, capable de concurrencer les "crysis" et autres "gears of war" "gtr2" "gta" ect

quelqu'un de motivé ici pour développer un XNA pour le java ? :aie:

vois tu shenron666, je suis plus nuancé que toi.
mis à part les librairie de C#, qui sont EXCELLENTE, et pourtant j'aime réinventé la roue, je trouve le langage C# très conviviale.
je ne parle de XNA, car même si je suis son actualité je ne m'y suis pas encore essayé, comme je le dis j'aurais préféré faire du DX directement.

Pour revenir sur le langage, il propose des atouts indéniable tel que les classes partielle, les requetes SQL sur des collections via LINQ, quel bonheur que de retrouver une sous collections d'objet au sein d'une Liste avec un paquet de conditions en une ligne, sans pour autant bridée les perfs ou perdre le typage.

Je ne sais pas si tu as longuement essayé le C# ou si c'était il y a un moment, mais je trouve que sur la version 3 et encore plus la 3.5 M$ a fait des efforts énormes.

Même sans parler JeuxVideo j'ai encore du mal a trouver des avantages a JAVA sur C#, et puis bon venant du C++ que j'aime toujours autant, rester en environnement VisualStudio c'est un vrai bonheur.

Hélas je regrette que l'on ne puisse faire du DX10 en C#, je me serais bien essayé.

concernant le C# je dois y passer :aie:
avec un peu de chances ça ne se fera pas, les limitations imposées ne me plaisent pas
quand on a gouté au c++ on a du mal à revenir en arrière en laissant la machine virtuelle gérer entre autres la mémoire à sa place
si elle le fait bien tant mieux, si elle le fait mal, tu ne peux rien y faire
et le problème est le même en java

et puis en c++ si tu veux un garbage collector tu en code un ou tu en utilise un que d'autres ont fait :bug:

côté perfs, M$ ont encore de très gros efforts à fournir
on a de gros problèmes de perfs avec les applications C# comparées à leur équivalent en C++ (sur un P3 1GHz avec 512Mo de ram l'application C# prend beaucoup plus de resources et se trouve être au moins 3 fois plus lente :aie:)

concernant dx10 tu es certain que le dernier SDK ne permet pas de l'utiliser en C# ?

Oui idem j'ai du passer a JAVA pour le boulot et maintenant C#, j'en profite donc pour voir ce que ça donne en profondeur, surtout coté jeux.

Je suis aussi un grand fan du C++, mais bon avoir plusieurs corde a son arc n'est pas un désaventage, par exemple pour codé un éditeur de carte pour un STR, en C++, même avec mon framework ca prend plus de temps qu'en WPF avec C#, et a ce niveau les perfs tu t'en fou un peu ;-)

Par contre oui tout ce que j'ai trouvé semble confirmer que DX10 est limité au C++ ...