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 :
(en faisant abstraction de l'attaque personnelle que tu viens de faire, parce qu'on a tous bien vu que le jeu java que tu montres est celui de gouessej)
il y a aussi une différence de budget, et ça, ça fait une TRES grosse différence. essayons de comparer ce qui est comparable, pour que ce thread ne soit pas qu'un vulgaire troll....
il y a jbullet, le portage java de bullet. Celui ci fonctionne bien mais est plus lent que la version C++Envoyé par flyweight
C'est vrai. JBullet est même plus gourmand en mémoire que la version C++ mais ça ne vient pas de Java, c'est dû en majeure partie à l'utilisation de javax.vecmath (ça ne fait pas partie du Java de base) qui est connu pour produire beaucoup de "déchets", c'est un choix de programmation qui a été très critiqué par les programmeurs de jeux vidéo en Java.
Déjà, juste un détail, "jeu" au singulier ne prend pas de "x".
Deuxième chose, mon jeu tourne à 500 FPS sur une ATI HD 4850 :
http://tuer.tuxfamily.org/screenshot...0_1440_990.png
C'est peu vu la très faible complexité de la géométrie des niveaux mais je me suis déjà expliqué sur ce problème, ça ne vient pas de Java mais du fait que je n'utilise pas encore mon système de partionnement de l'espace.
Compare ce qui est comparable. Je développe ce jeu tout seul depuis octobre 2006, je n'ai pas eu beaucoup d'aides, j'ai fini par me débloquer tout seul à chaque fois sauf quand j'ai posé des questions sur le polygon offset (je crois que vous appelez ça le depth bias en DirectX). J'ai toujours écrit que je n'avais pas la prétention de faire un jeu de qualité commercial et je n'en ai absolument pas les moyens. J'ai déjà cité un grand nombre d'API et de moteurs, je suis fatigué de répéter la même chose. Je vois que tu cherches à me ridiculiser. Moi je suis satisfait par mon petit FPS tout pourri, je regarde l'évolution des performances, je suis passé de 64 Mo de mémoire et seulement 0.5 FPS à 11 Mo de mémoire réellement utilisés et 8 FPS sur une vieille bécane 700 Mhz avec une ATI Radeon 9250, je n'ai jamais prétendu rivaliser avec des jeux commerciaux réalisés par une équipe d'au moins 15 personnes, nécessitant plusieurs années de travail à plein temps et utilisant un moteur physique de grande qualité. J'espère uniquement que certains de mes algorithmes pourront être réutilisés dans d'autres projets et que mon jeu serve au moins à montrer qu'on peut créer un jeu vidéo en 3D en Java qui s'installe facilement sur 4 familles de système d'exploitation différentes.
Voici un meilleur exemple :
http://fr.youtube.com/watch?v=IpYrvuq9Jb8
En voici un autre :
http://www.avengina.org/
Ca ne vaut pas farcry mais c'est déjà un peu plus probant.
Avant de me chambrer, flyweight, peux-tu me dire quels jeux vidéo tu as écrit?
Dernière modification par Invité ; 10/08/2008 à 13h36.
Non mais son post était totalement démago, juste pour faire plaisir aux enfants et fanboys.
Déjà, Crytek n'a même pas développé Havok.
Ensuite, c'est pas parce que le jeu de gouessej tourne à 210 fps qu'il tournera forcément à 3 fps avec du rendu aussi joli que far cry 2.
Vive le raccourci qui n'a aucune valeur scientifique.
Tout ce qu'il y a à commenter, c'est qu'il n'y a pas autant de bibliothèques de bonnes qualités en Java, mais ca n'est pas dû à une raison technique, mais principalement pour des raisons sociologiques, c'est tout quoi!
-----
Forcément, quand tu payes des ingénieurs compétents pour faire un moteur physique, ben c'est sûr qu'il sera bon !
Pareil, Crytek, ils ont des gens qui publient au SIGGRAPH, c'est pas rien non plus.
Tout ça c'est pas à cause de C++, mais surtout grâce à des chercheurs. Après évidemment, il y aura des limitations de performances dûes à Java, mais ça on était conscient.
Les trucs comme ça n'ont pas été faits par des amateurs dans leur temps libre en général, parce qu'ils n'ont pas le temps !
Le problème de performance se situe surtout pour certaines opérations mathématiques (addition scalaire multiple par exemple) qui tirent fortement partie de SSE. Cependant, l'impact sur les performances globales de l'application est difficile à chiffrer et comme je l'ai déjà dit, Java a d'autres atouts de son côté pour "compenser". Il y a certaines parties de l'application où Java peut s'en sortir mieux que là où il y a beaucoup d'opérations sur des vecteurs, par exemple le décodage et l'encodage de fichiers au format XML. Je rappelle encore une fois que Jake2 va plus vite que son équivalent C/C++ sur certaines machines récentes, ça illustre bien ce que j'essaie d'expliquer.
Oui, et encore SSE c'est pas toujours la panacée, à part pour la racine carrée.
J'ai parfois perdu en performances (très légèrement), par rapport à une implémentation classique.
Enfin, c'est peut-être dû à une mauvaise utilisation, je ne sais pas, si certains veulent voir le code...
C'est vrai c'est un meilleur exemple.
Bonjour désolé si je n'ai pas lu toute la discussion, je me permettrais d'ajouter quelque mot au sujet des jeux en Java.
Je suis actuellement Beta testeur pour Wakfu développer par le studio Ankama, je suis pas la pour faire de la pub mais juste pour dire que le moteur 3D et même le jeu est développé en Java. Je peux vous assurer que niveau graphisme, c'est très très jolie, fluide, et que cela réagit très bien.
Je dirais sans hésiter après avoir vu cela que Java peux être utilisé pour réaliser d'excellent jeux. Je conseille à ceux qui le peuvent d'aller jeter un œil sur leur site.
ce qui veut dire 2D
mais sinon, http://www.tribaltrouble.com/ est bien en 3D et en java lui. C'est pas un jeu AAA, mais c'est un jeu complet, commercial en java....
Nous sommes tous d'accord à ce point du débat (je pense) pour dire que Java peut permettre de faire d'excellents jeux aux graphismes potables que ce soit en 2D ou en 3D.
Je pense qu'il reste encore à débattre de la possibilité (même si ça a déjà été fais sans grand succès) de Java à offrir des graphismes 3D de jeux de dernière génération (Bioshocks par exemple) :
- Possible ? au vue des réponses sur le débat, ce point reste obscure pour moi
- Performances ? si c'est possible, à quel prix ? (car si c'est pour ramer à 1 fps après sur une bête de course...
Bonne continuation à tous, je continu de suivre l'évolution du débat
Bonjour,
C'est quoi le AAA ?
C'est un jeu dont les attentes de la part de son publisher et du public sont grandes. Un jeu AAA ("twipeul É" ou triple A en anglais) aura un budget conséquent, un fort niveau de polishing, aura une couverture pub importante, aura des reviews dans tous les grands sites et magazines de jeu vidéo. Exemple de jeu AAA : Halo, Prince of Persia, the Sims 2, Need for speed underground etc.
Exemple de jeu non AAA : Backyard baseball, Braid, etc.
Le terme vient des agences de notations financières, les AAA, AA, A, B etc. indiquant le degré de confiance du retour sur investissement ou le risque de perdre de l'argent.
Bien entendu la distinction est arbitraire et n'est pas forcément très objective (si l'on s'en tient à la définition financière). Un jeu comme Crysis par exemple aura un polish et budget très important mais fera beaucoup moins d'argent que Wii Play qui est plutot basique au niveau de son développement/features mais se vend comme des petits pains.
C'est pareil pour les films, un film dont les espérances de gain pour le studio sont importante bénéficiera d'un budget promotionnel important parfois une partie importante du budget de production du film lui-même, le risque est de perdre beaucoup plus d'argent si le film floppe, mais de maximiser les revenus et le retour sur investissement si le film marche comme attendu.
LeGreg
Les jeux qu'on appelle "AAA" ou "triple A" sont les jeux de tout premier ordre, ceux qui font la fortune des magazines de jeux vidéo.
le AAA est un jeu généralement à très gros budget et souvent très attendu.
Donc ce qui manque en Java c'est le AAA qui peut se résumer par jeux à gros budget, et avec une équipe importante.
Donc ce n'est pas une question technique, mais uniquement "comme cela ne s'est jamais fait en Java, on ne prends aucun risque donc C++". C'est du conservatisme pure et simple.
Il me semble tout a fait possible de faire Doom 3 ou Crysis en Java, mais pour faire ces jeux, il faut être un certains nombres à temps plein sur 2 ans (donc il faut être payé).
Le plus important dans un jeux c'est la vitesse, et pour l'obtenir il faut utiliser les bons algorithmes. Il peut être nécessaire de refaire une routine en assembleur, mais le plus important c'est les algorithmes. C'est cela qui permet de passer de 20 fps à 65 fps. Si tu arrives en utilisant les bonnes structures de données à réduire le nombre de polygone à afficher à l'écran, tu peut en profiter pour activer des effets géré par la carte graphique. Et pour cela, le C, le C++ ou le Java c'est pareil.
Comme exemple de jeux commerciaux, on peut regarder du coté de Wakfu ou Tribal Trouble. Ils sont très jolie, bien fait, et commerciaux en plus. Peut être que cela donnera des idées à Ubisoft et consort.
Donc pour résumer:
- Pour faire des jeux à gros budget, on est obligé d'utiliser le C++, parce que sinon il y a trop de risque d'échouer.
- A mon avis, c'est tout a fait possible de faire de très gros jeux en Java.
- Pour tous les autres jeux (petit, moyen), on peut les faire en C++, en Java, ou en tout ce qu'on veux.
- Tous les effets graphiques peuvent être fait en Java comme en C++.
Il est fort probable que les prochains jeux de Microsoft soient en C#, car il a les moyens de prendre ce risque (et pas sun).
Voila.
Ok donc c'est les jeux à gros budget, des blockbuster.
En fait je pensais que cela avait a voir avec l'anti-aliasing.
Par contre, la plupart des magazines en France sont déficitaires. Les seuls qui font des bénéfices sont les magazines people (Paris match, voici, etc...). Tous les autres magazines on un taux d'invendu en 1/3 et 3/4. Voila pourquoi ils sont aussi chers.
Je l'ai déjà observé personnellement, et pas qu'une fois...
Dites vous que java n'est pas fait que pour le développement de jeux pc, Java ME existe, et dites vous que certains téléphones mettent une plombe à instancier une pauvre classe toute bête, alors appeller un GC... Par exemple, lorsque qu'on a porté le jeu sur lequel on travaillait sur le Motorola V500, on s'est vite rendus compte que c'était un téléphone qui allait nous poser énormément de problème. Lors d'une instanciation, il freeze quelques secondes, pareil lors d'un GC ou d'un accès RMS. Le plus drole, c'est le chargement d'images
Anyway, java a l'avantage de tourner sur toutes les plateformes, ce qui n'est pas du luxe en jeu vidéo mobile. Sinon, le marché n'existerai pas.
F.
Je crois qu'il ne faut pas confondre/comparer une JVM toute buggué avec celle qui se trouve sur un PC.Par exemple, lorsque qu'on a porté le jeu sur lequel on travaillait sur le Motorola V500, on s'est vite rendus compte que c'était un téléphone qui allait nous poser énormément de problème. Lors d'une instanciation, il freeze quelques secondes, pareil lors d'un GC ou d'un accès RMS. Le plus drole, c'est le chargement d'images
J'ai aussi fait du développement de jeux sur téléphone mobile, et certain téléphone avait effectivement des JVM vraiment bien buggué... Mais ce n'indique pas que forcément toutes les JVM réagisse de la même manière.
C'est un choix qui est fait. Ce n'est pas natif, et d'ailleurs comme tu l'as signalé, on parle de portage d'un téléphone à l'autre, à cause des résolutions/matériels différent, mais aussi des différentes version de JVM (J2ME et Doja) et des extensions disponibles sur les différents mobiles.
On pourrait très bien travailler en Symbian sur beaucoup de mobile et le portage serait aussi "simple" que pour JAVA.
C# fonctionne de la même manière que Java... on peut faire des jeux AAA en C#, donc pourquoi pas en Java...
C'était un commentaire sarcastique. L'idée sous-jacente était que les magazines de jeux vidéo sont plein de pub.
Mais bon, ça n'a rien à voir avec le sujet donc j'arrête là
C'est le noeud du problème.Donc pour résumer:
- Pour faire des jeux à gros budget, on est obligé d'utiliser le C++, parce que sinon il y a trop de risque d'échouer.
- A mon avis, c'est tout a fait possible de faire de très gros jeux en Java.
- Pour tous les autres jeux (petit, moyen), on peut les faire en C++, en Java, ou en tout ce qu'on veux.
- Tous les effets graphiques peuvent être fait en Java comme en C++.]
A l'heure actuelle, personne n'a encore prouvé que c'était faisable - même pas un petit hobbyiste dans son coin. Quake2 a été repris à toutes les sauces, Quake3 aussi, mais malgré le fait que toutes les informations pour refaire Doom3 en Java existe (format des maps et des modèles), je n'ai pas encore vu de jeux java utilisant ces technologies.
On oublie quand même un peu vite qu'au delà des algorithmes, il y a aussi des structures de données à gérer, et notamment des tableaux de vertex et d'indices. Je ne suis pas assez calé en Java pour être capable de dire si c'est effectivement un problème, mais mon idée est que le modèle Java impose non seulement un doublement de la mémoire mais aussi une conversion objet/structure au moment d'envoyer ces données à la carte graphique. Si il s'agit effectivement d'un problème, ça se transforme rapidement en une limitation importante.
Les jeux AAA nécessitent non seulement des algorithmes de plus en plus performant mais aussi des tonnes et des tonnes de données (rappel: Rage PS3 = 1 bluray); dans ce cadre, et si des conversions de données sont nécessaire (principalement à cause du modèle mémoire de Java), comment peut-on imaginer faire un jeu du niveau de Rage en Java ?
Bref: est-ce que les java boys ici-bas peuvent éclairer notre lanterne à ce sujet ? Que se passe-t-il lorsqu'on envoie des données à la carte graphique (texture, vertex buffer, ...) ? Quelles sont les opérations qui sont effectuées ? etc.
Sans même parler de problème de ressource, il faut aussi prendre conscience qu'un jeu, ce n'est pas qu'un programme qui affiche des images. Dans la boucle principale il y a 3 étapes : récupération des entrées utilisateur, mise à jour du modèle de données et rendu.
La mise à jour du modèle de données est la partie gênante. A l'heure actuelle, les blockbusters effectue cette opérations en plusieurs étapes, dont les deux principales sont sans conteste la mise à jour du modèle physique (collisions, réponses aux collisions, gestion des forces, ...) et la gestion de l'intelligence artificielle. Ces calculs sont exceptionnellement lourds dans certains cas, que ce soit dans le monde de l'IA (cf les possibilités du moteur Kynogon (gestion des comportements adaptés à l'environnement, path finding, gestion des lignes de tir, ...) ou même de PathEngine (path finding)) ou dans celui de la physique ( Havok Physics, PhysX). Pire, ces deux mondes se rencontrent aujourd'hui (cf les produits de Natural Motion ou Havok Behavior).
Les quelques middleware que j'ai cités sont pour la plupart multi-plateforme (je crois que la palme revient à Havok, qui tourne sur à peut prêt tout ce qui peut faire tourner un jeu vidéo: PS2, PS3, XBox, XBox 360, PC/Win, PC/Linux, Wii, Mac, ...) mais écrit en C++ et, pour certain, en partie en asm pour une excellente raison: il est hors de question qu'ils provoquent un ralentissement notable du jeu. Un jeu AAA doit tourner au minimum à 30 fps sur une machine cible donnée, ce qui signifie que ces calculs d'une lourdeur infâme doivent pouvoir ne prendre qu'une fraction des 33 ms alloués à la mise à jour et au rendu de chaque frame du jeu.
A moins que je ne me trompe, il n'existe pas à l'heure actuelle de produits aussi poussés en Java. Alors que les hobbyistes et les développeurs indépendants seraient les premiers concernés par ce type de produit fonctionnant sous Java, aucun développement d'envergure ne propose encore de solution viable. On trouve sans trop de problème des middleware physique/gestion de collision optimisés gratuits voire open source en C++, mais aucun de leur pendant Java n'offre le même niveau de performance (note pour moi-même: on trouve moins de benchmark orientés "java est plus rapide" sur les problèmes ou Java est assuré de perdre).
Bref, quoi qu'on en dise, si Java est - et je crois que tout le monde est d'accord - une plateforme suffisante pour le développement de jeux à faible consommation de ressources, ce sont principalement ses problèmes de mémoire et de performances qui font qu'il n'est pas, à ce jour, adapté au développement d'un jeu AAA. Si refaire Doom3 apparaît presque possible aujourd'hui (mais Doom3 commence à se faire un poil vieux), refaire Crysis en Java est plus que certainement impossible (j'ai eu l'occasion de discuter du CryEngine2 avec les gens de Crytek de nombreuses fois, et je ne crois pas que la technologie utilisée soit adaptable en Java, à moins se sérieusement la revoir à la baisse).
Ce qui effectivement, pousse au "conservatisme". Sauf que bon, "conservatisme" c'est un peu exagéré pour décrire une position attentiste.
Non. Malgré son immense fortune, MS n'a pas les moyens de prendre ce risque non plus - plus pour des raisons de PR qu'autre chose. Le mieux que MS puisse faire, c'est débloquer des sous-sous pour publier des jeux indépendant ou du type casual qui sont écrits en C# (j'ai déjà cité Schyzoid; d'autres vont certainement être réalisés). Le raisonnement est le suivant: si MS ou un studio first party de MS développe un jeu en C# et que le jeu se vends mal, MS se tire une balle dans le pied et perd pas mal de crédibilité. Si MS donne des sous à un studio third party pour faire un jeu en C#, c'est le studio en question qui est alors responsable de la qualité du jeu, pas MS.Il est fort probable que les prochains jeux de Microsoft soient en C#, car il a les moyens de prendre ce risque (et pas sun).
Dans ce cas, c'est la portabilité de Java qui est remise en cause. L'idée d'avoir un même binaire sur toutes les plateformes n'est possible à mettre en oeuvre que si toutes les plateformes se comportent de la même manière.
A quoi tu pense? A ma connaissance, il n'existe pas, à ce jour, de jeu AAA écrit en C#.C# fonctionne de la même manière que Java... on peut faire des jeux AAA en C#, donc pourquoi pas en Java...
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