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 :
Il n'y a que les techniques de bases d'il y a 10ans ... des objets 3D texturés. Je ne vois pas, par exemple, de bump mapping, pourtant l'une des bases de la 3D .. même pour les jeux amateurs...De plus, aucun n'utilise non plus de shadow casting ... une des bases également.Envoyé par gouessej
Y a t'il une raison que ces éléments basiques ne soit pas là ? (date du jeu ? performance ? contraintes lié à Java3D ? )
qu'est-ce qui te fait dire cela ?
en quoi les algorithmes utilisés dans le GC Java ne seraient pas utilisables en C++ ?
ce que tu dis n'est pas logique, un algorithme de programmation peut être appliqué à (presque) n'importe quel langage
il y a quand même des problématiques en C++ pour l'implémentation d'un GC qui n'existent pas en Java. Un exemple simple : en Java les objets sont manipulé via des références qui sont en fait des sorte de pointeur. par contre, en C++, tout peut être manipulé par des pointeurs, du coup, on ne peut pas généraliser la gestion memoire aussi simplement qu'en Java (qu'est ce qui se passe si on passe un pointeur vers un objet sur la pile par exemple, ou encore que le pointeur passé est le resultat d'un operation d'aritmetique de pointeur qui du coup ne pointe plus vers la base de la zone mémoire alloué...)
C'est en fait un des défaut/aventages (selon le point de vue) du C++ : on ne peut pas envisager l'utilisation d'un GC "universel" car les modes d'alloc sont bien plus varié qu'en Java ou tout passe par le tas.
à partir du moment où tu intègres l'utilisation d'un GC tu ne fait plus d'allocation avec des new/delete "standards" mais en passant par l'interface de ton GC (tu peux aussi surcharger les opérateurs)
tes pointeurs sont encapsulés dans une interface les prenant en charge
et évidemment tu ne manipules plus les pointeurs directement
la différence étant qu'en java c'est géré "nativement", tu n'as pas le choix et tu ne peux pas faire de "bétise" (quel imbécile a fait un delete sur mon smart_ptr ?)
Je te parle de "haut niveau" graphique, tu me réponds avec des graphismes "tout à fait acceptables". Tu joues sur les mots pour avoir le dernier?
Et tu nous montres des screenshots digne de jeux sur Saturn (excuse-moi, mais ton dernier screen est assez poussif... graphisme lowpoly à coup de triangles plats, textures étirées, lumières d'outre-tombe...).
Je ne dis pas que ça ne sera JAMAIS possible, je dis juste qu'au jour d'aujourd'hui, ce n'est graphiquement pas à la hauteur de programmes compilés (entendre par là "pas en Java"), ou alors au détriment de la vitesse, donc à moins d'avoir une bête de compétition, ça rame.
Vu que je sens que tu vas surenchérir, je précise tout de même que pour faire des jeux avec des graphismes du style des screens que tu as montré (donc pas trop poussés....), ok, no problem, on peut arriver à un jeu fluide...
(et accessoirement, je précise aussi que je suis développeur Java/Jogl amateur, avant d'être parqué avec les pros-C++, hein)
Pour les histoires de GC, je n'ai jamais eu de soucis avec, donc je n'interviendrai pas dans la discussion sur ce sujet... de toute façon c'est trop technique pour moi!
Non c'est juste vrai. Premièrement, il y a plusieurs modes d'utilisation de VBO; deuxièmement, les display lists sont aussi stockées sur la carte graphique; troisièmement, à la base, les VBO servent surtout à harmoniser et à simplifier l'API qui servaient à l'origine à utiliser des vertex arrays compilés ou pas et des display lists. Sur certaines cartes graphiques parmi les premières à implémenter les VBO (extension ARB sur l'ATI Radeon 9250 Pro par exemple), ils sont même si mal implémentés que tu as exactement les mêmes performances qu'avec des vertex arrays non compilés même si tu les mets en mode statique (j'ai fait le test avec une arène composée de 500 000 points et en respectant la taille maximale conseillée pour un VBO). J'en ai assez de lire sur plein de tutoriaux que les VBO sont une sorte de potion magique, c'est juste une API propre et unifiée qui permet d'avoir le beurre et l'argent du beurre, de se servir des display lists de la même façon que les vertex arrays.
Je ne vais pas dire ça. Je pense que beaucoup de programmeurs ne choisissent pas un langage de programmation par sadomasochisme. Java n'empêche pas d'avoir de beaux graphismes.Gouessej, les screenshots que tu nous montrent ne sont pas vraiment à l'avantage de java.
Un jeu c++ :
Tu vas dire que ce ne sont pas les graphismes qui importent, d'accord, mais ne sors pas ces arguments toi-même
Déjà, il n'y a pas que Java3D pour faire de la 3D en Java. De plus, JMonkeyEngine permet de faire du bump mapping et le jeu MegaCorps Online utilisait déjà du shadow casting en 2004 alors arrêtez de faire passer les jeux vidéo écrits en Java pour des antiquités.
Tu déformes mes propos. Je n'ai pas dit que les algorithmes utilisés par le ramasse-miettes en Java ne sont pas utilisables en C++ (il y a une différence entre "utilisé" et "utilisable"). Tu sais bien que la JVM a son propre memory heap et corrige-moi si je me trompe, je ne crois pas qu'on puisse choisir entre plusieurs algorithmes pour les ramasse-miettes optionels disponibles en C++ (rien n'empêche d'implémenter ceux qui nous intéressent) alors qu'en Java j'ai déjà dit qu'on avait le choix et ce sera encore plus vrai en Java 1.7.
Je ne joue pas sur les mots. Il y a un début à tout, il faut bien qu'on commence par avoir des jeux avec des graphismes que je trouve acceptables, c'est une étape.Je te parle de "haut niveau" graphique, tu me réponds avec des graphismes "tout à fait acceptables". Tu joues sur les mots pour avoir le dernier?
De toute façon, je crois que c'est aussi en partie subjectif. Si je montrais une belle capture d'écran, à partir du moment où ça viendrait d'un jeu écrit en Java, il y aurait toujours quelqu'un pour dire que c'est moche.
Ce n'est pas parce que ce n'est pas à la hauteur aujourd'hui que ça ne le sera jamais. Je ne vois pas pourquoi ça ramerait notablement plus en Java qu'en C++.
Tu te ranges très bien dans les pros C++ tout seul. D'ailleurs, pourquoi utilises-tu JOGL si tu penses que de toute façon, tu auras des performances si mauvaises que tu ne pourras pas égaler un programme compilé?(et accessoirement, je précise aussi que je suis développeur Java/Jogl amateur, avant d'être parqué avec les pros-C++, hein
Pour les histoires de GC, je n'ai jamais eu de soucis avec, donc je n'interviendrai pas dans la discussion sur ce sujet...
C'est tellement technique que tu sors des trucs du genre "au détriment de la vitesse" et "ça rame" sans preuve concrète alors que notamment les performances de JOGL sont sensiblement les mêmes qu'OpenGL en C++.
Dernière modification par Invité ; 03/02/2009 à 07h52.
J'ai simplement juger sur les exemples que TU as présenté qui n'ont rien de tout ça .. peux tu nous mettre des exemple utilisant ces techniques dans ce cas ?
Pourquoi on ne pourrait pas choisir en C++ son algorithme de ramasse-miette ? J'ai du mal à saisir, mais bon, je ne fais pas beaucoup de Java
et c'est pas comme si ele C++ n'avait pas son propre heap. Tu crois vraiment que malloc et new font un appel systeme a chaque fois ?
Non, ça c'est TON avis et TON opinion.
C'est magique d'être classé "pro C++" parce qu'on fait une critique sur Java... on peut adorer un langage et être lucide à son sujet. Faut arrêter d'être manichéen parfois...
ça aussi, c'est TON avis et TON opinion. Je n'ai jamais écrit ça. Nulle part.
Mon appli du moment n'a pas besoin de tourner à 300 fps. Je n'ai pas de graphismes poussés, pas de son à gérer, assez peu d'IA.
J'utilise Jogl parce que j'utilisais OpenGL en C++ (et que je suis allergique à Java3D, JME et similaire). J'utilise Java parce que je maitrise mieux ce langage que C++, et que je le trouve plus "agréable" pour développer (avis purement personnel qui n'engage que moi). Rien ne dit que je ne reviendrai pas au C++ le jour ou Java ne sera pas assez rapide pour ce que je veux faire.
Pour l'instant, pour faire ce que je veux faire, Java fait très bien son boulot. D'ailleurs mes algos Java de maintenant tourne plus rapidement que mes algos C++ d'il y a 5 ans. Comme quoi, il n'y a pas que le langage qui y fait.
j'aime beaucoup ta réponse, ça doit être le post le plus lucide, clair et bien tourné que j'ai lu ici et il retranscrit bien l'idée que je me fait des langages de programmation en général
le langage que l'on maitrise n'est pas forcément le "meilleur" mais à partir du moment où il donne satisfaction pas de raison d'utiliser un langage qui pourrait être plus performant sous condition de le maitriser aussi
Tu es assez grand pour aller vérifier la liste des fonctionnalités de JMonkeyEngine .
Pour le malloc, je pense que oui, c'est ce que j'ai appris en cours de programmation système. Pour le new, je ne m'avancerai pas. Si tu as une source à ce sujet, ce sera intéressant .
As-tu un exemple précis à donner dans ce cas?
Dans ce cas, une équipe de programmeurs maîtrisant Java et pensant pouvoir créer un jeu vidéo commercial avec ce langage ne devrait pas se priver.
Désolé, quelques programmeurs Java s'acharnent à croire qu'on peut écrire autre chose qu'un pong avec ce langage, voici une démonstration technique utilisant OpenGL et ... j'ai oublié le nom du moteur physique :
http://www.insightmachines.com/demo/demo.jnlp
J'avais déjà posté ce lien mais le programme a été mis à jour. Il utilise les shaders s'ils sont disponibles.
Dernière modification par raptor70 ; 05/02/2009 à 22h57.
Tu nous parles de jeux utilisant ces techniques... donne nous des exemples vu que tu en connais. Je n'ai jamais suivi l'actu des jeux Java donc je suis là pour le découvrir. Tu veux montrer que Java peut être utile .. donne des exemples concret pour argumenter et faire avancer ce débat.
Personnellement, je m'amuse beaucoup à charrier des amis qui font du Java, étant un fanboy C++. Mais je reconnais de grandes qualités à ce langage.
Je comprends que un programmeur à l'aise dans son langage veuille s'en servir pour un maximum de choses.
Par contre, je ne comprends pas, gouessej, que tu en sois presque à critiquer l'utilisation de C++ pour le développement 3D/Jeux. Ca, ça me tue.
Je reviens sur cette petite remarque que j'avais laissé passer...
Oserais-je mettre en avant le fait que toi non plus tu ne nous as toujours pas amené de preuve concrète que Java était capable aujourd'hui d'être de niveau à créer des jeux aux graphismes évolués?
Qu'entends-tu par "sensiblement"? as-tu des chiffres? des comparaisons? des références? pas Jake2 une nouvelle fois stp, c'est un Jogl optimisé qu'ils utilisent (justement parce que les perfs n'étaient pas au niveau). Sinon la comparaison code original en C / Jake2 0.9.1 (donc Jogl) n'est pas franchement à l'avantage de Jogl...
Pour le côté "techique", c'était en rapport avec le garbage collector et le débat qui tournait autour. Pour appréhender ce sujet, il y a besoin d'un peu plus d'investissement qu'une simple perception visuelle de joueur sur la "vitesse" d'une application. Evidemment, tu as détourné la phrase à ton avantage...
As-tu bien lu (et surtout compris) ma phrase???
Je pense savoir lire. J'ai déjà donné énormément d'exemples de programmes, d'API, de démonstrations techniques, de jeux... Ce n'est pas parce que je n'ai pas montré de jeux avec des graphismes "beaux" dans le sens actuel (jeux AAA) que ça ne peut pas être fait en Java. Par contre, j'ai tenté de montrer que les arguments avancés contre Java pour justifier sa lenteur ne tenaient pas la route, qu'il n'y a rien qui empêche de faire de tels jeux en Java (si ce n'est le fait qu'il faut parfois aller chercher les "ingrédients" un peu partout) et j'ai expliqué pourquoi. J'ai donné les paramétrages possibles pour le ramasse-miettes, etc...Oserais-je mettre en avant le fait que toi non plus tu ne nous as toujours pas amené de preuve concrète que Java était capable aujourd'hui d'être de niveau à créer des jeux aux graphismes évolués?
Qu'entends-tu par "sensiblement"? as-tu des chiffres? des comparaisons? des références? pas Jake2 une nouvelle fois stp, c'est un Jogl optimisé qu'ils utilisent (justement parce que les perfs n'étaient pas au niveau). Sinon la comparaison code original en C / Jake2 0.9.1 (donc Jogl) n'est pas franchement à l'avantage de Jogl...
Pour le côté "techique", c'était en rapport avec le garbage collector et le débat qui tournait autour. Pour appréhender ce sujet, il y a besoin d'un peu plus d'investissement qu'une simple perception visuelle de joueur sur la "vitesse" d'une application. Evidemment, tu as détourné la phrase à ton avantage...
As-tu bien lu (et surtout compris) ma phrase???
Encore une fois, tu méconnais ton sujet. Ce que les auteurs de Jake2 appelent "FastJOGL" n'est que pour l'essentiel l'utilisation des VBO en JOGL, l'appellation est trompeuse, je leur avais posé la question il y a quelques années. Pourtant, ils écrivent sur leur site que ce "FastJOGL" réduit le nombre d'appels natifs. De plus, je maintiens que Jake2 est un bon exemple, tu vois bien sur la troisième ligne que la version utilisant LWJGL (un autre binding d'OpenGL pour Java) va effectivement plus vite que la version originale. Globalement, Jake2 a au moins le mérite de montrer que les performances de Java et de C/C++ sont comparables, que Java n'est pas notablement plus lent (j'entends par là qu'il n'est pas 3 fois plus lent que C/C++). Je pense que Jake2 est un exemple plus complet qu'un petit benchmark que je pourrais faire dans mon coin. Tu vois, quelqu'un d'autre avait montré ici un benchmark où JOGL était 30% plus lent qu'OpenGL en C, ça ne tenait pas la route tout simplement car le gars avait fait une erreur de débutant, il avait mis un Thread.sleep(long millis) à un endroit bien choisi et ça cassait la synchronisation avec la carte graphique. Quand je fais ça dans mon jeu tout pourri, je divise le frame rate par 2. Quand je suis passé à JOGL alors qu'à la base mon projet était en C++, je n'avais pas vu de différence notable. Si tu veux rapidement te faire une idée, fais tourner glxgears en plein écran, GLGears avec LWJGL et GLGears avec JOGL (en le modifiant pour qu'il s'appuie sur AWT). Chez moi, avec une carte graphique d'une autre époque, j'obtiens entre 55 FPS et 57 FPS pour les 3. Il faudrait faire un test plus poussé car c'est un peu léger.
Enfin, pour le ramasse-miettes, je ne me suis pas limité à analyser la perception du joueur, j'ai mesuré les pauses, j'ai utilisé l'option -verbose pour voir quand j'ai un full GC (très rarement), j'ai essayé de voir quand il était le plus sollicité et pour quelles raisons, j'ai parlé ici même des réglages que tu peux faire pour limiter la durée maximale des pauses, je ne vais pas me répéter.
Alors toi tu as le droit de charier les utilisateurs de Java et moi je n'ai pas le droit de dire que C++ a ses limites et qu'il peut s'avérer inadapté pour certains types de projet, c'est bien ça? Ankama Games a choisi Java côté serveur et client pour Wakfu (version PC) à la place de Flash et non C/C++.
Ah oui, ça n'existe pas mais ça pourrait. Convaincant.
Il a montré qu'à son avis il n'y avait rien qui empêchait cette réalisation en argumentant sur chacun des points avancés ici.
Après on est d'accord avec lui ou pas (et pour un AAA je ne suis pas convaincu), mais lui au moins argumente contrairement à toi.
Oui mais quand je charie je plaisante, c'est à dire que j'invente des fausses critiques, je fais des blagues bidons, pour rigoler. Or toi, tu ne sembles pas rigoler en disant que Java est meilleur pour les jeux (c'est pas ça mais presque ...).
Non non, il n'y a pas d'appel système à chaque fois.
Par exemple sous linux, malloc utilise souvent l'appel système mmap ou brk (ou les 2), mais ne l'appelle pas à chaque fois car il réserve des blocs complets dans le tas.
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