Discussion :

[shenron666]

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.

cpu : core2duo E6300
gpu intel gma (shaders non disponibles)
fps : entre 0 et 5

edit : et en plus, la caméra fait n'importe quoi, par moment je n'ai plus rien à l'écran ou elle est en dehors du décor et on voit l'ombre en dessous

[stardeath]

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...

heu, alors si tu veux faire des jeux tout moche graphiquement, libre à toi, mais les jeux auxquels je joue, ils sont soit très fun, soit bien et beau. des jeux avec un graphisme à la quake 2, non merci, des potes font la même chose en caml, et eux ils n'utilisent pas opengl.

hors pour prouver sa lenteur ou pas, il faudrait peut être que tu nous montre quelque chose de comparable avec des techniques avancées actuelles.

ha et si, encore un truc, les fps après un certain seuil c'est juste une bonne blague de "qui qu'a la plus grosse";
par contre récupérer 10 fps quand tu es à 50, là il y a un vrai challenge, en prendre 100 quand tu es déjà au dessus de 150, c'est juste du kikoolol.

[Alp]

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.

+1, d'autant plus qu'en C++ on ne passe pas toujours (selon les implémentations) par du malloc quand on fait un new, etc.

Sinon, je trouve la réponse de stardeath très pertinente. On voit des jeux très fun et bien foutus mais également fluides avec des langages qui n'ont pas pour réputation d'être "rapides" (comparés aux langages répandus pour le temps réel).

On ne renie pas le fait que Java et sa JVM s'améliorent côté performance, mais gouessej tu nous dis bientôt que le C et le C++ sont des langages lents et que pour faire de vrais gros jeux nécessitant de la rapidité il faut utiliser Java...

[Mat.M]

Je suis d'accord avec Stardeath , Quake2 c'est un peu dépassé techniquement
Donc j'en conclut que les possibilités technologiques de Java ne permettent de faire que des jeux dépassés technologiquement

On voit des jeux très fun et bien foutus mais également fluides avec des langages qui n'ont pas pour réputation d'être "rapides" (comparés aux langages répandus pour le temps réel).
.

Tout à ait d'accord on peut faire d'excellents petits jeux en Flash

[plegat]

Je pense savoir lire. J'ai déjà donné énormément d'exemples de programmes, [...]

Hors sujet... je te demandais ça concernant ta question visant à fournir un exemple qui me fera revenir au C++...

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.

Très bien. Je dis que Jake2 se base sur un Jogl optimisé, tu réponds qu'ils utilisent une version modifiée pour aller plus vite. J'appelle ça de la mauvaise foi.

Quand je suis passé à JOGL alors qu'à la base mon projet était en C++, je n'avais pas vu de différence notable.

De même.
Par contre, histoire de prévenir ceux qui voudrait faire la même manip, il faut faire gaffe sur certains algos, et ne pas adapter tel quel du code C++ au risque de parfois faire augmenter dramatiquement le temps de traitement (mon adaptation d'une classe Screenshot avait été calamiteuse... heureusement que c'est intégré dans Jogl maintenant) (ça rejoint ta remarque sur le benchmark avec le Thread.sleep())

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)

C'est bon, je tourne déjà avec Jogl.
Par contre si tu as un lien où récupérer cette bête... ça m'intéresse (celui qui est livré avec Jogl n'affiche pas les fps, et je n'ai pas hyper le temps de mettre les mains dans le code...).

Enfin, pour le ramasse-miettes, je ne me suis pas limité à analyser la perception du joueur, [...]

Tssss... hors-sujet encore... essaie de lire au premier degré ce qu'on écrit, et de ne pas y chercher une attaque personnelle ou une critique...

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.

Il suffit juste que quelqu'un le fasse avec les technos et les "critères de qualité" du moment pour avoir une référence. Comme ça on arrêtera de polémiquer. N'y aurait-il pas des projets en cours du côté de Sourceforge ou similaire (hormis Jake2)?

edit : et en plus, la caméra fait n'importe quoi, par moment je n'ai plus rien à l'écran ou elle est en dehors du décor et on voit l'ombre en dessous

tout à fait... mais c'est une démo technique pour un moteur physique, il ne faut pas trop en demander sur l'affichage...
Il doit y avoir un paramètre à régler chez toi, ça tourne à 30fps sur mon antiquité.

Sinon, je trouve la réponse de stardeath très pertinente. On voit des jeux très fun et bien foutus mais également fluides avec des langages qui n'ont pas pour réputation d'être "rapides" (comparés aux langages répandus pour le temps réel).

Donc, si on extrapole, vu la réputation de lenteur que traine le langage tel un forçat son boulet... on peut faire des jeux très fun et bien foutus en Java

Donc j'en conclut que les possibilités technologiques de Java ne permettent de faire que des jeux dépassés technologiquement

C'est juste que Java évolue tellement vite que le temps qu'on finisse de programmer le jeu, il y a eu tout plein d'améliorations qu'on n'aura pas pu prendre en compte!

[Invité]

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.

Merci. J'ai donné des sources aussi quand j'en avais.

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 ...).

Je dirais plutôt que je pense que C++ n'est pas la solution miracle pour tout. Les contraintes évoluent.

cpu : core2duo E6300
gpu intel gma (shaders non disponibles)
fps : entre 0 et 5

edit : et en plus, la caméra fait n'importe quoi, par moment je n'ai plus rien à l'écran ou elle est en dehors du décor et on voit l'ombre en dessous

Je crois tout simplement qu'il a dû utiliser les VBO et que sur ta carte, il aurait mieux fait d'utiliser les display lists. Certaines puces Intel ont des performances catastrophiques avec les VBO. Autrement dit, ça n'a rien à voir avec Java.

heu, alors si tu veux faire des jeux tout moche graphiquement, libre à toi, mais les jeux auxquels je joue, ils sont soit très fun, soit bien et beau. des jeux avec un graphisme à la quake 2, non merci, des potes font la même chose en caml, et eux ils n'utilisent pas opengl.

Ok, je veux bien te croire mais il faudra que tu me montres Quake 2 en OCaml s'il te plait et sans OpenGL.

hors pour prouver sa lenteur ou pas, il faudrait peut être que tu nous montre quelque chose de comparable avec des techniques avancées actuelles.

J'ai montré Avengina mais ce n'est peut-être pas suffisant.

ha et si, encore un truc, les fps après un certain seuil c'est juste une bonne blague de "qui qu'a la plus grosse";
par contre récupérer 10 fps quand tu es à 50, là il y a un vrai challenge, en prendre 100 quand tu es déjà au dessus de 150, c'est juste du kikoolol.

Oui tu prêches un convaincu, j'ai lu quelques petites choses intéressantes sur la persistance rétinienne, l'illusion de continuité et l'effet phi. Du coup, je pense qu'il aurait été plus intéressant de tester Jake2 sur des machines beaucoup moins puissantes.

On ne renie pas le fait que Java et sa JVM s'améliorent côté performance, mais gouessej tu nous dis bientôt que le C et le C++ sont des langages lents et que pour faire de vrais gros jeux nécessitant de la rapidité il faut utiliser Java...

Je n'ai jamais dit que C et C++ étaient des langages lents, tu extrapoles. Je te prie de ne pas déformer mes propos, ni de tenter de me caricaturer. Cependant, je ne suis pas choqué de lire que Brian Goetz prétend que les allocations mémoire en Java sont plus rapides qu'en C++.

Je suis d'accord avec Stardeath , Quake2 c'est un peu dépassé techniquement
Donc j'en conclut que les possibilités technologiques de Java ne permettent de faire que des jeux dépassés technologiquement

Conclus ce que tu veux mais c'est ça que j'ai du mal à vous faire comprendre ici : Java n'a pas encore son "Far cry 2" (sinon ce débat n'aurait pas de raison d'être) mais il n'est pas impossible de créer un jeu de ce niveau en Java. Furikawari a très bien compris ce que je voulais dire et l'a exprimé plus synthétiquement que moi.

Hors sujet... je te demandais ça concernant ta question visant à fournir un exemple qui me fera revenir au C++...

Je n'ai pas d'exemple qui te ferait revenir au C++.

Très bien. Je dis que Jake2 se base sur un Jogl optimisé, tu réponds qu'ils utilisent une version modifiée pour aller plus vite. J'appelle ça de la mauvaise foi.

C'est complètement faux! Tu déformes complètement ce que j'ai écrit! Selon moi, ils utilisent une version tout à fait standard de JOGL mais au lieu de se contenter des display lists, ils utilisent des VBO comme d'autres jeux reposant sur JOGL le font déjà. Tu sembles ne pas m'avoir compris.

De même.
Par contre, histoire de prévenir ceux qui voudrait faire la même manip, il faut faire gaffe sur certains algos, et ne pas adapter tel quel du code C++ au risque de parfois faire augmenter dramatiquement le temps de traitement (mon adaptation d'une classe Screenshot avait été calamiteuse... heureusement que c'est intégré dans Jogl maintenant) (ça rejoint ta remarque sur le benchmark avec le Thread.sleep())

Tu n'es pas le seul à être passé par là. J'avais utilisé AWT directement quand JOGL n'avait pas encore cette classe.

C'est bon, je tourne déjà avec Jogl.
Par contre si tu as un lien où récupérer cette bête... ça m'intéresse (celui qui est livré avec Jogl n'affiche pas les fps, et je n'ai pas hyper le temps de mettre les mains dans le code...).

Va dans la rubrique "Demos" sur www.lwjgl.org et pour la version JOGL, va sur le site officiel de JOGL, il y a un fichier jogl-demos.zip dans la rubrique de téléchargement.

Il suffit juste que quelqu'un le fasse avec les technos et les "critères de qualité" du moment pour avoir une référence. Comme ça on arrêtera de polémiquer. N'y aurait-il pas des projets en cours du côté de Sourceforge ou similaire (hormis Jake2)?

J'aimerais bien que ce soit si simple... La bêta version de Tribal Trouble 2 est pas mal mais bon... ce n'est pas suffisant.

tout à fait... mais c'est une démo technique pour un moteur physique, il ne faut pas trop en demander sur l'affichage...
Il doit y avoir un paramètre à régler chez toi, ça tourne à 30fps sur mon antiquité.

Ton antiquité et la mienne gèrent mieux que les puces Intel

Donc, si on extrapole, vu la réputation de lenteur que traine le langage tel un forçat son boulet... on peut faire des jeux très fun et bien foutus en Java

C'est bien dit. Les "Puppy Games" en sont de bons exemples.

C'est juste que Java évolue tellement vite que le temps qu'on finisse de programmer le jeu, il y a eu tout plein d'améliorations qu'on n'aura pas pu prendre en compte!

Ca dépend de quoi tu parles exactement car une modification dans OpenGL se répercute très facilement dans JOGL et LWJGL, ce dernier supporte déjà OpenGL 3.0, la V-Clip Collision Detection Library des Mitsubishi Electronic Research Laboratories a été assez facile à porter du C++ à Java.

Edit. : J'ajoute quelques captures d'écran ci-dessous.

[Mat.M]

Je dirais plutôt que je pense que C++ n'est pas la solution miracle pour tout. Les contraintes évoluent.

Qui a dit que C++ était la solution miracle ?

Sais-tu pourquoi Sun a fait le langage Java au moins ?
Sun a fait ce langage parce que c'est une sorte d'architecture distribuée multiplateformes.
Donc si je veux des applets pour faire des calculs comptables, sortir des états,des classes pour la facturation en entreprise, pour plateformes hybrides sur As400, Windows, IBM Mainframe je vais prendre évidemment Java ( Websphere notamment ).
Faire cela en C++ serait idiot.
Si je veux coller au plus près des ressources matérielles de la machine je vais prendre C++ parce que c'est plus adapté évidemment étant donné qu'en C++ on accède directement à la mémoire et au bas-niveau.

Tu parles de "contraintes qui évoluent".
Franchement je ne vois pas ce dont tu parles si tu peux m'expliquer plus en détail cela serait une bonne chose.
J'ai toujours programmé en C++ pour concevoir des jeux je ne vois pas ce que va m'apporter de plus Java à part toute une usine à gaz de classes .jar à raccorder les unes avec les autres.
Je programme en C++ et Direct X on va à l'essentiel point à la ligne et avec les performances..

[stardeath]

J'ai montré Avengina mais ce n'est peut-être pas suffisant.

méa culpa, j'avais pas vu, c'est dans ce style de démo que je trouve que l'on pourra "comparer" les 2 langages (si y a quelque chose de vraiment vital à comparer), ensuite faut avoir assez de courage pour programmer 2 scènes strictement équivalentes tant en java qu'en c++.

mais bon ça c'est pas pour moi, vu que je bosse sous directx (excuse bidon je sais ^^)

[shenron666]

Je crois tout simplement qu'il a dû utiliser les VBO et que sur ta carte, il aurait mieux fait d'utiliser les display lists. Certaines puces Intel ont des performances catastrophiques avec les VBO. Autrement dit, ça n'a rien à voir avec Java.

je pense plutot que les shaders ne sont pas "glsl" mais des "programs"
les VBO semblent bien fonctionner sur la puce intel du boulot
mais c'est clair que la lenteur n'est pas un problème java
avec une nv9600GT je plafonne à 60 fps

[IrmatDen]

Bon allez, je lâche mon popcorn et mon code pour me joindre au troll l'espace d'un post

Cependant, je ne suis pas choqué de lire que Brian Goetz prétend que les allocations mémoire en Java sont plus rapides qu'en C++.

Les boîtes utilisant sérieusement le C++ pour faire du jeu vidéo demandant de grosses perfs trouve aussi que les perfs en C++ sont mauvaises. C'est pourquoi ils finissent par implémenter leur propre version de la STL, et tout particulièrement des allocateurs. Pour les curieux prêt à passer un peu de temps sur une page très intéressante, EA a présenté sa version de la STL (vous y trouverez les motivations poussant à implémenter différemment telle ou telle chose).
Donc s'il juge les perfs d'allocation, la question est: quelle stratégie d'allocation as-t-il utilisé dans son bench c++ ? (désolé, je ne l'ai pas trouvé en googlant; le bench que j'ai trouvé avec son nom ne comportait pas de mesures sur ce point, et date vraiment).

[stardeath]

c'est tout sauf un troll, la stl est totalement inefficace quand on bosse sur un projet nécessitant des performances, la stl n'a qu'un avantage : totalement basée sur les templates, mais à quel prix??

sur mes propres codes, j'ai remarqué une grosse différence de rapidité dès que mes structures de données devenaient assez importantes, utiliser un bête tableau, malgré les inconvénients, reste le must.

[deadalnix]

Les templates, c'est mouliné à la compilation. Si la STL est lente, ça n'a rien avoir avec celles-ci.

[Alp]

Il y a pas mal de choses (presque tout) dans la STL qui est fait pour être aussi général et réutilisable que possible. Ceci a un coût : les performances. On ne peut fournir un truc générique à souhait sans perdre en performances, et de plus il y a pas mal d'indirections, etc... Bref ce n'est pas optimal. Après, il faut utiliser les bonnes SDD, jouer avec les subtilités du C++, etc... si on veut du super performant.

[tulipebleu]

Si j'ai bien compris, les jeux AAA ne peuvent être fait qu'en C++, avec DirectX et pas en C, ni sous Linux. De plus, il ne faut pas utiliser la librairie standard de C++.

Ce que je ne comprend pas, et que j'aimerais qu'on m'explique, c'est est-ce qu'on peut utiliser le polymorphisme et l'héritage pour faire des jeux AAA ? Parce qu'on m'a toujours dit que l'héritage multiple est plus lent que l'héritage simple. Il me semble que c'est un des points fort du Java par rapport au C++.

Si on ne peut pas utiliser l'héritage et le polymorphisme, qu'elle est l'interret du C++ ? le typage fort ? les templates ? la librairie DirectX ? un moteur 3d ultra optimisé en assembleur utilisable directement en C++ ?

[Matthieu Brucher]

Si j'ai bien compris, les jeux AAA ne peuvent être fait qu'en C++, avec DirectX et pas en C, ni sous Linux. De plus, il ne faut pas utiliser la librairie standard de C++.

Ce que je ne comprend pas, et que j'aimerais qu'on m'explique, c'est est-ce qu'on peut utiliser le polymorphisme et l'héritage pour faire des jeux AAA ? Parce qu'on m'a toujours dit que l'héritage multiple est plus lent que l'héritage simple. Il me semble que c'est un des points fort du Java par rapport au C++.

Si on ne peut pas utiliser l'héritage et le polymorphisme, qu'elle est l'interret du C++ ? le typage fort ? les templates ? la librairie DirectX ? un moteur 3d ultra optimisé en assembleur utilisable directement en C++ ?

Non, on peut faire des jeux AAA en C, sous Linux, ...
On peut utiliser le polymorphisme et l'héritage, l'héritage multiple n'a pas d'incidence sur la vitesse si on ne fait pas n'importe quoi. C'est toujours la même chose. Dans les parties critiques, il est nécessaire de faire le maximum en statique (pas de polymorphisme dynamique, fonctions virtuelles, ...), mais pour le reste, on s'en fout un peu (beaucoup).

[stardeath]

Les templates, c'est mouliné à la compilation. Si la STL est lente, ça n'a rien avoir avec celles-ci.

que les templates soient moulinés à la compilation ou pas ne change rien, aucune optimisation spécifique (comme par exemple l'alignement) n'est possible du à sa (trop) grande généricité. et vu qu'on parle de performance ....

[deadalnix]

Mais cela n'a rien a voir avec les teplates.

Preuve en est que le code templaté n'est pas lent s'il en fallait : les expressions templates pour le calcul matriciel.

[IrmatDen]

que les templates soient moulinés à la compilation ou pas ne change rien, aucune optimisation spécifique (comme par exemple l'alignement) n'est possible du à sa (trop) grande généricité. et vu qu'on parle de performance ....

C'est un point soulevé dans le papier indiqué plus haut. Mais ça n'a en effet rien à voir avec les templates.

[stardeath]

bah vu que le but des templates est d'être générique, je vois mal des templates préprogrammés avec des optimisations pour tous les types, ou alors j'ai pas compris le but des templates.

[Matthieu Brucher]

bah vu que le but des templates est d'être générique, je vois mal des templates préprogrammés avec des optimisations pour tous les types, ou alors j'ai pas compris le but des templates.

Tu peux le faire, grâce à la spécialisation des templates. Les type traits sont créés sur ce principe de spécialiser tout en proposant une interface générique.