POur agumenté un peu tout le debat,
voici un ensemble de bench réalisé avec différent language.
Je vous laisse juger.
http://shootout.alioth.debian.org/
Ps : les dernier bench ne sont pas complet. Plutôt regardé ce de 2007
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
POur agumenté un peu tout le debat,
voici un ensemble de bench réalisé avec différent language.
Je vous laisse juger.
http://shootout.alioth.debian.org/
Ps : les dernier bench ne sont pas complet. Plutôt regardé ce de 2007
Visiblement java tire bien son épingle sur le systemes multi-cores face a un programme en C++ non multithreadé car il est capable de partager la charge sur les cpu dans certains cas.
Je ne suis pas convaincu du résultat face a un vrai programme en C++ multithreadé.
Cela dit, le gros point faible de java est pas dans la puissance de calcul mais dans la consommation mémoire, ce qui peut mener a des lenteurs, mais pas dans tous les cas.
Passe un coup de FindBugs sur Eclipse et tu vas comprendre que c'est plutôt une usine à gaz donc l'argument d'Emmanuel tombe à l'eauEnvoyé par mavina
Le souci dans ce raisonnement étant qu'on ne sait pas (je n'ai pas regardé le code d'Eclipse, je ne sais pas si c'est OS) si Eclipse est bien programmé ou si c'est une énorme usine à gaz
Faudrait regarder le code. On peut toujours programmer un Editeur en C++ qui rame à fond, suffit de mal programmer
F.
On n'a pas besoin de DirectX puisqu'il y a OpenGL et que Microsoft ne voudra jamais que DirectX puisse marcher en Java. Cependant, dans JavaFX, il y a déjà des dll qui tritouillent Direct3D, tu peux peut-être t'en sortir en partie avec ça, à vérifier.
Java prend quand même de l'âge
Et C++ aussi.
Java a depuis la version 1.3 des moyens de faire des jeux 2D très rapides. On en trouvait il y a quelques années, certains très réussis.
Pour la 3D, c'est plus galère. Java ne gère pas les SIMD, il lui manque des directives de vectorisation.
C/C++ sont utilisables, mais la vectorisation n'est pas franchement native, on se retrouve quasi à faire de l'assembleur.
Si vous voulez un langage TRES rapide en maths, multiplication de matrices, parallélisation, et simple d'écriture, prenez le FORTRAN, il a été conçu pour cela et a très bien évolué.
Si vous voulez être très tendance, utilisez la LLVM pour compiler. Vous obtenez quelque chose de jittable, avec un bon support des SIMD.
Mais comme je l'ai lu plusieurs fois:
- un bon jeu n'est pas le plus beau
- un bon jeu n'est pas n'est pas le plus évolué
- un bon algo est plus sûr qu'un bon langage
Donc pour faire un bon jeu, AVANT de se demander quel est le langage qui donnera les meilleures performances (ce qui dépend de la plate-forme), mieux vaut se demander:
- si le jeu peut être intéressant
- si le jeu peut être prenant
- de quels outils doit-on disposer pour créer les graphismes, les animations, les niveaux? (et là je déconseille de créer des outils en C++, c'est généralement une perte de temps face aux langages évolués avec une bibilothèque standard plus complète)
- quels joueurs sont ciblés? (si on cible un maximum de personnes, il faut que le jeu tourne sur des procs de base et des cartes graphiques intégrées)
Pour refaire un monkey island, autant utiliser Java. Pour un gros jeu 3D, il faut être plus proche du système (peut-être seulement pour le graphisme?)
Pour faire un jeu tout seul, autant utiliser un langage qu'on maîtrise.
Pour programmer en équipe, autant utiliser un langage que tout le monde connaît.
Enfin, il faut rester honnête: OpenGL même en version 3 ne rivalise toujours pas DX 10. Une bonne nouvelle cependant: MS n'a pas son mot à dire en ce qui concerne la réalistion d'un binding Java de DirectX. La license d'utilisation de la technologie ne dit pas "vous ne l'utiliserez qu'en C++ ou C#". Elle dit grosso-modo "amusez vous bien".
Ca vient du fait que tout le monde est d'accord pour dire que Java est parfaitement adapté à la réalisation de jeux "casual", et qu'on a tous admis aussi que certaines tâches particulière des jeux AAA peuvent être exécutées dans un environnement Java. Il ne reste donc que cette question làle débat a un peu/complétement dévié sur "Le langage Java est-il adapté pour les jeux vidéo AAA ?"
[FAQ des forums][FAQ Développement 2D, 3D et Jeux][Si vous ne savez pas ou vous en êtes...]
Essayez d'écrire clairement (c'est à dire avec des mots français complets). SMS est votre ennemi.
Evitez les arguments inutiles - DirectMachin vs. OpenTruc ou G++ vs. Café. C'est dépassé tout ça.
Et si vous êtes sages, vous aurez peut être vous aussi la chance de passer à la télé. Ou pas.
Ce site contient un forum d'entraide gratuit. Il ne s'use que si l'on ne s'en sert pas.
Certes, il manque à OpenGL 3 le gros ménage prévu depuis longtemps mais en terme de fonctionnalités bas niveau, ça vaut DirectX10 sans problème. Il y a déjà eu un projet de portage de XNA à une époque mais c'est tombé à l'eau parce que la communauté a préféré se concentrer sur OpenGL et c'est normal puisque Java n'est pas fait que pour Windows.
Avengina est une belle démonstration de ce que pourrait être un jeu AAA selon moi.Ca vient du fait que tout le monde est d'accord pour dire que Java est parfaitement adapté à la réalisation de jeux "casual", et qu'on a tous admis aussi que certaines tâches particulière des jeux AAA peuvent être exécutées dans un environnement Java. Il ne reste donc que cette question là
On en a déjà parlé, c'est pas la fin du monde que Java ne gère pas les vecteurs SIMD et les bindings OpenGL pour Java tiennent la route alors non, ce n'est pas galère du tout, ça marche très très bien.
Ca n'empêche pas certains laboratoires de physique de porter progressivement leurs bibliothèques en C++ voire en Java.
On n'est pas obligé d'être près du système pour faire un gros jeu en 3D. La machine virtuelle Java, le ramasse-miettes et le compilateur JIT sont assez mûrs, il y a de quoi faire. Ce n'est pas dit que tu es de meilleurs performances en choisissant une approche bas niveau. Par exemple, quand tu codes en assembleur et que tu compares ce que te sort GCC, tu te rends compte qu'il est difficile de faire humainement mieux (sauf si tu as un égo démesuré). Il en est de même pour la machine virtuelle Java. Parfois, en voulant optimiser (je parle de micro-optimisation là), tu peux faire une bourde qu'un compilateur ou une machine virtuelle ne ferait pas.
Je te rejoins en ce qui concerne l'importance des algorithmes, c'est pour cela que je dis aux gens qu'il faut se préoccuper de ça en priorité avant même de penser à optimiser certaines opérations mathématiques.
Dernière modification par Invité ; 05/09/2008 à 13h51.
tu a bossé sur combien de moteur de jeux AAA pour sortir une bêtise comme ça ? au contraire, le SIMD est le seul moyen d'exploiter au mieux les processeurs actuel. en dehors du multi core, les deux grosses inovations pour la perf pure en terme de processeurs depuis le pentium sont le X64(qui est d'un avantage douteux pour la perf justement) et les instructions super scalaires, donc s'en privé, c'est se priver de tout ce que nous apporte les proc modernes... Je perle bien entendu en dehors du cadre du multi core qui est aussi bien géré par les deux langages.
certe, tu va difficilement battre le compilo sur l'ensemble du projet, par contre, sur des partie restreinte pour lesquelles un profiler t'auras donnée des info précises sur les perfs en utilisation réelle, tu peut sans problème battre le compilo en réorganisant ton code et en faisant des micro optim a base d'instruction SIMD justement... mais ça, tu ne peut pas le faire en Java
* Il est infiniment plus simple de faire rapidement un code qui marche que de faire un code rapide qui marche
* pour faciliter les recherches, n'oubliez pas de voter pour les réponses pertinentes
Mes articles
Sur ce point, un collègue m'a parlé d'une équipe qui travaille dans les jeux vidéos pour portable, et donc obligatoirement en Java. Cette équipe avait tellement de mal à gérer les incompatibilités entre les différents Javas des différents téléphones du marché, qu'elle a pris une décision drastique.
Elle écrit désormais son code en C. Elle dispose ensuite de "compilateurs" qu'elle a réalisé elle même qui génèrent à partir du C le code Java qui va bien pour chaque destination (je ne sais pas s'il y a un code par destination, ou un code unique qui soit est hyper restreint, soit fait des tests en fonction de l'architecture cible).
Ma session aux Microsoft TechDays 2013 : Développer en natif avec C++11.
Celle des Microsoft TechDays 2014 : Bonnes pratiques pour apprivoiser le C++11 avec Visual C++
Et celle des Microsoft TechDays 2015 : Visual C++ 2015 : voyage à la découverte d'un nouveau monde
Je donne des formations au C++ en entreprise, n'hésitez pas à me contacter.
Et là entre nous, pourquoi ne pas avoir développé un framework avec une précompilation ?...
Le problème, c'est pas java, c'est les constructeurs de portables. Quand tu vois que le, par exemple, nokia 6230, sur un drawRegion de x pixels il en oublie un. Chaque machine virtuelle de chaque constructeur et de chaque téléphone est différente parceque chaque téléphone ne supporte pas telle ou telle feature.
Mais l'équipe de travail dont tu nous parle, elle a mal géré son truc, ,un framework aurait été beaucoup plus flexible, il en existe même des tout faits avec Neomad par exemple!
F.
Développeur Java / Flex à Shanghai, Chine
mes publications
Mon dernier tutoriel : Messages Quit IRC : explications
La rubrique IRC recrute des redacteurs : contactez moi
Ce flim n'est pas un flim sur le cyclimse. Merci de votre compréhension.[/SIZE]
ouch! il risque de galerer pas mal, un generateur de Java ecrit en C c'est un peu le monde à l'envers, un generateur Java=>Java ou bien à la limite pourquoi pas C++=>Java , mais de C vers Java, c'est un peu comme ecrire de l'ASM qui produirais du PHP. je pense pas qu'ils aient pris la meilleur solution la ?, peut-etre separer les parties "incompatibles" dans une API Java specifique par tel aurait etait mieu, non ?
+1Mais comme je l'ai lu plusieurs fois:
- un bon jeu n'est pas le plus beau
- un bon jeu n'est pas n'est pas le plus évolué
- un bon algo est plus sûr qu'un bon langage
je suis pas tout à fait d'accord, il y'a des centaines de language mais même pas une dizaine de facon de programmer, un bon developpeur doit pouvoir basculer d'un language à l'autre sans prob. Un dev sui sait bien dev en Objet dans un language n'aura aucun mal apres qq tps à dev en C++,JavaScript,PHP,etc... meme si il n'a jamais touché au language, et qqun qui sait dev en ASM sur PC pourra sans prob dev un truc en assembleur sur une autre plateforme. l'important c'est pas le language, le language c'est juste un outil qu'il faut choisir adapté à la cible pas au developpeur.Envoyé par Rep.Movs
...Pour programmer en équipe, autant utiliser un langage que tout le monde connaît....
Perso,j'ai compris que c'est un compilateur qui traduit du C en JAVA. Ce n'est pas pareil.ouch! il risque de galerer pas mal, un generateur de Java ecrit en C c'est un peu le monde à l'envers, un generateur Java=>Java ou bien à la limite pourquoi pas C++=>Java , mais de C vers Java
http://www.jazillian.com/indexC.html...FRTyXgodRVyXiQ
Combien de gens ici ont réellement travaillé sur des moteurs de jeux AAA? S'il faut développer un moteur de jeux AAA pour avoir le droit de s'exprimer ici, alors il ne va pas rester grand monde.
Il y a d'autres formes de parallélismes, tout ne s'arrête pas au parallélisme d'instructions. J'ai déjà dit qu'il y a plein d'autres pistes à exploiter pour optimiser son moteur sans descendre si bas niveau. Tu auras beau penser au SIMD, si ton algorithme de subdivision de l'espace est gourmand et lent, tu auras pris le problème à l'envers et quelqu'un qui aura d'abord optimisé cet algorithme sans penser au SIMD aura de meilleures performances que toi. Ca ne veut pas dire qu'il ne faut pas penser à utiliser le SIMD, ça veut dire que chaque chose vient en son temps et qu'il y a plein de choses à optimiser avant ça. C'est pourquoi au final, comme les optimisations de haut niveau auront souvent plus d'impacts que les micro-optimisations et qu'elles ne sont pas spécifiques à certains langages (on reste dans le domaine algorithmique), Java n'est pas spécialement handicapé. Le SIMD est la "cerise" sur le gâteau, pas le gâteau.
Tu battras le compilateur mais à quel prix en terme de portabilité? De plus, tu ne peux pas le faire en Java pur mais personne ne t'interdit d'appeler du code C ou directement de l'assembleur en Java (ce que je ne recommande pas justement pour des raisons de portabilité).certe, tu va difficilement battre le compilo sur l'ensemble du projet, par contre, sur des partie restreinte pour lesquelles un profiler t'auras donnée des info précises sur les perfs en utilisation réelle, tu peut sans problème battre le compilo en réorganisant ton code et en faisant des micro optim a base d'instruction SIMD justement... mais ça, tu ne peut pas le faire en Java
Mais, on avait pas dit que le fait de "délocaliser" les parties vraiment critiques vers le C++ permettait justement potentiellement à Java de faire un jeu AAA ?
je crois que dans cette discussion au moins 3 personnes ont bossé ou bossent sur des jeux AAA, mais je ne peux pas en etre certain...
Ce n'est pas nécessaire selon moi même si c'est ce qui a été fait en partie pour Night Squad 2 si j'ai bien compris. Comme je l'ai dit, je pense qu'il y a bien d'autres optimisations possibles avant d'en arriver là. Il faut s'entendre sur ce qu'on appelle les parties critiques et il faut vérifier si on y gagne vraiment au final. De toute façon, quand tu utilises un binding d'OpenGL en Java, tu appelles du code C/C++, les opérations vectorielles d'OpenGL sont donc faites de la même façon quel que soit le binding que ton jeu utilise (PyOpenGL, JOGL, LWJGL, GL4J, Tao Framework...).
La GLU a été réécrite en Java pur pour améliorer les performances. J'entends par là que le fait d'écrire du code en Java pur peut être plus optimisé que d'appeler du code C/C++ via JNI/JNA, cela ne vient pas seulement de l'overhead dû aux accès à du code natif, cela vient aussi du fait que Java peut intrinsèquement aller plus vite que C++ parfois. Ca va donc dans les deux sens, appeler du code C++ n'est pas la solution magique.
Ok, qu'ils se manifestent alors. Ca ne doit quand même pas servir d'appui pour sortir des arguments d'autorité. Beaucoup de développeurs m'avaient donné tort sur la question du verrou de Cardan il y a quelques années et il s'est avéré que c'étaient eux qui avaient tort au final (ils ne sont pas infaillibles, errare humanum est), la foire aux questions sur les matrices et les quaternions va être mise à jour sous peu en conséquence, je remercie une fois de plus le professeur Pascal Mignot au passage, il ne développe pas de jeux AAA mais son aide m'a été fort utile, comme quoi le fait d'être un développeur de jeux AAA n'est pas nécessaire pour contribuer au développement de jeux vidéo et à ce forum.
Je précise que je ne remets pas en question le talent des développeurs de jeux AAA, je dis juste que ce serait un raccourci un peu rapide de dire "ok tu développes des jeux AAA alors tu as forcément raison".
Dernière modification par Invité ; 10/09/2008 à 19h04.
Bonne nouvelle!!! Funcom développe un MMO en Java, sa sortie est prévue en 2009 :
http://www.funcom.com/funcom/fronten...esentation.pdf
http://www.jeuxonline.info/actualite...com-casual-mmo
Ca sent bon tout ça
Pour en rajouter une couche, quelqu'un ici a laissé entendre que les "array bounds checks" sont coûteux en Java. En fait, on peut les désactiver, c'est juste que la solution de contournement est un peu tirée par les cheveux, il faut passer par sun.misc.Unsafe. Cependant, vous ne gagnerez que 5% de vitesse pour les tableaux de base et ça ne vaut pas le coup si vous utilisez déjà pas mal les nio buffers. J'en conclus que l'argument des "array bounds checks" ne tient pas vraiment la route comme ça ne change pas grand chose quand on s'en passe, on prend juste plus de risques.
non non, c'est vraiment une plaie ces trucs... y'a pas à tortiller ca rend l'acces aléatoire à des tableau bcp plus lent. c'est plus de l'ordre de 50% que de 5%. une fois en assembleur un acces tableau c'est quasi qu'un MOV avec les bounds check y'a deux tests en plus + les chargements de registres qui vont bien. c'est tres bien les bounds check pour la stabilitée mais faufrait vraiment un moyen de les controler en dehors des class sun non-officielle.Cependant, vous ne gagnerez que 5% de vitesse pour les tableaux de base et ça ne vaut pas le coup si vous utilisez déjà pas mal les nio buffers
Je vous conseille d'aller jeter un coup d'oeil ici (un jeu Java utilisant Project Darkstar) :
http://www.callofthekings.com
Bonjour, j’ai vu qu’il y avait eu un gros débat, ici.
La raison pour laquelle je suis venu poster ici, c’est que avec un amis, nous avons l’intention de développer un mmorpg en 2D.
Notre première idée fut celle de le développer en java, vu que nous connaissons de mieux en mieux ce langage et que nous l’apprécions énormément. Nous ne comptons pas coder un jeu professionnel, ca serait vraiment un jeu amateur comme ont les aimes.
Comme j’ai vu qu’il y avait pas mal de monde avec de bonnes connaissances en programmation de jeux ici, je me suis dis que vous pourriez nous aidez en nous donnant une idée des outils qui sont disponibles. On nous a déjà conseillé la SDL pour java, mais je voudrais savoir s’il existe d’autres technologies disponibles et performantes. On nous a aussi dit l’opengl. Mais est ce bien utile pour un simple jeu en 2D.
J’espère que vous pourrez nous aidez.
Stag.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager